STM32duino - SDIO for onboard SD card (experimental)

[Bob-the-Kuhn]

This PR adds the ability to use the SDIO module to access the onboard SD card for the boards that use the STM32duino platform/library.

This has been tested on a Black STM32F407VE board.

---

This should be considered experimental until tested on other boards.

---

ITEMS FOR DISCUSSION:

• There is currently a soft SPI method of accessing the onboard SD card. I'm not aware of a need to have both methods. Should one be deleted? Which one?
• The LPC176x boards have the option of accessing the onboard SD or the LCD's SD. Does that need to be included in this PR? Or a separate PR?

[Bob-the-Kuhn]

Once again, I'm confused.

Hope this isn't a "never mind..."

I was assuming that all STM32F4xx boards that used the port/pin method were STM32duino but ... I see a few that already made use of SDIO_SUPPORT which was available only to the Maple/STM32GENERIC platform/library.

Wish there was a magic wand that could move all the STM32 boards to one camp or the other.

[thinkyhead]

Looks pretty comprehensive. I'll have a closer look at it in the morning.

[Bob-the-Kuhn]

The pinsDebug_list.h change fixes a strange compile problem I see every time I enable M43. I'm wondering if there is something strange on my PC because no one else has reported it.

---

All the SDIO pin defines in pins_BLACK_STM32F407VE.h are not used when SDIO_SUPPORT is defined. The SDIO pins are hard wired in the code.

I should put something in there in case there is a board that uses just the one bit SDIO mode. Right now it always puts all four data pins into SDIO mode. Some boards may use the other three for non-SDIO purposes.

[thinkyhead]

The pinsDebug_list.h change fixes a strange compile problem

You've discovered the bug. I believe this may be caused by this file being included twice in pinsDebug.h, but I'm not really sure. The workaround I used for this was to add blocks like this to the top for pins that it complained about.

#if !PIN_EXISTS(E7_MS1)
  #undef E7_MS1_PIN
#endif

Another thing that can throw things off is if some header were to define LED_GREEN then it could get expanded by PIN_EXISTS(LED_GREEN) into –for example- "LED_D2" instead of just passing the literal string LED_GREEN resulting in "LED_D2_PIN" instead of "LED_GREEN_PIN."

[thinkyhead]

Following up on the issue, I discovered that quirks in the way C++ macros get expanded makes PIN_EXISTS susceptible to early expansion. In this example the expansion is bad:

#define MY_COOL 666
#define MY_COOL_PIN 123
#if PIN_EXISTS(MY_COOL)
  #error "The line above will throw an error."
#endif

This is because MY_COOL is getting expanded early. There are ways to suppress symbol expansion in macros, but the only way to make PIN_EXISTS immune was to revert it to a simpler form. This simplifies the pinsDebug_list.h file a lot, allowing us to remove a lot of #undef lines that were there to work around the issue.

[Bob-the-Kuhn]

commit 0280624 changes:

• Sd2Card_sdio_stm32duino.cpp - added guard to make sure this module only compiles if ST's STM32 library/platform is used.
• pins.h & boards.h - 1) complete BTT name change and 2) add/correct environments where obvious
• pins_BLACK_STM32F407VE.h - changed so that SDIO mode is not used if LCD or CUSTOM_CABLE options are selected
• pins_STEVAL_3DP001V1.h & pins_FLYF407ZG.h - added SDIO support
• pins_BTT_SKR_PRO_V1_1.h - added soft SPI support for the onboard SD card. SDIO is not connected to the SD card connector on this board.
• pins_ARMED.h - added link to web site. I had a devil of a time finding info on this board so I figured this might save time for someone else.

---

There are only three boards that can make use of the new module. I've been able to test on two of them.

Here's a list of all the current STM32F4 and STM32F7boards in Marlin along with my notes:

      BOARD                   PLATFORM      NOTES
                           
    BOARD_ARMED               STM32duino    no onboard SD
    BOARD_BLACK_STM32F407VE   STM32duino    tested
    BOARD_BTT_BTT002_V1_0     STM32duino    SDIO not supported in hardware
    BOARD_BTT_GTR_V1_0        STM32duino    SDIO not supported in hardware
    BOARD_BTT_SKR_PRO_V1_1    STM32duino    SDIO not supported in hardware
    BOARD_FLYF407ZG           STM32duino    not tested
    BOARD_FYSETC_S6           STM32duino    no onboard SD
    BOARD_RUMBA32             STM32duino    no onboard SD
    BOARD_STEVAL_3DP001V1     STM32duino    tested                         

    BOARD_THE_BORG            STM32GENERIC  
    BOARD_VAKE403D            STM32GENERIC  
    BOARD_STM3R_MINI          STM32GENERIC
    BOARD_CHITU3D             STM32GENERIC
    
    BOARD_MKS_ROBIN2          no environment
    BOARD_LERDGE_X            STM32GENERIC  
    BOARD_LERDGE_K            STM32GENERIC  
    BOARD_GENERIC_STM32F4     STM32GENERIC  

[Bob-the-Kuhn]

I think this PR is ready to be merged. I have no further features to add and all boards that can make use of this have been updated.

[ManuelMcLure]

commit 0280624 changes:

Line 391 of pins.h:

#elif (MB(BIGTREE_SKR_V1_4_TURBO) || MB(TT_SKR_V1_4_TURBO))

I think the second should be BTT_SKR_V1_4_TURBO (missing the B)

[Bob-the-Kuhn]

pins.h has been corrected.

[jmz52]

Great work!
My two coppers is to use #if defined(HAL_SD_MODULE_ENABLED) as a safeguard for sdio code and prerequisite for SDIO_SUPPORT if HAL_STM32 is used

[thinkyhead]

Rather than keep two names for boards, I've changed it to standardize on the shorter name variant for all boards.

[xC0000005]

BOARD_CHITU3D STM32GENERIC
BOARD_LERDGE_X STM32GENERIC
BOARD_LERDGE_K STM32GENERIC

These three should be using STM32DUINO. I'll see if I can get them building with this soon.

[BastR]

So if I understand with my limited knowledge, I should be able to access the onboard SD card on a SKR PRO? because I just flashed and I still don't have access to the onboard SD card :(.

SKR PRO with TMC5160 driver and full graphic smart controller

[Bob-the-Kuhn]

@BastR - you should be able to access the onboard SD card if are you are NOT using a SPI based LCD.

Make sure you have the following setup:

Configuration.h
    #define SDSUPPORT
    #define SD_CHECK_AND_RETRY
CONFIGURATION_adv.h
    #define SDCARD_CONNECTION ONBOARD

If this doesn't fix it then open an issue and do the following:

1. Capture the result of issuing a M20 command
2. ZIP and post the following:

• The capture
• Configuration.h
• CONFIGURATION_adv.h
• pins_BTT_SKR_PRO_V1_1.h

[Keltere]

Like written in this comment on skr pro 1.1 it isn't working if there is even a check of the spi lcd presence.
Some code must be removed in the pin file in order to make it work but still it won't mount the sdcard on either windows or linux.

[thinkyhead]

if there is even a check of the SPI LCD presence

Marlin only looks for hardware for which support has been specifically compiled in. If Marlin is compiled for an i2c LCD or no LCD it doesn't do any checking for SPI LCDs.