Skip to content

pyboard: Fix espxx boards hanging in bootloader after reset button. #11076

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 4, 2023

Conversation

Josverl
Copy link
Contributor

@Josverl Josverl commented Mar 19, 2023

Updated Logic

The updated logic will only set the dtr/rts signals for boards that do not use standard Microsoft drivers( based on the manufacturer)
It would also be possible to check against a list of known driver manufactures (like 'wch.cn' or 'Silicon Labs' ) but this would require a list of known drivers for all ports. (which I do not have)

fixes: #11075

@github-actions
Copy link

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
        rp2:    +0 +0.000% PICO

@dpgeorge dpgeorge added bug tools Relates to tools/ directory in source, or other tooling and removed bug labels Mar 22, 2023
# ESPxx boards and ESP32 boards use RTS/CTS for flashing and boot mode selection
# DTR False, to avoid using the reset button will hang the MCU in bootloader mode
# RTS False, to prevent pulses on rts on serial.close() that would POWERON_RESET an ESPxx
self.serial.dtr = False # DTR False = gpio0 High = Normal boot
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why this was previously True and is now False?

Also, if Windows doesn't set DTR/RTS by default, wouldn't it be good to set them for all drivers? Why can't it just set them both False for all drivers? Or at least True/False for Microsoft drivers?

Copy link
Contributor Author

@Josverl Josverl Mar 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the reasoning in the Issue , perhaps not the best place.
let me copy it here :

I'm not sure why this was previously True and is now False?
as that solve one problem (Reset on disconnect) , but now I found it created a 2nd one (Hang in bootloader )

to solve both False ,+ False is needed for espxx , but that would then block stm32 and others

any unconditional combination ends up blocking normal operation on some type of board or another.
9 see below truth table)
as to the why: I suspect that the non-Microsoft drivers may be less strict in the de-initialization , causing the spikes, but that is just speculation based on my professional bias.

A simple overview (for windows only) :

DTR CTS ESP8266 ESP32 STM32 SAMD51 RP2040
unspecified unspecified ❌ Win32:Reset on disconnect ❌ Win32:Reset on disconnect ✅ OK ✅ OK ✅ OK
True False ❌ Win32:Hang in bootloader ❌ Win32:Hang in bootloader ✅ OK ✅ OK ✅ OK
False False ✅ OK ✅ OK ❌ No Repl ❌ No Repl ❌ No Repl
True True ❌ Win32:Reset on disconnect ❌ Win32:Reset on disconnect ❌ No Repl ❌ No Repl ❌ No Repl
False True ❌ Win32 : Reset on disconnect ❌ Win32 : Reset on disconnect ❌ No Repl ❌ no Repl ❌ No Repl
serial.manufacturer wch.cn Silicon Labs Microsoft Microsoft Microsoft
serial.description USB-SERIAL CH340 Silicon Labs CP210x USB to UART Bridge USB Serial Device USB Serial Device USB Serial Device

Updated Logic

The updated logic will only set the dtr/rts signals for boards that do not use standard Microsoft drivers( based on the manufacturer)
It would also be possible to check against a list of known driver manufactures (like wch.cn or Silicon Labs ) but this would require a list of known drivers for all ports. ( which I do not have)

serial.manufacturer DTR CTS ESP8266 ESP32 STM32 SAMD51 RP2040
== "Microsoft" unspecified unspecified - - ✅ OK ✅ OK ✅ OK
!= "Microsoft" (wch.cn,Silicon Labs) False False ✅ OK ✅ OK - - -

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks for the details. That makes sense then.

This is a follow up to d263438, which
solved one problem (reset on disconnect) but introduced a second one (hang
in bootloader).

To solve both probles, False/False is needed for DTR/RTS for ESPxx, but
that would then block stm32 and others.  Any unconditional combination of
DTR/RTS ends up blocking normal operation on some type of board or another.

A simple overview (for windows only):

  DTR          CTS            ESP8266/ESP32          STM32/SAMD51/RP2040
  unspecified  unspecified    Reset on disconnect    OK
  True         False          Hang in bootloader     OK
  False        False          OK                     No Repl
  True         True           Reset on disconnect    No Repl
  False        True           Reset on disconnect    No Repl

  serial.manufacturer:        wch.cn/Silicon Labs    Microsoft

  serial.description:         USB-SERIAL CH340 /     USB Serial Device
                              CP210x USB to UART
                              Bridge

The updated logic will only set the DTR/RTS signals for boards that do not
use standard Microsoft drivers (based on the manufacturer).  It would also
be possible to check against a list of known driver manufactures (like
wch.cn or Silicon Labs) but this would require a list of known drivers for
all ports.

Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>
@dpgeorge dpgeorge force-pushed the mpremote/esp_no_bootloader branch from 9f5c97c to 9f74ffb Compare April 4, 2023 03:30
@dpgeorge dpgeorge merged commit 9f74ffb into micropython:master Apr 4, 2023
@Josverl Josverl deleted the mpremote/esp_no_bootloader branch April 4, 2023 23:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tools Relates to tools/ directory in source, or other tooling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

mpremote/pyboard: ESPxxx boards hang in firmware bootloader after hardware reset via button .
2 participants