Code size report:

   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
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (16c6bc4) 98.36% compared to head (0912594) 98.36%.

@@           Coverage Diff           @@
##           master   #13455   +/-   ##
=======================================
  Coverage   98.36%   98.36%           
=======================================
  Files         159      159           
  Lines       21088    21088           
=======================================
  Hits        20743    20743           
  Misses        345      345           

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

@NoosaHydro Which ESP boards are you finding that lock up or reset with the current mpremote/pyboard behaviour, and with which host OS?

Most ESP8266/ESP32 development boards have some version of the "automatic bootloader" circuit, meaning that default serial port behaviour (assert RTS and DTR together) shouldn't trigger a reset. In recent years I don't recall too many where this doesn't work as expected, except for when wiring RTS and DTR pins directly to the chip.

@projectgus There's more context to this change in the original PR it was included in: #13253 (comment)
pyserial/pyserial#729

@andrewleech Thanks Andrew, that's useful context.

I'm still curious how widespread this problem is. I have an embarrassing number of ESP32 boards and some ESP8266 ones, and I debugged these kind of issues a lot when I was the esptool maintainer at Espressif (and before). My impression is that it was more common back around 2016/2017, when more of the cheaper development boards weren't implementing the automatic reset circuit properly. These days I had the impression it was quite rare.

I'm not denying it happens, it's quite likely there are some families of boards that have this problem and maybe it's more widespread than I know. However, I'm curious exactly which boards do exhibit it, on which host OSes. That helps everyone understand how important it is to work around.

wtr this discussion and the inquiry as to how impactful the matter is: a couple of days ago I wanted to play with a ESP32_CAM board with an ambition to get to object detection & recognition and had a difficult time getting it to work icw Thonny. I managed - in the end - following up on a suggestion somewhere on the net to add RTS / DTR settings in Thonny's configuration file.

Then I had some ESP8266 Wemos D1's lying (ESP8266EX chips), once bought to supplement my collection of RPI Pico's with WIFI connectivity (now obsolete given the Pico_W availability) and ran into the same issue as the ESP32_CAM: flashing works but the Micropython prompt never shows up. Played with RTS etc here too but have not gotten the ESP8266 to run Micropython (tried different images, Thonny settings, several boards). Logged it as issue at Thonny (#3083).
Both the ESP32 and ESP8266 end the flash process with: Hard resetting via RTS pin... Done! Which appears to connect to the topic discussed here.
I realize these two examples do not yet represent a widespread issue (but still). .

Thx for the efforts all you guys continue to make to improve Micropython !

For additional reference, here is some previous work on this as done by @Josverl and discussed on Discord recently.

Note that according to Jos' research there are some (non-ESP) boards where de-asserting DTR may break functionality, and we'd need to ensure any blanket change here doesn't have similar regressions (or make it a command line option).

#11076

#10347

Thank you for sharing! The info below connects to the references you provided.

After having put the matter to rest for some days, I tried again, last evening, and with success. I have now two W10 PC's ("current" wrt Windows releases/updates), with the latest Thonny (4.1.4) giving me "MicroPython v1.22.1 on 2024-01-05; ESP module with ESP8266".
Great !

Tried again with both rts = false and dtr = false in the Thonny Configuration file, flashing with the Thonny integrated ESPTOOL with install settings Flash mode = DIO and size = detect, made the micropython show up.
There is a small difference, though: on the one PC, after a reset, I get first 4 lines of unreadable print before the prompt shows up. The other PC gives a clean prompt straightaway. As my W10's are different brands, there might be driver "influence" involved.

It is the ESP8266 which send the first boot message at 78440 baud, which decodes at 115200 baud to gibberish.

@gitcnd
I run ESP32/S3/ESP8266 with mpremote without any problems ( Flashing , connecting , resuming, rebooting)
Can you tell exactly what serial interface your boards are using ?

My fixes determine based on OS=="win" and portinfo[0].manufacturer != "Microsoft" as that was the best rule i could make based on my hardware.
The part of fixes that you propose appear to be a copy of the exact code I put in earlier, .

I ask as I spend quite a lot of time in determining, then fixing and and validating across ports and OSSes.
Also a change to one problem then can create another ( that's why #11076 was needed)
As there are (unfortunately) no integration of HIL tests for this in the MicroPython repo, and there was some refactoring since by @jimmo, possibly errors could have crept back in.

So before merging any changes I would propose to:

1. make sure to do such tests across host platforms (I can dig up my test suite if needed)
2. make sure that we do not have two different sections of code applying a similar fix under different conditions
3. it does make sense to me to add some sort of port-reset option, across all host platforms to be consistent.
   (FWIW "reset = hard reset" is already used in mpremote, so perhaps best avoid confusion)