Writing to SD card via SPI interfering with USART DMA Rx?

[Sebastian K.]

Posted on January 04, 2018 at 21:48

Hello,

I am having a problem with a simple data logging project on an L432KC Nucleo board.

I have a microSD breakout board from Adafruit hooked up via SPI1 and receive data on USART1 via DMA using a circular buffer for continuous reception. I am firing data at the board from another board in frames of ~100 Bytes every 20 ms at 460.8 kBaud. The intention is that the DMA keeps filling up the buffer with incoming data while I'm busy writing chunks of it to the card (which I am aware can take relatively long). Both parts work fine by themselves, I can write data to the card and the USART Half and Full Rx Completed callbacks are triggered as expected. I'm using the FATFS middleware provided by CubeMX and an adapted version of the Adafruit LCD shield library from the ST examples.

The weird thing is that it seems that whenever I write to the card (or sync it), during that time the USART does not receive any characters. I know that because the test data I am sending includes a running frame counter, and in the recorded file I see missing frames each time I write a chunk of data to the card. The DMA buffer is large enough to not overflow while I'm writing to the card.

Is that supposed to happen? I thought the SPI and USART were independent peripherals, and in the SD card / FAT code I see nothing that could lock the USART or DMA. Does anyone have any pointers as to what could be going on? I looked at the documentation, but found nothing that could explain it.

Thanks for reading.

#micro-sd-card #nucleo-l432kc #uart-dma

[Tesla DeLorean]

Posted on January 04, 2018 at 22:12

It should work. Make sure the SPI RX/TX and USART RX/TX DMA don't have any overlap. Make sure there isn't any blocking or interference from the HAL.

If the problem is easy enough to replicate you should work with an ST engineer to confirm the nature of the problem.

[Sebastian K.]

Posted on January 05, 2018 at 13:53

Clive One wrote:

It should work.

And it does. Turns out it was a simple indexing mistake I made when reading the two halfs of the DMA buffer. It works like a charm now.

Thanks for answering. At least it reassured me that there is no hardware limitation I wasn't aware of.