ESP32-S3 + blue microSD module: MISO stuck LOW when idle, SD.begin() fails

Hi all, stuck on mounting a microSD card and looking for a sanity check before I replace the module.

Hardware

  • ESP32-S3-DevKitC-1 (powered over USB-C, 5V pin used for module VCC)
  • Generic blue microSD breakout (AMS1117 3.3V reg + 74LVC125 level shifter)
  • Card: 32GB, FAT32, contains /MP3/*.mp3

Wiring (dedicated FSPI bus, no other devices share it)

  • CS → GPIO 11
  • SCK → GPIO 12
  • MOSI → GPIO 13
  • MISO → GPIO 14
  • VCC → 5V, GND → GND

Code (trimmed)

  static SPIClass spiSD(FSPI);

  pinMode(SD_CS, OUTPUT);
  digitalWrite(SD_CS, HIGH);
  pinMode(SD_MISO, INPUT_PULLUP);
  Serial.printf("MISO idle = %d\n", digitalRead(SD_MISO));

  spiSD.begin(SD_SCK, SD_MISO, SD_MOSI, SD_CS);
  for (uint32_t f : {400000, 1000000, 4000000}) {
    if (SD.begin(SD_CS, spiSD, f)) { /* ok */ break; }
  }

Observations

  • With MISO wire disconnected from module → MISO idle = 1 (ESP32 pull-up works, GPIO fine)
  • With MISO wire reconnected, CS held HIGH, no transactions → MISO idle = 0
  • SD.begin() fails at 400 kHz, 1 MHz and 4 MHz
  • Card reads fine on PC, FAT32 confirmed

What I've checked

  • VCC measures 5.0V on the module, AMS1117 output 3.3V
  • Continuity MISO ↔ GPIO14 good, no short to GND
  • Swapped SD cards, same result
  • Tried HSPI and FSPI, same result

The module actively pulls MISO LOW when idle — looks like the 74LVC125's OE is tied permanently active instead of
following CS, which is a known issue on some of these cheap boards.

Question: Is my diagnosis right, or is there a software-side fix I'm missing before I swap the module for an
Adafruit/SparkFun one?

Thanks!

If you're using a 3.3V processor, you don't need or want level shifting to communicate with a 3.3V uSD. All you need is the simplest of breakouts:

And yes, many if not most if not all of the generic blue uSD adapters have a problem where the buffer for the MISO line is enabled all the time and not disabled when /CS is high. You can do surgery on it to work around that if you're up to it.

I think MISO is ultimately derived from pin 7 (DO) of both the standard and micro SD cards. That pin should be tristate when the card's CS is not asserted, which means the data input to the 125 gate will be floating, and its output, although active, will be undefined.

But when CS is asserted, DO should go high, which means MISO should go high. Then everything should work - so long as there are no other devices on the SPI bus.

I don't know how this all works on an S3, but it should not be concerned with the voltage on MISO unless it has asserted CS. If the voltage is still low after CS is asserted, then something is wrong with the 125 or the traces between DO and the 125. It appears not to be a problem with the SD card because it works ok in your computer.

But I agree that all you really need is a simple breakout module if you're connecting to a 3.3V MCU, and doing more than that is just asking for trouble. You don't need to translate 3.3V to 3.3V.

Edit: I guess if it was me, I would remove the SD card, and disconnect all the lines, and then measure the resistance between D0 and ground. And then if you can find which 125 gate is involved, do the same test for its input and output pins. It could just be a solder blob short somewhere.

Another possibility would be to test the module on an Uno or Nano with one of the example sketches. While their design is defective, these SD module do work on AVR-based Arduinos so long as there's only one. If that works, then maybe there's something quirky about SPI on the S3.