cancel
Showing results for 
Search instead for 
Did you mean: 

SDIO+DMA FIFO Error (TX Underrun) F4 STM32F417ZGT6

sdellinger
Associate II
Posted on June 04, 2014 at 16:32

The original post was too long to process during our migration. Please click on the attachment to read the original post.
6 REPLIES 6
jasonp4113
Associate II
Posted on September 22, 2014 at 01:52

You may have found a solution to your issue by now, but have you tried integrating the files ''stm324xg_eval_sd.c/.h''

I have had good results with these files using DMA (in conjunction with cube generated HAL SD files) I can xfer (with aggressive clocks) up to 25MB/s (SDXC) with no errors.

(Non-DMA mode although - results in random underrun errors when writing - irrespective of what HAL drivers you use)

Posted on September 22, 2014 at 03:55

One other observation I might make is that the DMA TX (write) operation completes long before the SDIO TX FIFO (on the peripheral) clears to the card. It's important to wait for that to clear before proceeding.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
brubinstein
Associate II
Posted on April 30, 2015 at 17:08

Run into the same problem. Apparently this flag in such case needs to be ignored. Keil example does exactly that. The worst part is that STM doesn't respond nor provide clarification on this issue at all. Their example code doesn't use DMA.

Posted on April 30, 2015 at 18:18

Their example code doesn't use DMA.

You're evidently working with a different set of facts than I am. Because I've been using DMA forever, and fragments of code that I wrote showed up in the HAL/Cube stuff.

The worst part is that STM doesn't respond nor provide clarification on this issue at all.

Front line product support is the work of the distributor and the FAEs. The OP was TL;DR; I skimmed it for useful nuggets, it would take hours to trawl though the detail and someone would need to write a big check.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
craig2399
Associate II
Posted on May 04, 2015 at 20:29

I am using HAL + Cube on a custom board with STM32F405RGTx and I'm experiencing Rx Overruns as described by the OP when reading SDIO via DMA. BTW, I am not having any issues writing SDIO via DMA. I am notified of the overrun in myHAL_SD_XferErrorCallback as triggered here:

void HAL_SD_IRQHandler(SD_HandleTypeDef *hsd)
{

.

.

.

 else if (__HAL_SD_SDIO_GET_FLAG(hsd, SDIO_IT_RXOVERR))

 {

 __HAL_SD_SDIO_CLEAR_FLAG(hsd, SDIO_FLAG_RXOVERR);

 hsd->SdTransferErr = SD_RX_OVERRUN;

 HAL_SD_XferErrorCallback(hsd);

 }

.

.

.

}

The result of this error is that we get stuck in an infinite loop later inside HAL_SD_CheckReadOperation.

HAL_SD_ErrorTypedef HAL_SD_CheckReadOperation(SD_HandleTypeDef *hsd, uint32_t Timeout)
{

.

.

.

 //***** Gets Stuck HERE ******

 /* Wait until the Rx transfer is no longer active */

 while((__HAL_SD_SDIO_GET_FLAG(hsd, SDIO_FLAG_RXACT)) && (timeout > 0))

 {

 timeout--;

 }

.

.

.

}

So, what are some options for handling this? Thanks, Craig
craig2399
Associate II
Posted on May 04, 2015 at 23:05

Ok, I figured out my issue.  I feel a little stupid and embarrassed by this, but the issue was that I was trying to read data from the SDIO via DMA to a buffer in core coupled ram.  Doh!!!  Anyway, there's a little lesson here I suppose.

Craig