It takes 3-5 minutes to decide that a connection cannot be established

[balloob]

ESPLoader is initialized by calling main_fn. This function calls detect_chip, which in turn calls connect which triggers the connection sequence.

If a device requires the BOOT mode to be held down to start flashing, the connection will fail. Currently it takes 4-5 minutes on my machine before it raises the error Failed to connect with the device. This seems too long.

The default attempts number for connect is set to 7. This means that 7 times it tries the following:

• Calls connect_attempt with esp32r0_delay set to false
• Calls connect_attempt with esp32r0_delay set to true

main_fn allows passing in a mode that is passed down to connect_attempt. It is defined as type string, it defaults to default_reset. It can be set to no_reset to skip resetting the device inside connect_attempt. The resetting takes quite some time, with hardcoded sleeps. If esp32r0_delay is true, there is a call to sleep 2 seconds!

Because our connection runs connect_attempt twice for each attempt, we are trying to attempt to connect 14 times. That's already twice as many as the Python tool does by default.

Below a screenshot of the console logs. This is not a full single attempt (out of 7), as it cuts off the 2nd call to connect_attempt with esp32r0_delay set to true. The screenshot already spans 26 seconds. It has another 6 full attempts to go!

Looking at esptool, it also resets between every attempt, but it uses different reset strategies that leverage different delays https://github.com/espressif/esptool/blob/master/esptool/loader.py#L567. The strategies are defined at https://github.com/espressif/esptool/blob/master/esptool/reset.py#L61. By default the sleep delay between RTS setting is 0.05 and 0.55 for a 2nd reset attempt. There are also calls to 0.1 and 0.2s sleeps. There definitely is never a 2s sleep 👀 Also there is no reference to what esp32r0_delay is, it's not in the Python tool.

Summary:

• What is esp32r0_delay?
• Why are we doing two connection attempts for each attempt, doubling the number of attempts what esptool does?
• Are there ways we can speed this up further?

[igrr]

What is esp32r0_delay?

espressif/esptool@2d72f56#diff-b035aa3701bf24cdb68151b147c0cfe693bbb1b27812a779f13d4255bdff1fc7L597

Agree that some delays here are probably excessive, we can speed this up.

[balloob]

If esptool has removed it, can we remove it too? Or maybe we can guard it for Windows users only based on the user agent string ?

[RushikeshPatange]

@balloob, @igrr, and @brianignacio5, could you please provide any updates regarding this particular issue?

[brianignacio5]

Do we still have these issues ? @RushikeshPatange @balloob ?

[RushikeshPatange]

Do we still have these issues ? @RushikeshPatange @balloob ?

@brianignacio5, I have used esptool-js (example) with following dev-kits:

• ESP32-C3-MINI-1U
• ESP32-WROOM-32

I encountered this issue while working with the ESP32-WROOM-32 DevKit. Sometimes it connected automatically, but most of the time it took too long to connect. I found a workaround: pressing the boot button on the DevKit allowed it to connect immediately. Maybe this issue is occurring because I'm using an older ESP32-WROOM-32, but don't know the actual cause.

ESP32-WROOM-32 Connection Screenshot: ( Stuck at connection )

[brianignacio5]

Could you try my fork in https://brianignacio5.github.io/esptool-js/ which implement #160 changes ?