SPI DMA Stream Seems to Eventually Freeze

[Drew M]

Hi,

I'm using CubeMX generated HAL drivers to use SPI in DMA mode. In my particular situation, we are sending a small amount of data (3 bytes) very often over the SPI interface. The data transmission works fine most of the time, but sometimes (as little as 100, or as many as 5000 transactions), the SPI's Rx DMA stream (which the HAL SPI driver uses to indicate completed transactions in Rx/Tx mode) will seemingly just stop transferring data. This then causes the application level Tx buffer to backup and I can no longer communicate with the external peripheral.

Metadata:

STM32777NIH MCU

STM32CubeMX v5.0.1

Details:

At the time when the application level Tx buffer begins to overflow, I've used IAR to inspect various registers of the DMA stream and SPI peripherals. At the time of overflow, it looks like the DMA stream is configured to transfer data, but the the transfer complete callback never occurs:

DMA_S1CR: TCIE, HTIE, TEIE, DMEIE, and EN bits are all set to 1, so I think the stream and appropriate interrupts should be enabled

DMA_S1NDTR: set to 2, indicating 2 data items left to transfer

SPI2_CR2: TXDMAEN and RXDMAEN both set to 1

As far as I can tell, the registers indicate that the DMA stream should transfer the data and call the appropriate callbacks in HAL. Yet, the registers stay in these states indefinitely, seemingly waiting of the DMA transfer to complete. The SPI_DMATransmitReceiveCplt() callback (or DMA1_Stream1_IRQHandler() for that matter) is never called after this point. I have not seen any error flags set in the status registers for either the DMA stream or the SPI instance. I also put breakpoints on the error callback functions that HAL registers, but they never get called.

Does anyone have an idea of what the issue may be or what next I should check in debugging?

[waclawek.jan]

> what next I should check in debugging

SPI registers, mainly status register. But don't look at them with the debugger as reading DR may be intrusive.

I'd suspect unhandled SPI Rx overflow.

JW

[Drew M]

Thanks for the reply JW,

Are you suggesting that the debugger reading the data register could be pulling data out of the SPI Rx FIFO and inadvertently interfering with the normal register access sequence?

I've tried closing my memory/register windows in IAR and just putting a breakpoint in the SPI IRQ handler to see if it is ever called with any error flags raised, but haven't seen anything.

[S.Ma]

Well, F7 has data cache and this could cause trouble. Try to disable the cache to confirm/infirm the assumption.

With F4/L4 got SPI Master slave with DMA run every 5 msec for hours with 2kbyte packets without fault.

[Drew M]

I have the D-cache disabled on the system, so I don't that should be interfering with anything. I haven't had any issue with the other DMA streams that are in use, so I'm wondering if the small data size and frequency of starting/ending transfers is causing problems. I'll be doing some more investigating