2015-12-08 01:03 PM
I have an STM3240G-EVAL and I'm using the HAL drivers from STM32CubeF4 to access the SD card. It can read data, but it hits this error the first time it attempts a write.
I call BSP_SD_WriteBlocks_DMA(), which calls HAL_SD_WriteBlocks_DMA(), which does a few things and finishes by calling SDIO_DataConfig, as follows: sdio_datainitstructure.DataTimeOut = SD_DATATIMEOUT; sdio_datainitstructure.DataLength = BlockSize[=512] * NumberOfBlocks[=1]; sdio_datainitstructure.DataBlockSize = SDIO_DATABLOCK_SIZE_512B; sdio_datainitstructure.TransferDir = SDIO_TRANSFER_DIR_TO_CARD; sdio_datainitstructure.TransferMode = SDIO_TRANSFER_MODE_BLOCK; sdio_datainitstructure.DPSM = SDIO_DPSM_ENABLE; SDIO_DataConfig(hsd->Instance, &sdio_datainitstructure);Prior to SDIO_DataConfig(), DMA2->HISR is clear, but this call makes both TCIF6 and FEIF6 get set. The result is that the interrupt handler gets called, a FIFO error is detected, and my error callback function is invoked.Why might this failure be happening? I could suspect the hardware, since I've had several complicated issues using other drivers to access the SD card.In case it matters, I use BSP_SD_Init() to initialize the SD card. Also, it works fine in polling mode, as long as I only read/write one block at a time. Writing multiple blocks can get me a SD_CMD_RSP_TIMEOUT error (I'd love to know why that might happen as well, if anyone knows). #stm32f4 #stm32cube #sdio #dma2015-12-08 01:53 PM
One thing that's a potential gotcha is the PLL must be running, as the SDIO uses the Q-Tap at 48MHz, or so. This is true even if you aren't using the PLL to clock the core.
Running the core directly off the HSI/HSE won't make this happen, and the fail-through on the SPL's SystemInit() could leave the PLL off if the selected clock didn't start, or PLL doesn't lock. As it is reading I'm going to assume this isn't your issue. The DMA TC for the write will fire before the FIFO vacates to the SDIO bus.2015-12-08 02:52 PM
My initialization code does set up PLL and uses it as the sysclock source. (The initialization code is copied from a sample project; I am not experienced enough to understand exactly what it's doing.)
2015-12-14 04:07 PM
Solution found!
I had seen other forum posts saying that it's ok to ignore the FIFO errors. I wasn't sure how that applied to me (since the code that checks for errors is part of the driver), but after comparing my code with a sample SD block interface, I removed the error callback function altogether. Apparently in STM32 HAL, BSP_SD_Read/WriteBlocks_DMA() encapsulates waiting and checking for errors, such that implementing HAL_SD_Xfer/Rx/TxErrorCallback() is unnecessary.