Unable to connect to ESP32-S3 in bootloader/flash mode. Serial communication for data works, but upload/flash attempts fail consistently. (ESPTOOL-1019)

[ErMagnificoo]

Operating System

Windows 11

Esptool Version

4.8.1

Python Version

3.10.4

Chip Description

ESP32S3

Device Description

Plain ESP32S3 (SuperMini) board

Hardware Configuration

No response

How is Esptool Run

No IDE, Windows terminal

Full Esptool Command Line that Was Run

python -m esptool --port COM3 erase_flash

Esptool Output

C:\Users\Alex>python -m esptool --trace --port COM3 erase_flash
esptool.py v4.8.1
Serial port COM3
Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
    0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    55555555                          | UUUU
TRACE +0.000 Write 46 bytes:
    c000082400000000 0007071220555555 | ...$........ UUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    5555555555555555 5555555555c0     | UUUUUUUUUUUUU.
TRACE +0.007 Read 1 bytes: c0
TRACE +0.000 Read 45 bytes:
    0008240000000000 0707122055555555 | ..$........ UUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    5555555555555555 55555555c0       | UUUUUUUUUUUU.
TRACE +0.000 Received full packet:
    0008240000000000 0707122055555555 | ..$........ UUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    5555555555555555 55555555         | UUUUUUUUUUUU
TRACE +0.105 Serial data stream stopped: Possible serial noise or corruption.
.TRACE +0.118 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 


and the repeats from 0707122055555555 ...

More Information

Troubleshooting Attempted

• Multiple USB port tests
• Various reset sequences (BOOT/RESET button combinations)
• Different connection parameters in esptool

Specific Command Attempts

python -m esptool --port COM3 --chip esp32s3 erase_flash
python -m esptool --port COM3 --chip esp32s3 --baud 115200 --before default_reset --no-stub erase_flash
python -m esptool --port COM3 --chip esp32s3 --connect-attempts 10 erase_flash
python -m esptool --port COM3 --chip esp32s3 flash_id

Potential Context

• Board previously used with modified TinyUSB USB descriptors
• Another identical board functions normally

Expected Behavior

• Successful bootloader connection
• Ability to erase/flash device

Actual Behavior

Consistent failure to enter bootloader/flash mode via esptool

Additional Information

• USB data communication works
• No visible physical damage to board
• Drivers up to date

Reproducibility

100% reproducible on this specific board

Other Steps to Reproduce

I've uploaded and runned this code:

`
#include "class/cdc/cdc_device.h"
#include "esp_log.h"
#include "tinyusb.h"
#include <string.h>

// Custom VID and PID
#define CUSTOM_VID 0x1234 // Replace with your Vendor ID
#define CUSTOM_PID 0x5678 // Replace with your Product ID

// USB Device Descriptor
static const tusb_desc_device_t custom_device_descriptor = {
.bLength = sizeof(tusb_desc_device_t),
.bDescriptorType = TUSB_DESC_DEVICE,
.bcdUSB = 0x0200, // USB 2.0
.bDeviceClass = TUSB_CLASS_MISC,
.bDeviceSubClass = MISC_SUBCLASS_COMMON,
.bDeviceProtocol = MISC_PROTOCOL_IAD,
.bMaxPacketSize0 = CFG_TUD_ENDPOINT0_SIZE,
.idVendor = CUSTOM_VID,
.idProduct = CUSTOM_PID,
.bcdDevice = 0x0100, // Device release number
.iManufacturer = 1, // String index 1
.iProduct = 2, // String index 2
.iSerialNumber = 3, // String index 3
.bNumConfigurations = 1
};

// USB String Descriptors
static const char *string_desc_arr[] = {
(const char[]) { 0x09, 0x04 }, // Language ID (English US)
"My Manufacturer", // Manufacturer
"ESP32-S3 CDC Device", // Product
"123456789ABCDEF" // Serial Number
};

// USB String Descriptor Callback (Must match TinyUSB's signature)
uint16_t const *tud_descriptor_string_cb(uint8_t index, uint16_t langid) {
static uint16_t desc_str[32];

// Validate index
if (index >= sizeof(string_desc_arr) / sizeof(string_desc_arr[0])) {
    return NULL;
}

const char *str = string_desc_arr[index];
uint8_t len = strlen(str);
if (len > 31) len = 31;  // Limit max length

// Convert ASCII to UTF-16LE
desc_str[0] = (TUSB_DESC_STRING << 8) | (2 * len + 2);
for (uint8_t i = 0; i < len; i++) {
    desc_str[i + 1] = str[i];
}

return desc_str;

}

void app_main(void) {
ESP_LOGI("USB", "Initializing USB CDC device with custom descriptors");

// TinyUSB configuration
const tinyusb_config_t tusb_cfg = {
    .device_descriptor = &custom_device_descriptor,
    .string_descriptor = NULL,  // Let TinyUSB use tud_descriptor_string_cb()
    .external_phy = false
};

// Install TinyUSB driver
ESP_ERROR_CHECK(tinyusb_driver_install(&tusb_cfg));

uint8_t buf[64];

while (1) {
    // Check if data is available
    if (tud_cdc_available()) {
        uint32_t count = tud_cdc_read(buf, sizeof(buf));

        // Echo the received data back to host
        tud_cdc_write(buf, count);
        tud_cdc_write_flush();
    }
    vTaskDelay(pdMS_TO_TICKS(10));
}

}
`

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[github-actions]

Hi @ErMagnificoo! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Based on the information provided, it appears the user is experiencing issues with connecting to an ESP32-S3 device in bootloader/flash mode using esptool. Let's analyze the problem and provide some potential solutions based on the available knowledge sources.

1. Bootloader Won't Respond:
   The error "Failed to connect" suggests that the chip is not entering the bootloader properly. According to the ESP32-S3 Troubleshooting Guide, there are several things to check:

• Ensure you're using the correct serial port (COM3 in this case).
• Check that no other software is accessing the serial port.
• Verify that the chip is receiving a stable 3.3V power supply.
• Check that all pins are correctly connected for boot mode selection.
• Try removing any other devices connected to GPIO pins.
• Attempt using a slower baud rate (e.g., -b 9600).

2. Custom USB Descriptors:
   The user mentioned that the board previously used modified TinyUSB USB descriptors. This could be interfering with the bootloader mode. As suggested in the ESP32-S3 Troubleshooting Guide, if the application accidentally reconfigures the USB peripheral pins or disables the USB peripheral, it can cause issues.

Recommendation:
Try to manually enter the download mode and then use the erase_flash command to wipe the flash memory. This might clear any problematic configurations:

1. Manually enter download mode (refer to your board's documentation for the exact method, usually involving holding down the BOOT button while resetting).

2. Run: python -m esptool --port COM3 --chip esp32s3 erase_flash

3. Serial Data Corruption:
   The trace output shows "Serial data stream stopped: Possible serial noise or corruption." This could indicate issues with the USB connection or cable.

Recommendations:

• Try a different, high-quality USB cable.
• If using a USB hub, connect directly to the computer's USB port.
• Attempt to use a powered USB hub if available.

4. Additional Troubleshooting:
   If the above steps don't resolve the issue, you can try the following:

• Use the --trace option (as you've done) to get more detailed output.
• Try using a much lower baud rate: python -m esptool --port COM3 --chip esp32s3 --baud 9600 erase_flash
• Attempt to skip chip autodetection: python -m esptool --chip ESP32-S3 --port COM3 erase_flash

If none of these solutions work, it's possible that the custom USB descriptors or previous firmware have caused a more persistent issue. In this case, you might need to use alternative flashing methods, such as JTAG, to recover the device.

For further assistance, you may want to open an issue on the esptool GitHub repository with all the details and troubleshooting steps you've already taken.

[radimkarnis]

Hi @ErMagnificoo,
this issue looks similar to #1070, can you please verify if this is or is not the case?

Some points:

1. We previously had reports of poor build quality of the SuperMini series of devkits. Could this be a single faulty unit? Can you please inspect the board?
2. If you hold the BOOT button, connect the USB to the USB cable and then run esptool with the --before no_reset option, this still doesn't work? I would suggest trying to erase_flash this way.
3. You say Serial communication for data works, how do you verify that? If you get a serial console running and see data output, what do you see if you switch to the bootloader mode?

[radimkarnis]

Also, please look at #868, this seems to be the same issue.

[jedi7]

Hello @ErMagnificoo

The root cause of the problem is that operation in USB CDC mode is not compatible with the method Esptool (v5.1.0) uses to enter the download protocol (setting strapping pin and reset pin). Consequently, the commands sent by Esptool are being processed by your application's echo program instead of the ROM bootloader, which results in the unexpected behavior you are observing.