2020-04-30 07:31 AM
I'm using the SPI peripheral on an STM32H743 as a slave. Is there a way to change the contents of the TX FIFO without resetting the peripheral? I need to always transmit a specifc byte at the beginning of a transaction along with other data, but the master may only request the first byte to analyze it (It is a status word indicating the repsonse is ready). At this point I need to refill the FIFO with the status word and the data.
Solved! Go to Solution.
2020-05-05 09:34 AM
I got the NSS signal to work in slave mode via HAL by setting the GPIO mode for the NSS pin to GPIO_MODE_AF_xx AND calling HAL_EXTI_SetConfigLine separately. I think this should suffice. If the HAL_GPIO_Init function allowed both GPIO_MODE_AF_xx and GPIO_MODE_IT_xx mode it would work nicely. Thanks so much.
2020-05-05 09:52 AM
I should mention that, in my design, I also have the SPI4_NSS signal routed to PA7 which is muxed with TIM3_CH1 and TIM14_CH1 so it might be possible to implement that "timer capture triggering a DMA transfer" solution you mentioned. Could you provide more details on how to implement that or perhaps a HAL example you could point me to?
2020-05-06 04:49 AM
It is possible with TIM3_CH2 on PA7, but it seems to be more complicated than I have anticipated at first.
So, the basic idea is
Is there some minimum time between the rising and falling edge of NSS guaranteed? If it is long enough, then using EXTI would be simpler.
2020-05-06 06:59 AM
Very impressive. Which DMA stream reads the RX FIFO or is that an unmentioned 4th DMA stream?
I'll use EXTI. There's about 5us of wiggle room.
2020-05-06 07:49 AM
Yes, another DMA strem is needed if there is incoming data as well, not just dummy bytes to keep the SPI clock going. That's what bothers me in my solution, using up too many DMA streams from the limited supply.
5 μs should be enough, just use EXTI. Dont't use HAL functions, they are terribly slow. Interrupt handling with HAL is even slower.
2020-05-06 10:45 AM
That is helpful that you measured HAL's timing in the scope images. HAL gets a lot of criticism, understandably, but in its defense it is VERY handy for getting to know how the peripherals work and have working code that can be extracted.
Do you know anything about JKhal's comment in the "SPI is too slow" forum post you provided a link to about the Hardware NSS not working for him?
2020-05-07 12:03 AM
> you measured HAL's timing in the scope images.
Not my measurements, I'm using them with permission. They were made on an STM32F4 which runs maybe on 1/3 the speed of the STM32H7.
> HAL gets a lot of criticism, understandably, but in its defense it is VERY handy for getting to know how the peripherals work and have working code that can be extracted.
Exactly. Look into thje HAL source code to see what registers are in what order accessed. But when dealing with an interrupt that could be triggered in 5 μs intervals, forget fancy concepts like flexible reusable code, write a specialized interrupt handler that does exactly what you require and nothing more.
> about the Hardware NSS not working for him?
No idea. There were issues with hardware NSS in master mode on earlier STM32 series, but I believe they were solved on the STM32H7.
I am not aware of any issues with NSS in slave mode.