[grblHAL/STM32F4xx Issue#123] SKR 2 SDCARD_ENABLE

#1 – dresco 于 2023-05-28

I think it’s just that the current F4 driver expects the SDCard to be interfaced over SPI, whereas on the SKR2 it’s a full SDIO/MMC connection. So not a hardware limitation..

#2 – terjeio 于 2023-05-29

The SKR-2 map was provided by a user and he decided not to add SD card support. I do not own one and at the time it was added I did not have other hardware to test with.

3. Yes, easiest would be use the STM32CubeIDE and set up a new project and use that to generate most of the needed code, then integrating it back into this driver. Jons H7xx repo has SDIO code in place already so that might be a useful reference. What could be an issue is that this driver already has a single lane SPI interface for SD card available, there might be clashes with that that has to be resolved.

#3 – asward 于 2023-05-29

Thanks for the info, I’ll give it a shot.

#4 – terjeio 于 2023-06-02

@asward FYI I have finally added SDIO interface (thanks to @dresco who donated a breakout) as an option to the F7xx driver and is testing it now. It was kind of tricky as I needed the SPI interface option to still be available.
The code changes will be more inline with what is needed for the F4xx driver and might be copied over more or less “as-is”. I will commit the F7xx changes as soon as I am satisfied with the tests.

#5 – dresco 于 2023-06-03

> I will commit the F7xx changes as soon as I am satisfied with the tests.

Cool, I’ll keep an eye out – as I would like to keep the H7 driver as close to upstream F7 as possible.

Most of the aggravation I had with the H7 implementation was related to cache coherency (that wasn’t handled properly in the ST generated code).

#6 – asward 于 2023-06-28

I haven’t given up! But this is more convoluted than I even imagined.

I had built a bare bones sd/fatfs project with STMCubeIDE for the F4. Pulled the relevant middleware and FATFS folders over and did what I thought was right to mitigate sdio vs spi configuration. This is what I thought would be the tricky thing, but turned out to be pretty straight forward. I compared against @terjeio SDIO changes for the F7 and I think I got pretty close (again, not an embedded guy, so trying to stay inline with project best practices as I find them).

The real stumbling block now is that STMCubeIDE v1.12.1 (current as of June ’23) is generating FatFS code and including middleware for v0.12c of FATFS. This seems to be a downgrade from earlier versions of STMCube which were written against at least 0.14. There are a number of ~breaking changes as far as I can see.

I think this would be all here nor there, but the sdcard plugin also seems to depend on at least v0.13. This is based mostly on the configuration defines the sdcard plugin is looking for (FATFS 0.13 change log: Changed heading character of configuration keywords “” to “FF“.)

All this to say – I’m wondering how I should proceed here. Would it work to pull in the F7 code directly and the HAL will take care of it? It seems like STM reverted on purpose but I have no idea why or what affects upgrading would have. I could use an older version of the IDE to get real F4 code. Or I could hack it all in some other way?

Certainly out of my element at this point, but very interested to learn how this typically works and hopefully make a contribution here.

#7 – dresco 于 2023-06-29

> The real stumbling block now is that STMCubeIDE v1.12.1 (current as of June ’23) is generating FatFS code and including middleware for v0.12c of FATFS. This seems to be a downgrade from earlier versions of STMCube which were written against at least 0.14. There are a number of ~breaking changes as far as I can see.

Fwiw, my v1.10 CubeIDE install also generates FATFS support using v0.12c (both F4 and H7 projects). I suspect the FATFS code in the F4 repo was added manually? (I know I had to manually update to later files for my H7 driver).

In your position (assuming default CubeIDE generated file locations), I think I would update the FATFS source under /Middlewares to the later upstream version, and then fix up the generated platform specific files under /FATFS as needed.

Is worth noting that Terje’s file locations for the F7 driver are a bit different to the generated ones, so perhaps that layout is preferred?

#8 – terjeio 于 2023-06-29

> Is worth noting that Terje’s file locations for the F7 driver are a bit different to the generated ones, so perhaps that layout is preferred?

To support both single lane SPI and four lane SPI (SDIO) I decided to refactor both the original grblHAL code and the STM32 library code allowing both to be used. I changed file locations in order to achieve this without duplicating the core FatFS code and thus have the same FatFs version (R0.14) for both. I guess the F7 layout and code can be copied over to the F4 driver “as-is”…

#9 – terjeio 于 2023-07-08

I have managed to get SDIO working with a Nucleo 144 board, with luck it should work with the BTT SKR2.0.
Polling mode is used, DMA mode could be added for speed/performance?
Note that I had to slow down the fast clock to avoid recieve FIFO overflows.