2014-07-15 10:46 PM
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)Thx2014-07-16 12:11 AM
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.2014-09-16 08:00 AM
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 tipAlberto2015-01-09 08:52 AM
Hi,
Apparently it's a known issuethat ''Non-DMA mode'' results in random underrun errors when writing. You can refer to this forum posts: , that may help you. Regards, Heisenberg.2015-01-12 02:36 PM
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.Jason2015-01-14 01:57 PM
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.cstm324xg_eval_sd.hCheersJason2015-03-25 02:36 PM
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: 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?