SD Card At Startup Fails #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The exercise for the SD Card seems to always fail when a card is already inserted and the unit boots up. If I remove the card and then re-insert it, then the card is seen. I'm documenting this Issue so it does not get forgotten, it is something that needs to be debugged.
Current version:
I loaded and started the above version. At around line 88, I removed the card and re-inserted it:
Here's a dialog that explains the problem:
Prompt 1
It looks like you fixed the problem. I ran this twice and the output to the console seems like reading is accomplished. Here's the log from the 2nd run. Can you explain why the older versions failed? I'll place that explanation in the Issue ticket and close the ticket as fixed.
Response 1
Yes — the “why” breaks into two distinct failure modes that happened at different points in your iteration:
Your latest
1407log (and your observation “ran twice and reading is accomplished”) is consistent with fixing both.1) Why the original versions failed with a card already inserted at boot
In the early versions (before we added the BLDO1 power-cycle + SPI idle clocks), the SD card’s behavior strongly matched:
The card never received a true reset / clean initialization sequence when already powered at boot.
On the T-Beam SUPREME, the SD card is powered from the PMU (AXP2101 BLDO1). If BLDO1 is already ON (or comes up very early), the SD card can be:
When you physically remove/reinsert, you force:
That explains why the “remove/insert” action acted like magic.
What fixed it
The fix in the working code does two key things:
A. Power-cycle BLDO1 at boot (software equivalent of the physical re-seat)
B. Send “idle clocks” with CS high before the mount attempt
That sequence makes the SD card far more likely to enter the proper SPI idle state before
SD.begin()runs.2) Why the regression happened in one of the newer versions
This was the big gotcha.
To add “pin state” logging, we initially wrote
dumpSdPins()like this (conceptually):That seems harmless, but it’s not.
Because you were calling
dumpSdPins()inside the mount path, it ended up doing this at the worst possible time:bus.begin(...)dumpSdPins()runs and reconfigures SPI pins back to INPUT_PULLUPSD.begin()… with the SPI pins no longer driven properlySo you effectively “cut the legs out from under” SPI right before the mount attempt.
Why that prevented hotplug recovery
Once that regression was in place, even after you removed/reinserted the card, the mount path kept sabotaging itself by reconfiguring the SPI pins.
What fixed the regression
We changed pin-state logging to be non-intrusive, using
gpio_get_level()(reads pin state without altering pin modes), and we stopped touching pinMode during active SPI operation.That’s why the new version both:
A good “Issue ticket” summary you can paste
If you want, I can also compress that to a 5–8 line “close reason” suitable for Forgejo issues.
Prompt 2
So part of the consideration is that the SD card has a power component unrelated to the read/write of the memory. If the SD card is not powered up correctly, attempt to call reads on it will fail because the small computer on the SD card has not properly initialized and cannot shake hands over the SPI interface?
Response 2
Yes. That is exactly correct.
An SD card is not passive storage.
It is:
In other words, it is a small embedded computer.
What Actually Lives Inside an SD Card
An SD card contains:
Raw NAND flash chips
A controller ASIC with:
When you power it up, the controller must:
Only then can it respond correctly to SPI commands like CMD0.
What Happens If Power-Up Is Not Clean
If the SD card:
Then the internal controller may:
That is exactly what your logs were showing.
Why Physical Re-Seat Fixed It
When you removed the card:
That is a hard reset of the SD controller.
Your firmware was previously giving it only a logical reset attempt — not a power reset.
Why Power-Cycling BLDO1 Works
When you do:
You are:
That is why the mount now works deterministically.
Why Idle Clocks Matter
Per SD specification:
To enter SPI mode:
If those conditions are not satisfied during power-up, the card may remain in SDIO mode.
So your:
ensures:
So Your Understanding Is Precisely Right
That is exactly the mechanism.
You are not “reading memory.”
You are talking to a microcontroller that then reads memory.
If that microcontroller is not in the correct state, nothing above it works.
Why This Is Common on ESP32 Systems
ESP32 boards often:
All of those create subtle power/initialization races.
You eliminated them by:
That is a very professional fix.
If you'd like, I can also provide a short “engineering-level explanation” suitable for documentation in your repository README explaining SD controller behavior in embedded systems.
Fixed by commit
0217ecejlpoole/microReticulumTbeam@0217ece