cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L462 + CMSIS V2 + FATFS + SDMMC with DMA not Working

Ravindra Patil
Associate II

Hi,

I am working on interfacing the SD card with the following requirement :

CMSIS V2 + FATFS + SDMMC with DMA on STM32L462.

I have configured the project in CubeMX Version 1.3.0. The CMSIS V2 with FREERTOS has been selected from the CUBEMX configuration and using FATFS system for handling data on SD card.

The SDMMC has been configures with DMA having two separate channels for Rx and Tx.

The f_mkfs is working but after that when i call f_mount it is failing.

Following are my observations:

when the f_mount function is called, as part of this functionality the FATFS reads the data from the SD card. Here the function BSP_SD_ReadBlocks_DMA() is called. In the further debugging it is observed that the read data command has been sent to the sd card by sdmmc and upon response from sd card the read data has been stored into the FIFO of the sdmmc peripheral. But the configured DMA is not at all copying the data from sdmmc FIFO to the buffer and since the FATFS is not getting the data on timeout it is resulting in error.

Played with multiple configurations of DMA but no Luck.

Please help me out since its been long days i am trying to debug and figure out the issue.

Many thanks in advance.

5 REPLIES 5
TDK
Guru

I don't believe SDMMC + DMA has ever worked out of the box with HAL.

If you feel a post has answered your question, please click "Accept as Solution".
Hab Collector
Associate III

Did you ever get an answer for this?

TDK's post is the right answer for this. That means as a minimum you have to analyze, debug and fix the HAL/CubeMX code to make it at least somewhat working. And it's the same with ETH, USB and to a lesser extent everything with HAL/CubeMX.

To be fair it is usually the CubeMX stuff that's most broken.

The HAL examples for the DISCO or EVAL boards tend to have a significantly better chance of working, and being ported onto platforms within the L4 family. There are at least TWO or THREE different SDIO/SDMMC implementations for the L4.

Can't say I've spent a lot of time with FreeRTOS, and this has been flagged as problematic by several, I think one issue is the yielding of the threads at IRQ time, and the general intolerance of the SDIO/SDMMC for wandering off the plot when in the midst of a data transfer.

Typically there are DISKIO driver examples for POLLED, DMA under the Middleware/FatFs directory, and FatFs examples under the Applications directories for the EVAL/DISCO boards.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Hab Collector
Associate III

Thanks all for responding. So before I finished my REV 1 hardware I built a test application using the STM32F746 Disco and the CMSIS V1 RTOS to play with a few things to include FATFS. Once the REV 1 Hardware came I made a bear metal application to test all hardware to include the SDMMC interface - so I know the hardware works and I have the FATFS working with both a bear metal and CMSIS V1 test applications. The actual application that I am developing now on REV1 uses the CMSIS V2 RTOS but the FATFS is not working and fails somewhere in f_open. The SDMMC is configured for SD 4 bits, DMA for TX and RX with global IRQ. The FATFS I configured as I did with the CMSIS V1 app the fixes from V1 app (namely two edits to sd_diskio.c) I applied here. So it should work but doesn't. Are you saying it is because of the CMSIS V2 - from my perspective, unless I missed something, that is all that has changed.