4 bit SDIO doesn't work although 1 bit SDIO works SDCARD

[con3]

Posted on January 18, 2018 at 14:37

Hey everyone,

I have a quick question concerning the 4 bit sdio sdcard implementation. The 1 bit sdio seems to work perfectly. I have absolutely no issues, although when implementing 4 bit it completely bugs out. Are there any lower level files that the 4 bit uses that the 1 bit doesn't? According to me they should use the same lower level functions and therefore both should work? My question is pretty much do they use the same lower level functions or are there separate functions for each implementation..?

Thanks in advance

#stm32-f7 #sdcard Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Mario Popovic]

Posted on January 20, 2018 at 14:02

So first thing I've noticed is that Cube generates code that defaults to SDMMC_BUS_WIDE_1B

I manually changed this to 4B?

This will not do anything I think, since by default it uses 1B to set the SD card mode to 4B. I'm not sure the driver even uses that field of the structure.

Secondly I can't find any call to HAL_StatusTypeDef HAL_SD_ConfigWideBusOperation(SD_HandleTypeDef *hsd, uint32_t WideMode) anywhere in my workspace.

It doesn't seem like the generated code calls it. it asserts 1B and continues. BSP_SD_Init looks like this:

That's weird, I'm using STM32F767IG and Cube generated this code for me:

/* USER CODE BEGIN BeforeInitSection */

/* can be used to modify / undefine following code or add code *//* USER CODE END BeforeInitSection *//** * @brief Initializes the SD card device. * @retval SD status */uint8_t BSP_SD_Init(void){ uint8_t sd_state = MSD_OK; /* Check if the SD card is plugged in the slot */ if (BSP_SD_IsDetected() != SD_PRESENT) { return MSD_ERROR_SD_NOT_PRESENT; } /* HAL SD initialization */ sd_state = HAL_SD_Init(&hsd1); /* Configure SD Bus width (4 bits mode selected) */ if (sd_state == MSD_OK) { /* Enable wide operation */ if (HAL_SD_ConfigWideBusOperation(&hsd1, SDMMC_BUS_WIDE_4B) != HAL_OK) { sd_state = MSD_ERROR; } }

return sd_state;

}

This may be a bug in CubeMX.

Try my code and see if it works

Regards

[con3]

Posted on January 20, 2018 at 14:33

Thank you, I can atleast see the lines activating now. f_mount returns a no filesystem error so I'll need to debug the lower level drivers, not sure how many errors might be ahead.

[Lars Beiderbecke]

Posted on January 31, 2018 at 20:13

I still have this issue. My SDIO is running at 21 MHz, with divider 0. When I set the divider to 2, the FatFs initialization breaks. If I increase the clock by setting the divider to 0 again, mounting works but reads fail.

Everybody talks about pull-ups, with values ranging from 1K to 47K. Is it possible to use the internal pull-ups instead of external ones?

[Tesla DeLorean]

Posted on January 31, 2018 at 20:53

You need to step back from the FatFs level, it will fail if you don't deliver the data correctly and repeatably, this needs to be addressed at the DISKIO layer. Read/Write indexed data patterns on the card, on a blank one pick some sectors in the middle, and review the data returned. Do some basic validation.

With a divisor of zero the bus clock is SDIOCLK / 2, for SDIO nominally clocking at 48 MHz the bus is running at 24 MHz. A setting of 2 would be SDIOCLK/4

Initialization of the CARD is done at 400 KHz

You ideally want the pull-up at the card interface, if you have short traces the internal STM32 pull-up will suffice.

Do you have external pull-ups? Are you having communications problems? Are the lines ringing? Do you see cross-talk?

I'd use 33K or 47K, you could use 1K, you'll expend more current, and is more aggressive than necessary, and drag VLow higher.

If software can't fix the issue, look at the hardware, connectivity and signal integrity at the card pins.

[con3]

Posted on January 31, 2018 at 21:15

So there are a lot of issues depending on the STM mcu your using and if your using cube.

As Clive has mentioned, you'll need to look at the lower level functions and see where the issues start occurring.

What stm microcontroller are you using? Are you using cube?

Does the open file pass?

[machinehum]

Posted on July 12, 2018 at 02:21

Thanks for the help! I was missing the pullups. Activating internals seems to have worked, will have to fix that with the next spin of the board!