CubeMX 4.22.1 and SD card FatFs problem

[Costas Papachristou]

Posted on October 25, 2017 at 15:45

Hi, I'm currently trying to make SD card work with FatFS on a custom made PCB with STM32F429. I create the init files with CubeMX 4.22.1 and although I set the SD interface to be 4 bits long, I find this code in the stm32f4xx_hal_sd.c

/* Default SDIO peripheral configuration for SD card initialization */

  Init.ClockEdge           = SDIO_CLOCK_EDGE_RISING;  Init.ClockBypass         = SDIO_CLOCK_BYPASS_DISABLE;  Init.ClockPowerSave      = SDIO_CLOCK_POWER_SAVE_DISABLE;  Init.BusWide             = SDIO_BUS_WIDE_1B;            // <--- shouldn't this be SDIO_BUS_WIDE_4B ????????  Init.HardwareFlowControl = SDIO_HARDWARE_FLOW_CONTROL_DISABLE;  Init.ClockDiv            = SDIO_INIT_CLK_DIV;

Also, the same thing  appears in MX_SDIO_SD_Init function created by CubeMX in main.c

/* SDIO init function */

static void MX_SDIO_SD_Init(void){

  hsd.Instance = SDIO;

  hsd.Init.ClockEdge = SDIO_CLOCK_EDGE_RISING;  hsd.Init.ClockBypass = SDIO_CLOCK_BYPASS_DISABLE;  hsd.Init.ClockPowerSave = SDIO_CLOCK_POWER_SAVE_DISABLE;  hsd.Init.BusWide = SDIO_BUS_WIDE_1B;               // <--- shouldn't this be SDIO_BUS_WIDE_4B ????????  hsd.Init.HardwareFlowControl = SDIO_HARDWARE_FLOW_CONTROL_DISABLE;  hsd.Init.ClockDiv = 32;

}

I'm asking this because HAL_SD_ConfigWideBusOperation (found in bsp_driver_sd.c) fails with error despite correcting these 2 mistakes, so I wonder if more mistakes are present that prevent SD card from initializing correctly.

I have also worked in the past with Atmel AVR and fatfs with success, so this is not the first time I have designed PCB or dealt with fatfs. Any clues?

Thanks

Costas

[Tesla DeLorean]

Posted on October 25, 2017 at 17:55

You must start comms with the card at 1-bit 400 KHz, read the card details/modes and then it switches to 4-bit 24 MHz or whatever at a later stage of initialization as appropriate.

[Costas Papachristou]

Posted on October 25, 2017 at 21:11

Thanks for the reply, so the problem must be something else. I haven't used/enabled DMA or interrupts for SD card and all initialization code is done with CubeMX and the code related to FatFs is:

FATFS_LinkDriver(&SD_Driver, '');      // <-- I've tried replacing empty quotes with SDPath or '0:', but it didn't work either

              fr = f_mount(&FatFs,  '', 1);        fr =f_open(&Fil, 'MTIME.TXT\0', FA_WRITE | FA_CREATE_ALWAYS);     // Create a file                        f_write(&Fil, 'ABCDE', 5, &bw);         f_close(&Fil);                      FATFS_UnLinkDriver(SDPath);

I also lowered the clock by setting the divider to 4 and 32 but no luck again. I also call MX_FATFS_Init() before this code.

While debugging the code I found the the problem is at BSP_SD_Init(), and specifically at HAL_SD_ConfigWideBusOperation(&hsd, SDIO_BUS_WIDE_1B) that doesn't return HAL_OK, if(hsd->SdCard.CardType != CARD_SECURED) is the exact point of failure.

Tomorrow I'll connect the logic analyzer and see if I can find something.

Meanwhile any advice would be greatly appreciated :)

*P.S. I also tried another SD card but no luck :(

[Tesla DeLorean]

Posted on October 25, 2017 at 23:20

When troubleshooting these things I tend to discard the upper layers and focus on the block IO code. ie what DISKIO.C is calling.

If I can't read blocks reliably the entire FatFs implementation is going to fall over and die. If reads validates I move on to writes.

I have pull-ups on the D0..3 and CMD pins at the socket, and on the Card Present pin of the socket.

[Costas Papachristou]

Posted on October 27, 2017 at 08:57

I looked at the signals with the logic analyzer and scope and they seem to be OK (signal level OK, not much ringing). However, I see that the SD card is not being detected.

if(hsd->SdCard.CardType != CARD_SECURED)       <-- This part of code is in stm32f4xx_hal_sd.c

In debugging mode hsd->SdCard.CardType =0, while CARD_SECURED=3

but I don't know why. I also put breakpoints in diskio.c but it seems that the program doesn't get into this part of code, probably because initialization fails. I need to dig deeper into this...

[Costas Papachristou]

Posted on October 29, 2017 at 21:19

Hello again,

After a lot of debugging I found out that there's a problem with the clock signal of the SD card. There are times that this signal is very messy and all over the place (looks like a problematic oscillator); this is when the SD card won't work (but other peripherals like GPIO and UART work fine). Other times, this signal is crystal clean, then the card works fine. I mean that when I connect the battery the SD card clock signal might me wrong, but after some pushes of the reset button the clock signal 'transforms' to a good one. Could it be a code initialization issue?

[Costas Papachristou]

Posted on November 02, 2017 at 15:11

OK, it turned out to be the dirty SD card socket pins that made the mess. Cleaned it with flux remover and now works fine at full speed and 4-bit interface. Thank you all for your help :)