Skip to main content
JC Lebreton
JC Lebreton
Associate III
February 13, 2018
Question

STM32H7 - SDMMC not working

  • February 13, 2018
  • 4 replies
  • 4239 views
Posted on February 13, 2018 at 13:22

Hi

I'm having quite an issue while using the FatFs on a SD card.

I configure everything on the Cube following this tutorial :

https://www.youtube.com/watch?v=kRhF44v2ezM

  

I'm kinda lost, and i would like some support or some clues to go deeper and make it work.

I'm not planning on using an SPI connection but the SDMMC proposed by CubeMx.

For now only the initialisation doesn't return errors. any other functions lead me to differents error.

I can some documents if needed 

hope some of you could help me.

thanks in advance

#stm32h7-sdmmc #stm32h7
This topic has been closed for replies.

4 replies

Amel NASRI
Amel NASRI
ST Technical Moderator
February 13, 2018
Posted on February 13, 2018 at 14:30

Hi

jean_camille.lebreto

‌,

Did you tried using the examples available in the STM32CubeH7 package?

You find examples using both FatFS and µSD underSTM32Cube_FW_H7_V1.2.0\Projects\STM32H743I_EVAL\Applications\FatFs.

-Amel

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
JC Lebreton
JC LebretonAuthor
Associate III
February 13, 2018
Posted on February 13, 2018 at 15:30

In fact i did !

To give some more information :

I'm actually working on a Nucleo-STM32H743ZI, and have no µSDport on it. (no Shield) 

I'm trying yo use 1wire SD

I'm using standard wire and pull ups resistor (43kOhm) on pin CMD and D0 

At the moment the function : 

BSP_SD_INIT();

but anyother functions from FatFs doesn't work! 

for exemple f_mount return error FR_NOT_READY

I'm starting to think that my issue is purely hardware (connection, pull up, wrong pinout etc...) 

I'm investigating and gonna try on the STM32F7-eval board.
Tesla DeLorean
Tesla DeLorean
Guru
February 13, 2018
Posted on February 13, 2018 at 17:29

Not ready suggests you have code in there looking for the socket's Card Detect pin.

Should be trivially easy to wire a full 4-bit SDIO from a NUCLEO-144, along with a GPIO for Card Detect

0690X00000604NmQAI.jpg0690X00000604NrQAI.jpg

3V3 Socket socket here

VCC - 3V3

GND - GND

D0 - PC8

CMD - PD2

CLK - PC12

D3 - PC11

D2 - PC10

D1 - PC9

CD - GPIO PG2 or PG3 close

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Torsten Jaekel
Torsten Jaekel
Associate III
June 6, 2018
Posted on June 06, 2018 at 08:29

My experience with SDMMC1 on STM32H7 NUCLEO:

1. make sure the ClockDivider is not too small (with flying wires, I use hsd1.Init.ClockDiv = 96;

 

    (try a bit, I saw that CMDs on SDIO can fail if too fast)

2. check what is the PCLK soure (where to get the SDMMC clock from):

    what is the PCLK source and frequency? I use PLL1 (PLL2 seems to fail for SDMMC1)

3.  Make sure, all the memory and buffers used by SDMM1 are really

just on AXI SRAM

(D1).

    

SDMMC1

cannot

access all memories, e.g. not D2 or D3! (see the bus matrix in datasheet).

     Check your linker script where .data, .bss will be linked.

4. When you have caches enabled, you use DMA - make sure to configure MPU, to use cache maintenance

 

     functions (Clean and Invalidate)

I had similar issues to bring up SDMMC1 and FatFS but my main faults where these:

a) SDMMC1 tried to use D2 or D3 buffers - DMA engine will hang, FatFS will see garbage ...

b) caches used but not properly updated for 'non-coherent' DMA (even all data was transferred by DMA - the MCU (FatFS) sees still the old cache content, e.g. MBR, FAT does not look reasonable for FatFS because cache was not updated (or when writing you corrupt the filesystem on SDCard!)

So, check caches, cache policies and maintenance and where are all the buffers (used by FatFS) are located and if SDMMC(1) can really access these memories (just AXI SRAM, D1).

It works fine for me now after fixing these issues.

Torsten Jaekel
Torsten Jaekel
Associate III
June 6, 2018
Posted on June 06, 2018 at 08:41

BTW:

there is a macro in FatFS source code:

ENABLE_SD_DMA_CACHE_MAINTENANCE=1

 

Make also sure not to enable, not to use this USE_SD_TRANSCEIVER (there is a feature to talk to SD via an external chip for level and protocol translation).

Also to bear in mind: SDMMC might have the option to use this DelayBuffer (a HW block to trim timing). I guess, I have not enabled, not in place fore me, but maybe your project, config uses DelayBuffer involved in SDMMC but it is not properly set/configured.

Torsten Jaekel
Torsten Jaekel
Associate III
June 6, 2018
Posted on June 06, 2018 at 08:45

My quick suggestion:

try to use only AXI SRAM (D1) for all .data, .bss (buffers, FatFS structures, variables ...).

If it still fails - check if you use caches enabled the SD DMA functions and check if the cache maintenance is enabled and done. Check also the MPU enable (e.g. set entire AXI SRAM/D1 region as 'write-through', don't use the default WBWA).
Terms & ConditionsAccessibility statement