STM32F429 - DMA writes to SDIO controller causing a FIFO error.

[GJohn]

SDIO DMA read operations appear to work fine. I suspect a configuration error, but I'm not sure where to start. DMA controller configured with CubeMX software. Device is running only one task under FreeRTOS. Any suggestions would be appreciated.

[Tesla DeLorean]

With writing you must ensure the SDIO/SDMMC FIFO actually clears to the media, the DMA TC will signal before this occurs. Problems usually occur if you plough on forward and send new commands before the data from the prior command has completely flushed.

[GJohn]

The operation in question was a f_write() operation to the FatFS middleware. The DMA operation was being performed by the HAL library. Am I correct in assuming there is a bug in the HAL SD code which

is causing this error?

[Tesla DeLorean]

There's been some suggestions that FreeRTOS causes a race condition of threads/interrupts handling the peripheral. You'd perhaps want a mutex to arbitrate access to the peripheral.

[GJohn]

Further information: the hardware is a STM32429I eval board. FreeRTOS is configured with, and running only one thread. So a race condition isn't possible. So is this a bug in the HAL SD routines?

[waclawek.jan]

How exactly do you detect this error?

JW

[Tesla DeLorean]

Callbacks are interrupts, you might have a single thread, but access to the peripheral is not serialized strongly, if foreground code causes a callback, and if the callback does more than set a flag, it has the potential to disturb the state of the peripheral. If I understand the complaint, a stop command or another command is submitted to the SDIO/SDMMC controller in the callback, and later code compares command vs command response and they don't match.

[GJohn]

This thread seems to be wandering off topic. So let me re-state the original issue.

I am running a very small test program to test a uSD memory card connected to the SDIO controller in a ST32F429 microcontroller (STM32429I-Eval PCB) . FreeRTOS and FATFs are configured.

What I see is that the DMA reads of the memory card work fine - I can see the FAT32 file structure and the FATFs f_mount() call works fine. DMA writes to the memory card fail. By placing breakpoint in the DMA ISR routine HAL_DMA_IRQHandler() (module stm32f4xx_hal_dma.c) the DMA write operation is failing with the FIFO error bit set (register DMA_HISR, bit FEIF6). I have no idea why this is occurring.

So far, I have discovered that CubeMX configured a 1 bit memory card I/F even though I specified a 4 bit I/F. I also observed that the DMA write routine HAL_SD_WriteBlocks_DMA() in module stm32f4xx_hal_sd.c starts the DMA transfer before it configures the SDIO controller for the block transfer. I find this odd, but the DMA read function is structured the same way and it works.

So focusing on this information, any assistance would be appreciated.

George

[waclawek.jan]

DMA writes to the memory card fail. By placing breakpoint in the DMA ISR routine HAL_DMA_IRQHandler() (module stm32f4xx_hal_dma.c) the DMA write operation is failing with the FIFO error bit set (register DMA_HISR, bit FEIF6).

So, it's not SDIO's FIFO you are talking about.

Do you have FIFO in DMA enabled? (Check Cube's code, or read out and observe the DMA registers). If not, you can safely ignore the FIFO error, and, if the interrupt-on-FIFO-error is the problem, it can safely be disabled (or never be enabled at the first place).

If FIFO is enabled and FIFO error occurs... well, then I don't know (it would mean the memory-side port of DMA could not fill the FIFO fast enough to keep up with the peripheral, and that sounds like serious depletion of the mcu's resources at the source memory's bus, or DMA itself).

Disclaimer: I don't use Cube and I don't use SDIO.

JW

[GJohn]

Thank you Jan. Your response is concise and to the point. Unfortunately, it doesn't resolve my problem.

Yes I do have the DMA FIFO enabled. Based on the processor reference manual (RM0090), it appears FIFO mode enabled is the preferred mode for DMA operations.

The FIFO error bit indicates either a overrun or an underrun. There needs to be a handshake between the SDIO and DMA controllers to transfer data. I suspect I have something configured incorrectly and the transfer isn't taking place. But so far, nobody has been able to help me.

I also found an intriguing note buried in the processor errata doc (ES0206) section 2.12.1, page 31.

It says: "Do not use the HW flow control. Overrun errors (Rx mode) and FIFO underrun (Tx mode) should be managed by the application software." This section refers to the SDIO controller. No information is offered about how the application software should manage this issue.

I've tried testing the SDIO flow control bit both on and off. No luck in either state.

George