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.

[Tesla DeLorean]

Posted on January 18, 2018 at 16:48

The SDIO/SDMMC drivers should handle this seamlessly. The physical interface is reliant on correct connectivity, and will likely have issues if the data bits skew with respect to each other, or lack pull-up at the card. If you have ringing on the signals you might want to consider series resistors also.

[con3]

Posted on January 20, 2018 at 12:45

Its odd, because I set it to 4 bit sdio in cube, but I still only see D0 doing anything with an oscilloscope. all lines have the required pullups, etc.

[Mario Popovic_2]

Posted on January 19, 2018 at 08:49

Hello,

Have you tried to setting the Pull-up on the GPIO Pins for the SD interface? I had simmilar problem on STM32F767 and this helped.

Regards,

Mario

[con3]

Posted on January 20, 2018 at 12:46

I have pullups on all the lines. It works, although I can only see D0 doing anything. All the other data lines are dead. I used cube to set it to 4 bit sdio

[Mario Popovic]

Posted on January 20, 2018 at 12:57

Have you tried to debug through the driver to see exactly where it gets stuck? Are you using FATFs? Which part are you using?

The reason you see only D0 doing something is because on reset the SD card is in 1bit mode over which it then needs to be configured in 4-bit mode. This would imply that setting it to work in 4-bit mode is not working. Mabe the SDIO clk is too high?

Regards

[Mohammad A]

Posted on January 20, 2018 at 14:39

Don't touch the code generated by cubemx, just lower the sd clock. That should be enough, at least for me it solved this issue.

[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.

[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!