Skip to main content
Costas Papachristou
Costas Papachristou
Associate II
October 25, 2017
Question

CubeMX 4.22.1 and SD card FatFs problem

  • October 25, 2017
  • 5 replies
  • 2130 views
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

    This topic has been closed for replies.

    5 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    October 25, 2017
    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Costas Papachristou
    Costas PapachristouAuthor
    Associate II
    October 25, 2017
    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
    Tesla DeLorean
    Guru
    October 25, 2017
    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Costas Papachristou
    Costas PapachristouAuthor
    Associate II
    October 27, 2017
    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
    Costas PapachristouAuthor
    Associate II
    October 29, 2017
    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
    Costas PapachristouAuthor
    Associate II
    November 2, 2017
    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 :)

    Terms & ConditionsAccessibility statement