SdFormatter support for ESP32 XTSD

[mikeysklar]

The Adafruit XTSD Breakout ships with a filesystem format that causes ESP32 based boards to fail reading it.

forum issue

A simple work around would be to format the card with another board (eg. RP2040) which works.

This PR only touches the example/SdFormatter.ino sketch to allow ESP32 based boards to re-format the XTSD drives.

• Added an ESP32 slow-clock (1 MHz) fallback to initialize XTSD/Zetta cards when normal init or CMD9 fails.
• Disabled flash-erase on ESP32 since XTSD/Zetta cards do not support the erase command.

+------------------+-----------------------------------------------+
| Category         | Details                                       |
+------------------+-----------------------------------------------+
| Storage Module   | Adafruit XTSD 512MB                           |
+------------------+-----------------------------------------------+
| Board #1         | Adafruit Feather ESP32 V2                     |
+------------------+-----------------------------------------------+
| Board #2         | Adafruit Feather RP2040                       |
+------------------+-----------------------------------------------+
| Arduino IDE      | 2.3.6                                         |
+------------------+-----------------------------------------------+
| SdFat Library    | Adafruit Fork 2.3.54                          |
+------------------+-----------------------------------------------+
| ESP BSP.         | SPI 3.3.3                                     |
+------------------+-----------------------------------------------+

[mikeysklar]

@hathach -

This failure is unrelated to this PR.

CI is failing on SdInfo.ino because the RP2040 BSP ships its own SdFat.h. The CI script uninstalls the repo’s SdFat fork. SdInfo is then compiled against the BSP version, which I think is causing the mismatch.

[mikeysklar]

@hathach - Thank you!

[hathach]

@mikeysklar I think we should make an seperated example let say: SdFormatter_esp32, since this example is from upstream https://github.com/greiman/SdFat, modify this can make it harder for us to sync with upstream in the future (have to resolve conflict over time).

[mikeysklar]

Sounds good. I'll replace rollback SdFormat to as it was and make create a SdFormat_esp32 example.

I'm guessing this could even be resolved in future ESP IDF releases as their filesystem behavior changes.

[ladyada]

is this ESP32 specific or fast-SPI specific? if so maybe just have it always try slower/retries no matter the platform?

[mikeysklar]

@ladyada - That is a good thought. In this case it is not only a speed thing. The XTSD comes pre-formatted with a FS that the ESP32 cannot tolerate. SdInfo fails to read it. It has issues with FAT size, alignment, BPB fields.

Running SdFormatter on the XTSD with a Feather RP2040 sets up usable filesystem that the ESP32 boards are fine with (SdInfo runs).

This PR ignores those FS issues for ESP32 only so it can be reformatted. Otherwise uses will need another architecture (RP2040, nRF52, M4, etc.) to format the XTSD flash.

We could consider adding a ignore-current-fs flag that could apply to all chips with SdFormatter. It would overlook FS format and include the slowdown override. It can remain disabled by default, but when enabled allows any arch to format without a bunch of FS checks.

[mikeysklar]

Reviewing this PR (it has been week since I've looked at it) the slowdown for all chips if CMD9 fails as @ladyada suggested makes more sense.

[mikeysklar]

@hathach - I think we can dump PR #42 for PR #44 which is universal architecture compatible and removes all ESP32 specific references.

This adds a universal fast→1 MHz fallback for SD init and sectorCount() to improve compatibility with XTSD/Zetta and other timing-sensitive cards. Tested on Feather RP2040 and Feather ESP32 V2, with normal SD cards unaffected.

[hathach]

superseded by #44