Has anyone a working 4-bit SDIO FATFS example that they can post for a 144-pin H7?

[PMath.4]

I'm despairing of ever getting 4-bit SDIO FATFS working on a 144-pin H7. I've tried modifying example code for the various eval and discovery boards, building from scratch with CubeMX, etc. and nothing works. The HAL code seems to read the card details OK but then stalls waiting for a SDIO status return. The BSP library code helpfully sets the timeout delay to 0xFFFFFFFF so it doesn't even timeout and call the timeout error routine.

SPI FATFS works perfectly but even 1-bit SDIO hits the same problem as 4-bit. The USB host Mass storage/FATFS example also works perfectly.

I've tried this both on Nucleo and custom PCBs and there is absolutely no issue with pin conflicts. The Nucleo even helpfully breaks out the SDIO pins.

A working example would be very gratefully appreciated - has anyone actually got this working?

IDE can be CubeIDE, Atollic or SW4STM32

[Tesla DeLorean]

Definitely had it working on the NUCLEO-H743ZI boards, don't have H7A3 boards as they always seem to be out of stock

https://community.st.com/s/question/0D50X0000BrEAhdSQG/cant-resolve-issue-with-stm32h7-using-sdmmc-and-micro-sd-card

Generally validate these things by writing test patterns to entire cards, and reading back, figure several 100 GB's

[PMath.4]

Thanks for the link. It seems the H7 are uniquely sensitive to the electrical environment of the SDIO connections. I swapped the 10K pullups on my SDcard module for 100K (didn't have any 47K) and made up some 5cm Dupont leads and now it works on a Nucleo-H7A3. Looking at the schematic for the STMH7B3 discovery board, there is no pullup on the clock signal so I have removed that one completely. The disco also has HSP051-4M10 connected on all the lines. This is a 4-channel ESD array with a rail to rail architecture designed specifically for the protection of high speed differential lines.

Why this is needed when the lines aren't differential and not remotely high speed is interesting?

It seems there is something not quite right in the electrical design of the SDIO I/F on the H7 chip. F7 and F4 don't have this problem running the bus at the same speed.

The SDIO clock is 25MHz so not remotely high speed and I can run an SPI connection to an SDcard completely reliably with 15cm leads, any value pullup (or none), at 25MHz so why if the H7 SDIO so sensitive? when SPI isn't?

[Tesla DeLorean]

Well the pin driver architecture on the H7 is different, and 4-bit mode is going to be particularly sensitive to skewing

[PHlin.1]

Using NUCLEO-H7A3ZI-Q board and get it to work without any problems with STM32CubeIDE 1.3.0 just by enabling SDMMC1 and FATFS in CubeMX. It works even with internal pull-ups, don't using external as that board doesn't have SD Card slot on it, had to solder it myself. It's running reliable at 80MHz / 3.3V.

Petr

[Tesla DeLorean]

Fixtured the QSPI ZIF, but the SD dongle worked fine

[magene]

@PHlin.1​ I've been bashing my head against the wall trying to get FatFs working on the same Nucelo-H7A3AI-Q board. I've tried a variety of ways including your approach using Stm32CubeIDE 1.7 and enabling SDMMC1 and FatFs in CubeMx but without success. Is there any chance you can make your working code available?

Thanks