cancel
Showing results for 
Search instead for 
Did you mean: 

Cube F4 v4.3 and SDIO SD_TX_UNDERRUN error

jasonp4113
Associate II
Posted on July 16, 2014 at 07:46

Hi All,

Using the standard Cube (F4 v1.30) HAL_SD drivers, I randomly get the SD_TX_UNDERRUN'' error when writing using HAL_SD_WriteBlocks().

It happens totally at random.

I have tried:

- using older libraries - same result

- Modified SRAM (data source) speed - same ''underrun''

- Modified PLLQ (slower) - same  ''underrun'' 

- Modified ''HAL_SD_WriteBlocks() where it performs the FIFO writes to just write ''SDIO->FIFO = 0'', this actually made it more reliable (especially for 1 block write), but not 100% consistent, and this obviously is unusable anyway.

This points to the fact that the function cannot source data fast enough for the FIFO sink - hence the underrun (I know this is obvious - but why??????)

What DOES work is modifying the ''Init.ClockDiv'' value to (say) '2' from '0' to slow the SD peripheral down from 25MHz (This obviously also slows the transfer rate)

Why can't the STM keep up with the SD write FIFO?

Is this normal?

Has anyone else found this issue?

It happens with all cards I have tried (SD,SDHC,SDXC)

DMA doesn't have this issue (although that's another can of worms using the unmodified HAL drivers)

Thx

6 REPLIES 6
jasonp4113
Associate II
Posted on July 16, 2014 at 09:11

More info:

Using a F205 board and compiling the same code (but for F2) results in the same behaviour.

I found that slowing PLLQ from 5 to 8 fixes the SD_TX_UNDERRUN issue therefore (I think) points to the core not sourcing the FIFO sink fast enough.

Any help or confirmation of this would be helpful.

Posted on September 16, 2014 at 17:00

same problem here on a 32F407 and solved slowing down the clock.

I think I will move to a DMA transfer

 

thank You for the tip

Alberto

jasonp4113
Associate II
Posted on January 12, 2015 at 23:36

Hi All,

Most if not all, of my projects require the SD interface. To date I have had no luck using SD in polled mode (which results in random underrun errors), irrespective of the driver code used.

I would suggest to anyone wanting to use the SD peripheral to use DMA mode exclusively. I thus far have never had an issue with DMA,

The driver code I have been using reliably comes with most discovery boards. Don't bother using the cube versions.

Jason

jasonp4113
Associate II
Posted on January 14, 2015 at 22:57

Hi

I re-read my above post and should clarify:

The BSP for the Discovery boards are good to go as far as accessing SD via DMA. These files hook into the HAL drivers and provide good bandwidth with no (underrun) errors.

I use these BSP files to access the SD via DMA/HAL:

stm324xg_eval_sd.c

stm324xg_eval_sd.h

Cheers

Jason

evan23
Associate II
Posted on March 25, 2015 at 22:36

I have seen all these posts about it working with DMA and not working with polling. However, I can't seem to get the current set of drivers (v1.3 or even 1.4) working with DMA mode. It seems that the interrupts are never triggering. I have checked the interrupt configuration multiple times.

Keep in mind that I've tried all of the things I've tried previously in:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32Cube%20%2b%20F4-Discovery%20%2b%20FatFS&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentvie...

Anyone have any other ideas? Keep in mind that the way I enabled DMA mode was just changing the calls in sd_driver.c from BSP_SD_Write(Read)Blocks() toBSP_SD_Write(Read)Blocks_DMA(), having the DMA interrupts already enabled, etc. Is there anything else missing in that process?