Summary

This is a possible alternative fix for #9659 which uses a different approach to #17776 and #17800.

Background

There are two conflicting problems with use of DTR and RTS in mpremote (and other serial host programs):

1. USB-CDC implementations tend to use "DTR is set" as a signal for "host is connected" (a reasonable thing to do), and therefore don't send any data to the host if DTR is cleared.

2. ESP8266 and ESP32 boards use a convention where setting (DTR&&!RTS) means "put IO0 low for bootloader mode" and (!DTR&&RTS) means "trigger reset", allowing the host to reset the chip to bootloader mode. Traditionally this is implemented in a small circuit - the circuit mostly exists so that default behaviour of an open serial port (DTR&&RTS) doesn't trigger a reset.

   With the Espressif integrated "USB Serial & JTAG" peripheral and Espressif TinyUSB native USB stack the same reset logic is implemented by looking for a sequence of line state transition packets (implemented in hardware and software, respectively).

#9659 describes a problem where Windows (and/or pyserial on Windows) clears DTR before RTS when closing the port, and therefore triggers a hard reset each time mpremote exits.

@Josverl has done a lot of hard work and testing to find a DTR & RTS setting which works for (2) without causing problems due to (1), and has come up with a heuristic for detecting possible Espressif boards. The challenge is that pretty much any USB/Serial chip on the market has been connected to an ESP8266 or ESP32 at some point, and there's no way to tell what MCU is connected from the USB side.

There also cases like #17999 where an Espressif chip with a native USB implementation needs (1) in order to function correctly.

Approach in this PR

Instead, we can manually clear RTS before DTR when closing the port, to avoid the reset issue. Opening the port can use the default behaviour (RTS & DTR both set).

In mpremote, the transport close() is called from a finally block in the mpremote main module (via do_disconnect()) - so this should always happen provided the Python process isn't terminated by the OS.

Testing

On Linux my test process is:

mpremote a0 exec "a=53"; mpremote a0 resume exec "print(a)" 

If the resume works correctly then this should print 53. If a reset occurs when mpremote exits then it will print NameError: name 'a' isn't defined.

Windows allocates a new COM port for each device, so made a batch file to only type the port name once:

python -m mpremote connect %1 exec "a=52"
python -m mpremote connect %1 resume exec "print(a)"

Results:

• A few targets in this table are still untested (mostly, testing all the different USB chipset drivers), but I think I have most of these in my bucket of ESP boards!
• 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 don't have access to a Mac to verify there's no regression there, but I don't expect one (port opening sequence hasn't changed for macOS, and clearing RTS early shouldn't break anything).
• Also did some manual tests of pressing the Reset button while mpremote REPL was connected to double check the board doesn't reset into bootloader mode.

Trade-offs and Alternatives

• If the mpremote process is killed by Windows then Windows may clear DTR before RTS during cleanup and trigger a hard reset (not verified), but this seems like a reasonable limitation. The close() path is in a finally block otherwise, so any "normal" mpremote exit should hit it.
• We could keep adding quirks for specific USB IDs, but I think this risks getting into a game of "whack a mole" with vendor USB/serial chip choices.