M5Stack Core S3 SD card not working

[JamesWhitlock]

CircuitPython version and board name

CircuitPython 9.2.8 on M5Stack Core S3

Code/REPL

import digitalio
import board
import adafruit_sdcard

spi = board.SPI()
cs = digitalio.DigitalInOut(board.SDCARD_CS)
sdcard = adafruit_sdcard.SDCard(spi, cs)

Behavior

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "adafruit_sdcard.py", line 112, in __init__
  File "adafruit_sdcard.py", line 133, in _init_card
OSError: no SD card

Description

No SD card is detected. The IO allocation appears to be correct. The docs have a warning about sharing the SPI bus https://docs.circuitpython.org/projects/sd/en/latest/#sharing-the-spi-bus-with-other-devices and the device's SPI bus is shared with the display. I don't know what the source of this comment is but I cannot see anywhere anywhere in the code that the CS is initialised as an output and held high before display init.

Additional information

No response

[JamesWhitlock]

This appears to be related/duplicate of #6290

[scarolan]

Spent significant time debugging this on the M5Stack CoreS3 SE (new board definition based on CoreS3). Here's what I found:

Root Cause: GPIO35 is shared between SPI MISO and display DC (Data/Command) pin.

The ILI9342C display uses FourWire SPI with GPIO35 as the DC pin. The SD card slot shares the same SPI bus and needs GPIO35 as MISO to read data back. These two functions are electrically and logically incompatible when both are active.

Behavior:

• sdcardio.SDCard(spi, board.SDCARD_CS) in boot.py or code.py → hard fault (memory access error, safe mode)
• sdcardio.SDCard(spi, board.SDCARD_CS) from REPL → no crash, but returns OSError: no SD card
• The SD card is never detected in any context

What I tried (all failed):

• Disabling display.auto_refresh before SD init
• displayio.release_displays() to fully tear down the display before SD init
• Adding 3 second delay before SD init
• Running SD init as the very first thing in code.py (before any print() or display access)
• Moving SD init to boot.py (even earlier execution)
• Running SD init via exec() to mimic REPL context
• Cherry-picking the SPI transaction fix from PR Fix BusDisplay transaction handling #10571
• Power-cycling the SD card via AXP2101 ALDO4 register toggle
• Sending 80 SPI clock cycles at 250kHz with CS high (standard SD wake-up)
• Toggling CS via digitalio before SD init
• Adding config_pin_as_output_with_level(GPIO_NUM_4, true) in board.c to assert SD CS high before display init

Analysis:

The FourWire display bus claims GPIO35 as a DigitalInOut output for DC via claim_pin() and common_hal_never_reset_pin(). When sdcardio initializes, the ESP-IDF SPI driver reconfigures GPIO35 as an input for MISO. This creates a conflict at the hardware level — two subsystems driving the same pin in opposite directions.

The script vs REPL difference: during script execution, the CircuitPython supervisor's display terminal is actively rendering print() output through FourWire, which uses GPIO35 as DC. The supervisor resets pins between script exit and REPL entry, putting GPIO35 into a clean state — which is why sdcardio doesn't hard fault from the REPL (though the card still isn't detected, likely because the display init already corrupted the SD card's SPI state during boot).

Affected hardware: Confirmed on both CoreS3 and CoreS3 SE. This is a hardware design issue (MISO/DC pin sharing) that requires a software workaround in CircuitPython's FourWire or SPI bus handling.

Tested on: CircuitPython 10.0.3 (stock CoreS3) and 10.1.0-beta.1 (custom CoreS3 SE build from main).