AnsweredAssumed Answered

STM32 SPI with DMA, DMA complete but SPI_BSY still

Question asked by Willette.Gary on Jul 15, 2015
Latest reply on Jul 17, 2015 by Willette.Gary
Here is my scenario:

SPI communications from STM32 to an FRAM NV device using SPI3. STM32 is SPI master, and SPI3 is set up to use the appropriate DMA channels for both RX and TX. The cube tool was used to setup the pin configuration on the STM32. There are currently no other users of SPI3 (they have been disabled for debugging purposes).

The problem:

DMA TX and RX are both successful, unless I attempt to perform a write then read of some arbitrary number of bytes (512 bytes or more). I am using the  ST-generated callback routines to signal the end of each respective DMA transaction, but I will focus on DMA TX because that is where I am seeing an issue. SPI_DMATransmitCplt is called once the DMA transaction has been completed, and not before (correct me if I'm wrong).

This function waits until the TXE flag is set (ready to be loaded for next transaction) and then waits until the SPI_BSY flag is reset. If both of these events pass, I set an a bit in an event group, which allows the original API function (which I wrote) to un-block. If I immediately check the SPI_BSY flag at this point, it is reliably busy for specific-sized transmissions, and remains busy for a time proportional to the transmission size. From 1 'tick' to 600 'ticks' (for TX of 65535 bytes). This tells me that the BSY flag is indeed related to the TX which I initiated.

The initial issue, and what is really a problem still, is that if I don't manually insert a check and wait for the SPI_BSY flag after a DMA TX, there is a chance that when I attempt to perform an RX, it will fail with status SPI_BSY. Even though the  SPI_DMATransmitCplt() function processed without error.

Can someone help me understand what's happening here? I don't understand how the ST-provided callback can wait until the BSY flag is reset before resuming, and then immediately after, the SPI is BSY.