0
votes

I have an application with a STM32F337 which should implement an SPI slave protocol.

Each of the SPI transaction packets or frames, whatever you want to call them, is supposed to have, say, exactly 100 bytes.

The master uses the NSS line to make sure that the frames are synchronized, as it is done in any good SPI application.

So in order to transmit 100 bytes, the master pulls NSS low (asserts it), clocks the 800 bits to the slave in the usual way and pulls NSS high again (de-asserts it).

Whenever one transaction goes wrong, the next one is supposed to be ok again by means of the synchronization, so during the "high time" of NSS the transaction is supposed to be evaluated and re-established. In order for this to happen, I need an interrupt signal for the NSS line which even should fire if the number of bytes transmitted was less than 100. (Tests show that the DMA interrupt is only fired as soon as 100 bytes are transmitted, no matter how often NSS is de-asserted and asserted again.)

I have found out that the SPI slave peripheral in the µC unit only uses the NSS line to control the MISO line's state (High Z or not), but does not control the communication using it, i. e. it doesn't reset any DMA state or whatever.

Thus, I have to find a way to mulitplex the line between NSS functionality and EXTI in order to have an interrupt ehenver the line state changes. But I don't see a way to be able to do so – at least, STM32Cube won't let me use the same pin for NSS and EXTI.

Is this a restriction of Cube or of the µC unit? Do I have other alternatives (except connecting the signal to several pins at once)?

2
IMO in the SPI protocol just check the line and you are done. EXTI in this case will make from it the "spaghetti code", and it is completely unnecessary as you know when you receive the data.0___________
You question is unfortunately completely unintelligible. Apparently you want some kind of synchronization for "transactions" so the 100-byte packages aren't sent in chunks with NSS deasserted in-between?FRob
@PeterJ_01 Unfortunately, the SPI peripheral checks the NSS for controlling the MISO's state (= the output in slave mode), but it doesn't reset the transaction state. (Except I see or configured something wrong.)glglgl

2 Answers

2
votes

I agree, that this is a major limitation of the STM32 SPI slave implementation. The SPI unit is not able to generate an interrupt whenever CS is de-asserted.

IMHO the best solution is indeed to connect the CS line to two MCU pins in order to be able to use hardware NSS and EXTI functionality in parallel. If this is not possible, my solution is to use the CS signal as EXTI interrupt and manage the SPI slave using software NSS management. The EXTI can be triggered on both edges (i.e. on assertion and de-assertions of CS) and the SPI slave is enabled and disabled by software from the EXTI interrupt handler.

The critical path of this approach is the time to prepare the SPI slave for reception on assertion of CS. The EXTI interrupt triggered by this event needs to be highly prioritized but depending on the clock configuration and the timing requirements by the SPI master the CPU might not be fast enough to toggle the NSS bit per software. In this case it might be an option to switch NSS on early - but this might not be possible in every application (e.g. shared SPI channels with multiple slaves).

1
votes

NSS in STM nomenclature or CS only selects the slave and signals not slected slaves to enter HI-Z state to free the bus.

It is not the synchronization mechanism and DMA will not trigger any interrupts because the NSS line is deasserted.