Skip to main content
jasonp4113
jasonp4113
Associate III
July 16, 2014
Question

Cube F4 v4.3 and SDIO SD_TX_UNDERRUN error

  • July 16, 2014
  • 6 replies
  • 1332 views
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

    This topic has been closed for replies.

    6 replies

    jasonp4113
    jasonp4113Author
    Associate III
    July 16, 2014
    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.

    alberto239955_stm1_stmicro
    alberto239955_stm1_stmicro
    Visitor II
    September 16, 2014
    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
    jasonp4113Author
    Associate III
    January 12, 2015
    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
    jasonp4113Author
    Associate III
    January 14, 2015
    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
    evan23
    Associate II
    March 25, 2015
    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&currentviews=1757

    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?

    Terms & ConditionsAccessibility statement