@Josverl you've looked into this a lot more recently than I have, so I'm very curious what you think.

I noticed that in your results table here you didn't get a REPL on non-ESP devices when setting DTR=True and RTS=True. I wasn't able to reproduce this (my understanding is that as long as DTR is set, RTS should be ignored) but it did give me some concern that I've missed something (or behaviour is different in some other Windows configuration).

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.39%. Comparing base (a563592) to head (3dd8073).
⚠️ Report is 4 commits behind head on master.

@@           Coverage Diff           @@
##           master   #18001   +/-   ##
=======================================
  Coverage   98.39%   98.39%           
=======================================
  Files         171      171           
  Lines       22289    22289           
=======================================
  Hits        21931    21931           
  Misses        358      358           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Some board vendors (ESP32 and others) wanted to save a few pennies and omitted the two transistor logic for RTS and DTR. Instead RTS and DTR are directly connected to the respective pins, e.g. Reset and IO0. Then it matters whether RTS and DTR are both low or both high. Such board required having control over RTS and DTR. That is possible e.g. with picocom. I faintly recall that there were similar discussion for mpremote.

My tests are all passing through the USB device to a Windows 11 VM on a Linux host. I expect native Windows behaviour will be the same., but it'd be good if someone could verify this.

I do expect differences, mainly as I also see differences in when running Ubuntu/ WSL2 in Windows. Could be it's just timing, but we know it only needs a spike to cause a reset.
I'll see what I can repo with the boards I have with me now. ( Not at home)

Then it matters whether RTS and DTR are both low or both high. Such board required having control over RTS and DTR. That is possible e.g. with picocom. I faintly recall that there were similar discussion for mpremote.

So would it be better to set RTS/DTR defaults (for ESPxxx) that can be changed by cmdline/config, rather than hard coding ?

Also, how can I determine on a board if the dual transistor logic you mention is in place? I do not want to pollute the tests, and I have both cheap and non-cheap boards

(And my electronics skills are basic)

So would it be better to set RTS/DTR defaults (for ESPxxx) that can be changed by cmdline/config, rather than hard coding ?

Yes. The default can be that both DTR and RTS are set (levels at the board low), which is the actual state.

Also, how can I determine on a board if the dual transistor logic you mention is in place? I do not want to pollute the tests, and I have both cheap and non-cheap boards

You can try the various settings, whether the board responds, or just assume that the majority of boards behave well with RTS and DTR both set and not use untypical boards for firmware testing. The special cases are then left as support for users with untypical boards.

P.S.: Not all cheap boards omit the reset/firmware_load logic.

@projectgus
wrt to the table above ; Several of the boards have multiple USB ports,
Usually they are labeled USB or UART/COM/Serial .

Can you clarify that in the table please ?
As these issues show these details 🙄matters in testing , and in issue reports as well.
I only have a few boards with me currently ( S3 - dual port , and C3-Dual port )

Some board vendors (ESP32 and others) wanted to save a few pennies and omitted the two transistor logic for RTS and DTR. Instead RTS and DTR are directly connected to the respective pins, e.g. Reset and IO0. Then it matters whether RTS and DTR are both low or both high. Such board required having control over RTS and DTR. That is possible e.g. with picocom. I faintly recall that there were similar discussion for mpremote.

Indeed! In fact, this is the wiring convention (and problem) that inspired the first reset circuit for ESP8266, on the original NodeMCU board circa 2014/15!

I agree it'd be useful to have this configurable for mpremote. However, that's somewhat separate to this problem (already mpremote will assert DTR and RTS from a MacOS or Linux host, Windows is the only one that doesn't due to the existing workaround).

FWIW, over the years I was the esptool maintainer I don't remember any complete dev boards with USB but no transistor logic, although I'm sure you're right that there are some out there (I do remember some with crappy implementations of the transistor logic). I've seen the "no reset circuit" pattern crop up a lot in consumer products or module breakouts where there might be a header that exposes RX, TX, IO0 and RST pins directly.

wrt to the table above ; Several of the boards have multiple USB ports,
Usually they are labeled USB or UART/COM/Serial .

Can you clarify that in the table please ?

Sorry about that, I've edited the table to explain better. A bunch of the "todos" are a bit vague because they're prompts for me to go rummage through my embarassingly large stock of ESP boards and find examples with all the possible interface chips! Once I find one (or someone else reports a result) then I'll update the table with the actual board details.

I'll see what I can repo with the boards I have with me now. ( Not at home)

If/when you have time then that'd be great, thank you! I'll do some testing with other boards (and maybe other host configs) next week, as well.

already mpremote will assert DTR and RTS from a MacOS or Linux host

assert DTR and RTS means that the level at the output of the USB/UART bridge is low. So these "non-conforming" board do not work with mpremote and Linux.

already mpremote will assert DTR and RTS from a MacOS or Linux host

assert DTR and RTS means that the level at the output of the USB/UART bridge is low. So these "non-conforming" board do not work with mpremote and Linux.

Yes indeed, that's why I'm saying that it's a separate concern to the problem that this PR is addressing. (To be clear: If this PR is merged then those configurations may stop working on Windows, but they already don't work from Linux or MacOS. This PR would at least make the behaviour consistent across different hosts, and then if necessary we can look at adding a config setting or an option that allows those particular boards to work from all hosts.)

You have to be careful messing around with setting the states of DTR and RTS as they control the ESP32's boot mode and restarting. I know that this is hard wired into the hardware USB-CDC on the ESP32's that support native USB. I do not know how this plays into the software stack that MicroPython is using but my guess is going to be that the software stack needs to watch those signals and to perform reboots and or setting the boot mode as needed depending on the state of DTR and RTS.

at the very bottom.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/get-started/establish-serial-connection.html#example-output

and then if you read here it will shed some more insight on those lines.

https://docs.espressif.com/projects/esptool/en/latest/esp32/advanced-topics/boot-mode-selection.html#automatic-bootloader

Now I know the above link is outlined for using a UART to USB bridge IC but the same applies when using the native USB.

I also think that this might be a tripping up point...

When developing esptool, keep in mind DTR and RTS are active low signals, i.e., True = pin @ 0V, False = pin @ VCC.

You have to be careful messing around with setting the states of DTR and RTS as they control the ESP32's boot mode and restarting

I appreciate your concern, but I'm well aware. Without putting too fine a point on this, I was the maintainer of esptool from 2015 to 2021 (including five years employed by Espressif). I wrote the sentence from the esptool documentation that you've quoted from (although that was a wiki page, back then).

I'm not saying this PR is infallible (hence marking as draft and asking for testers), but I am saying that I'm across the issue of DTR and RTS on Espressif boards.

I improved my Windows VM test setup by passing through the USB controller PCIe device to the VM - this should give equivalent USB behaviour to a native host. This revealed a quirk in the Silicon Labs driver that needs a workaround to avoid triggering a hard reset the first time the port is opened after power on (but the port was OK if opened additional times after that, very odd).

Was able to do a bunch more testing with various boards, have updated the table at the top. So far so good.

If anyone has unusual boards, additional USB/Serial chips, or unusual Windows setups then I'd greatly appreciate any test results you can provide. 🙏

Sharing my test results
All tests using :

• mpremote 1.27.0rc0.post75+g2416c6fee.d20250907 ( corrected on Windows )
• MicroPython v1.26.0

Updated with WLS2 tests

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' isn't defined```

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' isn't defined```

Thanks @Josverl, I really appreciate your help with this. That's interesting that all three failures you have are connecting to the Espressif USB/JTAG hardware peripheral. I'll do some more testing with different MP versions on my board, try to reproduce.

• mpremote 1.26.0rc0.post174+g5a7200217b.d20250619

Just to check: I don't have a commit 5a7200217b in my repo anywhere - did you perhaps rebase this PR branch? (I don't expect it's the difference, but worth ruling it out.)

Thanks for catching my mistake.
I assumed uv pip install tools/mpremote would update mpremote in the active environment.
It only does that after forcing it with --reinstall 🤦

I repeated the Windows tests with the mpremote version from this PR

I repeated the Windows tests with the mpremote version from this PR

Well, that's good news at least, I was really not looking forward to trying to figure out what was different between my Windows test setup and yours! Thanks for testing twice. 😁

Do you have any outstanding concerns with this approach (aside from the desirability of adding a manual override option, which I fully agree we should do)?

(For my own 2c: I'm not super happy that we turned out to need a SiLabs CP210x driver workaround on Windows hosts, although on the plus side the workaround should lead to consistent CP210x behaviour on all host OSes - and the behaviour is valid whether or not the CP210x is connected to an Espressif SoC or something else that might expect DTR or RTS to be used in a conventional way.)

Do you have any outstanding concerns with this approach

LGTM

and then we can add the option to apply rts/dtr tweaks from options/environment/config files separately.

( I do have one board ( ESP32-PICO-KIT-V4 - 4517) that needs a hard reset before mpremote will connect - but that was also with mpremote 1.25.0 - so I think that is a board defect and should not hold this back

This can now be rebased.

Rebased, did a couple of quick re-tests (although the only mpremote change after rebase is moving the import block to the top of the file).