sdcard via sdio in polling / interrupt mode

[kilian2]

Posted on October 14, 2009 at 17:20

sdcard via sdio in polling / interrupt mode

[relaxe]

Posted on May 17, 2011 at 13:07

I had the same issue as you.

However, I only needed SDIO+DMA so I have not dwelved deeper.

[kilian2]

Posted on May 17, 2011 at 13:07

hello

the example for SDIO access to sd-cards from the firmware library (sdcard.c) runs well on the STM3210E-EVAL board. but if the mode is set to ''polling'' or ''interrupt'', block transfers do no more terminate. for this reason, i am wondering whether someone tried these modes and had been successfull.

regards

kilian

[stefanobettega]

Posted on May 17, 2011 at 13:08

I'm using SDIO in DMA mode, but sometimes it lacks some data and driver hangs into SD_ReadBlock or SD_WriteBlock onto this code:

Quote:

while (DMA_GetFlagStatus(DMA2_FLAG_TC4) == RESET)

{}

Looking on TransferError status seems we have a tx or rx buffer under run. It seems that an error interrupt is issued by the SDIO peripheral, it's cleared by the ISR routine but the DMA transfer is not aborted. Maybe I've to check also DMA2_FLAG_TE4 to check for any error and return the correct code.

My code also has three other interrupts: an ADC JEOC running at 11µs with hardware startup provided by TIM2 TRGO, a 50µs interrupt provided by TIM1 and a 1ms interrupt provided by SysTick. Do you think that any of these interrupt could have some kind of impact onto DMA transfers, so that a data loss will occour?

Thanks in advance

[kjepsen9]

Posted on May 17, 2011 at 13:08

Hello,

I had same problem with Primer2 and SD-card in DMA mode.

I had no time to look for the error, please post a solution if you find one

Kasper

[stefanobettega]

Posted on May 17, 2011 at 13:08

Thanks for your replies.

@kjepsen: one possible problem is due to a Cortex limitation: you cannot use DMA accesso to FSMC memory map while using that also in normal access. Check

http://www.st.com/stonline/products/literature/es/14732.pdf

at chapter 2.12. We thought this was the problem, as our DMA buffer (that must be uint_32 aligned), was located in external memory. Placing it into internal memory (faster and accessible in DMA) only partially solved the problem.

@brian.d.myers: your solution will unlock the driver and the application, but will result in transfer error. I'm wondering if this transfer error is a real transfer error or is due to a bug somewhere in my code.

[briand.myers9]

Posted on May 17, 2011 at 13:08

I have had problems using the library code also.

Try this: add a check for TransferError not equal to SD_OK, in the loop where you are stuck.

Also it's probably a good idea to set up the DMA *before* issuing the Read Block command.

Also, try turning on HW flow control, especially if there is a possibility that another DMA usage is preempting the SDIO.

Hope that helps.

[briand.myers9]

Posted on May 17, 2011 at 13:08

@Ste76: Surely it's better to be aware of the transfer error, than to be stuck in an infinite loop? All the ISR does on Rx overrun is set the TransferError flag, so if it can happen, and you're not checking for it, there's your bug. It's your job to abort