ESP32 fails to enter download mode on Macbook via USB C Adapters (ESPTOOL-383)

[CraftyMyner]

Operating System

16" Macbook Pro 2021, M1 Max, macOS 12.0.1

Version

latest master

Python Version

3.10.0

Chip Description

ESP32-DevKitC V4, ESP32-WROOM-32D, ESP-PROG

Device Description

Setup 1: ESP32-DevKitC V4 -> USB Micro B to USB-C -> Macbook USB C port (Tried all ports)
Setup 2: ESP32-DevKitC V4 -> USB Micro B to USB A -> USB A to USB-C -> Macbook USB C port (Tried all ports)

Hardware Configuration

Nothing else is attached.

How is Esptool Run

platformio, arduino, and esptool.py from cli

Full Esptool Command Line that Was Run

python3 esptool.py --port /dev/cu.usbserial-10 read_mac

Esptool Output

esptool.py v3.3-dev
Serial port /dev/cu.usbserial-10
Connecting......................................

A fatal error occurred: Failed to connect to Espressif device: Wrong boot mode detected (0x13)! The chip needs to be in download mode.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

More Information

This appears to be similar to a previous issue: macOS connection failure (ESPTOOL-363) #696

Pressing boot/reset buttons allows chip to enter download mode.
Tried multiple boards, none are able to enter download mode.
Swapped driver for Silicon Labs CP210x VCP driver, still does not work.

Issue does not exist on Macbook Pro 2015 or windows laptop (USB A Ports)

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[radimkarnis]

Hello @CraftyMyner,
thanks for reporting and investigating this!

You are right that #696 is probably the same issue. I also use a MacBook and have experienced this behavior with a USB Micro B to USB-C cable. Using a hub solves this.

I will try to capture the DTR/RTS signals and debug this. Until then, we'll keep this open.

[CraftyMyner]

Thanks for looking into this @radimkarnis,

I just did some more testing and it looks like the reset signal works, just not the boot signal. A press of the boot button at the right time will get it to program.

[radimkarnis]

By any chance, do you have a USB2 hub available? There are reports (espressif/esp-idf#2849 (comment)) of failing auto-reset when using USB3.x ports. We could verify this is the same issue.

[CraftyMyner]

MacBook USB C (Thunderbolt 4/ USB 4) to USB Micro B cable - does not work.
MacBook USB C (Thunderbolt 4/ USB 4) to USB A Gen 3 adapter -> standard USB A Gen 2 to USB Micro B cable - does not work.
MacBook USB C (Thunderbolt 4/ USB 4) to USB A Gen 3 adapter -> USB A Gen 3 Hub -> standard USB A Gen 2 to USB Micro B cable - works!

[MMI]

I have a colleague experiencing this same issue with a brand new M1 macbook... they are going shopping for hubs to try.

Apropos of nothing, I had a very similar issue (able to reset but not trigger the ROM bootloader) when using esptool.py in a VM -- which led me to think that it was a problem with the way USB was virtualized. This new problem has me wondering it's more general to MacOS...

[CraftyMyner]

I thought it might be the apple driver but I tried the one from silabs and no change. I got a capture on my scope of the download mode sequence waveforms, there appears to be a slight glitch on the boot line right as the reset goes high for some reason.

[CraftyMyner]

P.S. This is through the same USB C to USB A adapter (that does not work on its own) AND the hub. 100% repeatable.

[MMI]

So for my part, I'd been reading the DTR and RTS lines using a logic analyzer (I don't have a scope) and I have observed
that when DTR is dropped more than 2ms before RTS comes up, the ESP32 will reset in "normal" mode. The trace below shows the desired behaviour (from esptool.py --chip esp32 --port /dev/xxx read_mac)

I'm curious... is it possible to see a trace of both the inputs (RTS,DTR) and the outputs (EN and GPIO0)?

[dobairoland]

Similar issue was reported here.

[MMI]

As has been noted elsewhere, the circuit is sensitive to timing. Those notes tend not to be specific. That's probably because everybody's implementation of that reference "auto-reset" circuit is slightly different -- particularly the capacitor.

On my devices, I have observed that the time between the dropping of DTR and the rising of RTS needs to be less than 2ms in order to trigger a reset into download mode. We have also figured out that changing the capacitor eases that constraint (because the capacitor affects the rise time on the EN pin).

Out of curiousity, is the chain of python, pyserial(or whatever is used) all native M1 compiled or is it running under Rosetta? If Rosetta is involved, I'm wondering if that's what's slowing down the hardware line transitions -> and would a fully native build "fix" the problem?

[256dpi]

I'm experiencing similar issues on my Macbook Pro M1 Max over USB-C. But, on my side, it seems to be an issue with esptool itself. Any release prior to v3.2 allows me to successfully read the chip ID, flash, etc. With v3.2 and master, I always get the "Wrong boot mode detected (0x13)!" error.

@radimkarnis Have there been any significant changes since v3.2 related to boot mode selection logic?