cancel
Showing results for 
Search instead for 
Did you mean: 

Need help with STM32L476RG SDIO + FATFS project

KAbis.1
Associate II

I have tried communication through SPI by following a lot of youtube tutorials. As there is no ready made library to take care of this through SPI, I decided to give SD mode a try. I am using the STM32L476RG microcontroller that has the SDMMC peripheral. For now, I am trying a simple mount, open, write and close program. I keep getting a FR_NOT_READY as the return value right at the f_mount function. Also, during code generation from cubeMX, I keep getting the following warning:

  • These IPs still have some not configured or wrong parameter values: [FATFS, Verify the Platform Settings Tab]

Also, please confirm the SD card wiring. I am using it in SD 1bit mode and so, I assume the only wires I had to connect were Data0, CMD, CLK and power lines.

I am using a Sandisk class 10 8Gb microSD card and I am using 1.3.0 cubeIDE version. I have attached my project (STM32L476RG_USARTtest) here.

5 REPLIES 5

Recommend circuit implementation, very short, equal length, ideally no more than a few inches. Pull-ups at the socket's edge. The card detect GPIO can be picked from available pins.

0690X000009kC3UQAU.jpgSorry, not a CubeMX adherent here

>>As there is no ready made library to take care of this through SPI..

Pretty sure this is an SPI based SD Card implementation

STM32Cube_FW_L4_V1.14.0\Drivers\BSP\Adafruit_Shield\stm32_adafruit_sd.c

Though I'm not sure there is an "NUCLEO-L476RG\Application" directory with a FatFs implementation, there are for other STM32 Families, and these would port across.

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

Pay very close attention to Clive's response. I spent hours and hours single stepping code trying to find the problem on an H7A3 and it was H/W. 10K resistors as commonly fitted to SDcard modules are too low. Note also that there is no pullup on the clock signal.

I did use CubeMx on the H7A3 and it generated perfectly workable code once the H/W was correct.

KAbis.1
Associate II

Hi clive1 and Pmath.4,

Thanks for your replies. I apologise for the delayed response. I see that your solutions to this problem are more focused on the hardware than the software aspects. I have been told to work from home because of COVID-19 and have been able to do some minor changes over the past few days in compliance with your suggestions to the best I could - using tools I have at home (solder iron, a multimeter and some other basic tools). As I have explained in this (lengthy) reply, I lack a couple of components but have configured the hardware on the STM32L476RG microcontroller to pretty much to the same thing (Tony Stark cave situation going on here). Please take your time reviewing these modifications and let me know if I am doing anything wrong.

Here is the hardware I am using:

  1. STM32L476RG Nucleo board
  2. CATALEX SD card adapter
  3. Sandisk 8Gb class 10 microSD card
  4. Sandisk 4Gb class 6 microSD card (I wanted to use the 8Gb SD card initially but then used this as an alternative for testing)

The CATALEX SD card adapter is designed for SPI communication. I have included the schematic for your convenience. 

0693W000000VCurQAG.png

First, I disconnected the outputs of the 74ABT125PW buffer from the pins of the SD card socket (CSCONN part number: CTF110919138002) represented on the right side of the schematic. Then, by exposing the soldermask, I soldered jumper wires to be able to tap the connector pins individually.

Instead of using pull up resistors (I don't have any at the moment), I enabled GPIO Pull-up resistors on all pins except the Clock pin. Regarding the value of the resistors, the internal pull up resistors of STM32L4 are about 40 kOhm. To check if the pull-up resistors were working, I inserted an infinite while loop after the initialization functions and checked the voltage of the required pins. They all showed 3.3V and with that, sorted out the hardware.

As for the setup and program, I have included pictures of the configurations. I only had to include the GPIO pull up resistors. I tested the program for both 4bit SDIO and 1bit SDIO. Both seemed to be showing the same error.

SDMMC GPIO configuration:

0693W000000VCvkQAG.png

SDMMC Parameters:

0693W000000VCwJQAW.png

FATFS Set Defines:

0693W000000VCwdQAG.png

0693W000000VCx7QAG.png

FATFS Platform Settings:

0693W000000VCxHQAW.png

Clock Settings:

0693W000000VCxqQAG.png

Ive tried using the 8GB class 10 and the 4Gb class 6 micro SD cards with both 1bit and 4bit interface. No luck there too.

PMath.4
Senior III

Have you set up a card detect pin? I think the generated code needs this and I've just noted the error you get in your first post

"These IPs still have some not configured or wrong parameter values: [FATFS, Verify the Platform Settings Tab]"

This shouldn't happen and is probably related to the card detect issue. Set any pin as an input in CubeMX and then in the FATFS platform setting allocate this pin as the card detect.

If you can wire this do it. Otherwise chase references to that pin in the generated code and patch the code so that it always returns card-detected. I think the generated code has some "user code" blocks so you can do this in a way that CubeMX doesn't overwrite

Hope this helps

KAbis.1
Associate II

Hey,

So I tried a couple of things. I initialized a random GPIO pin as Input and selected it as the Detect_SDIO. I wasn't familiar with the mechanism of that pin - if it had to be pulled low or high to show that a card had been connected. On further investigation, I found that the 9th pin on the microSD card connector is a mechanical switch that would be shorted to VSS (GND) when a card was inserted. So, I figured the Detect_SDIO pin should be pulled low. Since that pin was associated with the BSP_SD_Init() function, I used the debugger to step over lines of code until I got to the BSP_SD_Init function to check the return value of res. Finally, got it working (FR_OK at BSP_SD_Init) but on reaching f_mount(), it would return a FR_DISK_ERR. All this was in 4 bit wide bus.

I randomly decided to use the same configuration with 1 bit mode and all of a sudden it worked! Was able to create and write text into a .txt file. This is good progress in terms of showing that everything works at the higher level, but I still need to be able to perform a 4bit communication for higher speeds.