CircuitPython version and board name

ESP32 Feather HUZZAH32 in CircuitPython 10.x.x Beta/Nightly

Code/REPL

N/A as any code cannot be uploaded. Any code in a code.py file is fine to test with for this bug.

Behavior

not able to Serial File Transfer (Mu/ampy) Broken on ESP32 Feather HUZZAH32. Since this board does not have native USB support for file transfer, this becomes a critical issue for this type of board.

Description

Issue Description:

I am experiencing a critical regression in recent CircuitPython 10.x.x development builds for the Adafruit Feather HUZZAH32 (ESP32). This bug prevents file transfer and filesystem access via serial tools like Mu Editor's file transfer mode or ampy.

My Adafruit Feather HUZZAH32 (ESP32) does not have native USB, so it does not present its internal code storage as a directly mounted drive in the operating system. File system access and code upload are performed exclusively over the serial connection using tools like Mu Editor or ampy via the Linux command line.

Hardware:

Board: Adafruit Feather HUZZAH32 (I am using an EzSBC clone, which uses the same core components and pinout)

Microcontroller: ESP32

USB-to-Serial Chip: CP2104 (on the Feather HUZZAH32)

CircuitPython Versions & Behavior:

Working (Stable): 9.2.8 (Dated 2025-05-28)

The board does not show its internal code storage as a mounted drive in the OS, as expected for an ESP32 without native USB.

I CAN successfully upload code.py and other files, and browse the board's filesystem, using Mu Editor's serial file transfer feature or ampy via the Linux command line over the serial connection.

Not Working (Beta/Nightly Regression): 10.0.0-beta.0 (Dated 2025-07-15) and subsequent nightlies in that range.

The board does not show its internal code storage as a mounted drive in the OS, as expected for an ESP32 without native USB.

I CANNOT upload code.py or other files, nor browse the board's filesystem, using Mu Editor's serial file transfer or ampy via the Linux command line. These tools fail to connect to the filesystem or report errors.

Steps to Reproduce:

Flash firmware using Adafruit WebSerial ESPTool (https://adafruit.github.io/Adafruit_WebSerial_ESPTool/):

First, flash adafruit-circuitpython-adafruit_feather_huzzah32-en_US-9.2.8.bin to the Feather HUZZAH32.

Verify that code.py can be uploaded/downloaded and the filesystem listed using Mu Editor's serial file transfer feature or ampy ls via the Linux command line. (This should work).

Flash the problematic build using Adafruit WebSerial ESPTool:

Flash adafruit-circuitpython-adafruit_feather_huzzah32-en_US-20250708-main-PR10458-ce71e9e.bin (or 10.0.0-beta.0.bin) to the same board.

Attempt to upload/download code.py using Mu Editor's serial file transfer feature or ampy ls via the Linux command line.

Expected result: File transfer works, and filesystem can be accessed.

Actual result: File transfer fails; Mu/ampy cannot access the filesystem over the serial connection.

Regression Identified (Binary Search Results):
The regression was introduced between these two specific builds:

Last Good Build: adafruit-circuitpython-adafruit_feather_huzzah32-en_US-20250708-main-PR10447-b1599e2.bin (dated 2025-07-08T15:21:59.000Z) - Serial file transfer works.

First Bad Build: adafruit-circuitpython-adafruit_feather_huzzah32-en_US-20250708-main-PR10458-ce71e9e.bin (dated 2025-07-08T16:39:11.000Z) - Serial file transfer fails.
This points to the change(s) within Pull Request #10458 as the likely cause of the regression.

Additional Context:

Operating System: KDE Neon Linux with Kernel 6.14.0-24-generic (64-bit)

This issue makes it impossible to develop on the board using beta/nightly firmware unless files are manually flashed with the entire .bin file.

For context, I was testing the beta firmware to see if it resolved a separate, ongoing issue where an SD card (Adalogger FeatherWing) does not initialize in CircuitPython 9.2.8 (stable). I am still investigating this SD card issue, and neither the sdcardio nor the adafruit_sdcard library seem to work for me.

Additional information

No response