SDIO DMA Data Corruption

daviddavid92 · ‎2010-11-29

Posted on November 29, 2010 at 12:41

picguy2 · ‎2011-05-17

Posted on May 17, 2011 at 14:16

>[The problem] only occurs when high priority interrupts are using the CPU time.

>Reducing interrupt duration cures the problem

I’m sure we both know that ISRs should be as brief as possible. So I am assuming that you removed needed code in an attempt to pin down the problem. I would do the same thing.

No answers here. I do however, have questions which may lead to problem resolution.

Unless the processor sleeps its CPU load is always 100%. High priority ISRs do not change that. Does your high priority ISR all but saturate the FSMC? Cortex ISR processing stores/reloads 8 words every ISR entry/exit. (Except for pending same or lower priority ISRs.) Could these RAM accesses impact DMA? Experiment invoking a frequent do nothing timer ISR.

Have you tried setting max DMA priority on your specific channel? FSMC is much slower than internal static RAM. IIRC, it is also 8 or 16-bit memory. Try setting your FSMC DMA to 8, 16 and 32 bit transfers. How does this change the problem?

Is the data corruption due to missing bytes or trash bytes or some combination? Is the corrupted data what was in the buffer before writing the card?

My STM32/SD card efforts are on the back burner. What stops the card clock (or otherwise prevents corruption) for write data underrun when using DMA?

daviddavid92 · ‎2011-05-17

Posted on May 17, 2011 at 14:16

Hi,

I was careful not to claim a high CPU load for the reasons you state :)

The high priority ISR is in fact writing to the I2S audio interface, so it's running at 44100Hz. It's not doing too much with the FSMC, certainly all code is in internal flash, as are 'C' variables, so I don't think it's doing much at all with the FSMC. But it can take about 50% of the time between audio samples.

The foreground firmware is doing very little, so it's in fact interrupts are just a handy way of keeping everything synchronised.

I haven't tried adjusting DMA priorities etc, I need to read up on the options.

The corrupted data is wierd - it seems to be related to the data being transferred, but in a way that I can't understand. It's almost as if the 70odd pixels are from a different region of the display and rotated through 90degrees, which is completely implausible!!

From other issues I've had with the SDIO stuff, I think data overrun / underrun is not really handled very well. I have wrapped the sector read function with a retry-on-error while() statement, and it does occasionally fail with data overruns. I think with the DMA transfers, the data is transferred to the DMA buffer regardless of whether the data can be transferred on to RAM. There's no 'pause' functionality built in, so you MUST consume the data one way or another.

Will try some of your suggestions - thanks!

Chris.