microSD SPI STM32U575 Implementation

[f3l1xa88077]

Hiya. I’m working on a project that writes to a microSD card over SPI using an RTOS (ThreadX in this case). I’ve had a bit of trouble implementing it over the weekend since I’ve seen little/no support for SPI on FileX and I’ve had issues porting over FatFs SPI code over to this project. Looking for some help and guidance with this! I’m not experienced with FileX or FatFs, so the solution could be pretty simple.

With FileX, I can initialise but cannot mount the drive (memory pool allocations has been large enough). I used this custom library for the SPI implementation: 

With FatFs, I was also able to initialise but could not mount the drive.

 

Again, I am pretty new to this stuff, so a series of steps to implement and identify the problems would be greatly appreciated. I can figure out the rest of the code (like writing and reading), I’m just struggling with initialising and mounting.

[AScha.3]

HI,

Why not use the sdmmc interface, the standard for SD-card?

[f3l1xa88077]

I had done this on a previous version and got it working on SDMMC, but because of pin availability I was only able to spare SPI.

 

Edit: I only need this to work on this version (just needs to function). No need to make it a long-term solution.

[AScha.3]

Well, I can't tell much about SPI for filex etc, because I never used SD-card without sdmmc.

So it's more a bad design decision to not use sdmmc on a chip that has it. If doing anything super cheap, it's a different story.

So again: why waste your time on this bad design, if you know, it's bad and don't want to use it in future?

Just for fun?

About pin availability: at first set the pins you need for complex function, like USB or SD, then other pins for... whatever. Not the other way round.

Just from my experience with SD-card: mount not working at all,  most times indicating a hardware problem, no access to data from device possible. So check signal on clk and data lines, what's really going on there, with a scope.

[f3l1xa88077]

Thanks for the insight,

The reason I’m only using SPI on this specific version is for a debugging tool. The final version will be remote/autonomous, so there is no need for a microSD when when I cannot access it. I opted for the chip to be used on the final version (low-pin count) because if everything worked, a transition between this version and the next would just be a matter of disabling that SPI line. If I selected a completely different chip to free up space for SDMMC, then I’d need to re-work my PCB layout and basically start over for the next version.

I decided to use SPI for a microSD card because I saw the link in the post using SPI on FileX, and others porting FatFs (where SPI to SD is possible). I’ve just had issues with the implementation.

Hope this gives some context.