SMT32F0 SDHC card throuhg SPI and FatFs

[DKarc]

Good evening everyone,

I was't expecting that communication with SDHC Card through SPI will be so difficult. I would like to log data from my existing system , which is using SMT32F0, on SDHC Card. I have ready connection though SPI but on the Net it is hard to find even initialisation sequence of this card.

Does you guys know about any example, library or tutorial about it?

My chain is: STM32F0 <--> FATFS <- (here chain is broken) -> SPI <--> SDHC.

BR, Daniel

[Tesla DeLorean]

I don't have the F0 HAL libraries loaded, most have support for an Adafruit shield with SPI MicroSD card

STM32Cube_FW_F1_V1.8.0\Drivers\BSP\Adafruit_Shield\stm32_adafruit_sd.c

STM32Cube_FW_F1_V1.8.0\Drivers\BSP\STM32F1xx_Nucleo\stm32f1xx_nucleo.c <- SPI side BSP code

STM32Cube_FW_F4_V1.25.0\Projects\STM32F412ZG-Nucleo\Applications\FatFs\FatFs_uSD\readme.txt <- uses Adafruit on Nucleo

[DKarc]

Dear clive1,

thank you for your help, as usual by the way ;).

Your solution is working, I was using analogue examples from Cube F0 Examples.

If somebody will mount this set in the future, please keep in mind that CubeMX is first trying to utilize FatFs and Later SPI, so if you have some SPI-using code in FatFs init function you have to change Cube's order.

Later you could simply transfer couple functions from nucleo.c file to adartuit_sd.c so you don't need nucleo.c anymore in your project.

At the end of course you have to simply link user_diskio.c functions with BSP functions.

I was using class 10 microSDHC UHS-I card.

Best wishes for Everyone, Daniel

[Tesla DeLorean]

Thanks,

Some of ST's attempts to get a uniform cross-platform / cross-peripheral code base tends to add layers of abstraction and clutter.

A little bit of cut-n-paste refactoring can get it down to it's essence once the quick mash-up is shown to work.

Trap is always that the boss is impressed by the hour it takes to show a proof-of-concept working at the meeting, and confused that it will take some man-days of polishing to get something that won't generate support calls later. And further surprised why we spent all that time and when support calls don't materialize.

[DKarc]

That's correct. All tasks always took more time than expected and usually are done not in the way there are planned to, but like you said, when they start to work don't generate any calls.

Abstractions layers are good - everything is clear because of them, everybody has it's own needs and can adapt it in preferred way.

The most important thing is that everything is always working at the end.