vNext: terminal forces ESPxxx boards into bootloader on MCU reset

[Josverl]

What are the steps to reproduce this issue?

1. install vNext
2. connect ESP32 os ESP8266 board to serial
3. Connect to the serialport and open a Pymakr Terminal
4. press hardware reset on the board

What happens?

• the board reboots and enters the bootloader to download new firmware
• this issue does not show on pybv1.1 or Pi Pico / RP2040 types of boards, as they do not use the serial signals to direct the bootloader into flashmode.
• I do not have access to any pycom boards to verify the behavior on those models.

What were you expecting to happen?

• hardware reboot and reconnection to the exiting terminal ( behavior in v1 )

Any logs, error output, etc?

yes , for both ESP32 , ESP8266

MicroPython v1.17 on 2021-09-02; ESP32 module (spiram) with ESP32
Type "help()" for more information.
>>> 
[[[ Press hardware reset ]]]
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x7 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

Similar with an ESP8266

MicroPython v1.14 on 2021-02-02; ESP module with ESP8266
Type "help()" for more information.
>>>
[[[ Press hardware reset ]]]
 sdlܟ<�l�<♥
♦
�♦l�
c|��♥�‼�r�#�♦c��gn�dog���♦cp8ćlsd;l

Note that on both MCUs a MicroPython import machine; machine.reset() continues to work. As this does only reset the VM, rather than the chip , it is a clear indication that the strapping pins are set Low. ( signals are usually inverted on the autoflash interfaces).

Any other comments?

I fixed this same issue in v1 by setting dtr and rts high according to the ESP docs

    if (process.platform == 'win32') {
      // avoid MCU waiting in bootloader on hardware restart by setting both dtr and rts high
      this.stream.set({ rts: true });
    }

What versions of software are you using?

Operating system: Windows 11 Pymakr version: Vnext

[Josverl]

@jakobrosenberg , note that it is worth the effort to test if the same fix would be needed on mac/linux, or if that the serialport interface behaves differently these by convention. I just fixed it for windows as there were no reports of the same on other platforms.

a quick test on debian/arm64 does not show the same issue.

• [x] Win32
• [ ] OS: Linux arm64 5.15.32-v8+ - OK
• [ ] Mac

[jakobrosenberg]

Hi @Josverl . Did we merge your fix?

[Josverl]

That fix has been in V1 since some 4 years:

• https://github.com/pycom/pymakr-vsc/issues/16
• https://github.com/pycom/pymakr-vsc/pull/19

For V2 the serialport interface has been outsourced to micropython-ctrl-cont for which I raised this PR as I think you have seen.

• https://github.com/jakobrosenberg/micropython-ctl/pull/1

[Josverl]

Thanks for merging https://github.com/jakobrosenberg/micropython-ctl/pull/1, I did a quick test using the updated module and generic ESP32 and ESP8266 boards and that indeed avoids the MCU to wait in the bootloader

.vscode\extensions\pycom.pymakr-preview-2.13.0> npm install micropython-ctl-cont then connect and reset

MicroPython v1.18 on 2022-01-17; ESP32 module with ESP32
Type "help()" for more information.
>>> import machine;machine.reset()
WebREPL is not configured, run 'import webrepl_setup'
MicroPython v1.18 on 2022-01-17; ESP32 module with ESP32
Type "help()" for more information.
>>> 

also verified to work for the hardware reset menu option.

fixed by : 4f0741124bada03c3aecc83a3fc888cccaac4e28