2021-03-18 12:40 AM
Hi everyone,
I have a problem with a bidirectional SPI communication. I am using the HAL_SPI_TransmitReceive_DMA function for all my communications and my project is loosely based on the STM SPI example. I have now noticed a problem with my communication:
-The communication between master and slave switches between sending commands and statuses (8byte) and payload data (e.g. 1024 byte) so the DMA buffers have to be reconfigured in between those communications.
-The master will request payload data from the slave (8byte) and if the slave has available data it will signal this. The slave will then move on and run the HAL_SPI_TransmitReceive_DMA (now with the bigger payload buffer as an argument). Meanwhile the master also moves on, and activates the slave select signal (I am doing this through a GPIO, since later this bus needs to be extended to multiple slaves) and then runs its HAL_SPI_TransmitReceive_DMA to receive the payload data from the slave.
-The problem I noticed is that if the slave select signal is activated while the slave is still in the HAL_SPI_TransmitReceive_DMA function, the subsequent communication will fail/the slave will not respond to anything.
My first assumption here is that the slave select signal will lock the SPI peripheral from further configurations (which obviously makes sense, since it needs to be ready to receive data now) but I confused why the HAL_SPI_TransmitReceive_DMA does not generate any errors. It runs through as normal, returning HAL_OK while the SPI/DMA is now stuck forever. The slave code is then waiting for the TXRX interrupt which will never happen. If I just delay the master enough so that the slave select signal comes after the slave finishes its HAL_SPI_TransmitReceive_DMA everything works perfectly. The actual communication from the master happens around 30us after btw, so that is not the problem. I have verified all these timings using an oscilloscope btw.
My initial solution/idea is that I could implement another bus line where the slave can signal to the master that it is ready to receive/send data, but I am wondering if I missed something. I tried to find out if there is any interrupts or failures but cannot find any.
Thanks for your help in advance!
2021-03-18 01:58 AM
> The problem I noticed is that if the slave select signal is activated
What do you mean by "activated" here? Draw a simple timing diagram.
JW
2021-03-18 02:16 AM
Added note: Slave select is low active
Legend:
1: SPI SCK, start of communication
2: Debug signal: Slave enters TransmitReceive function
3: Debug signal: Slave finishes/returns from TransmitReceive function
4: Slave Select from previous transmission is deactivated
5: Slave Select is asserted for next transmission
6: Debug signal: Master enters TransmitReceive function
7: Debug signal: Master finishes/returns from TransmitReceive function
The picture shows the situation where the communication fails. If I delay the master and the slave select edge (5) moves past the time when the slave function finishes (3), the communication works