'Disable stub if connecting to an unsupported chip' commit breaks flashing on my supported chip (ESPTOOL-258)

[Habbie]

Operating system

Raspberry PI OS 10

Python version

3.7.3

What Chip

ESP8266EX

What development board or other hardware is the chip attached to

https://www.aliexpress.com/item/4000204281213.html

flashing setup can be partially seen at https://imgur.com/a/bUr66as if you're interested, but I don't think it's important for this bug report.

Is anything else attached to the development board, except for the serial flasher connections?

microusb for power; GND/RX/TX to the right pins on a Pi3.

Are you running esptool.py from an IDE such as Arduino or Eclipse?

no, bash.

Full esptool.py command line that was run:

~/.local/bin/esptool.py -p /dev/ttyS0 write_flash 0 ~/esphomeirbridge.bin

Full output from esptool.py

esptool.py v3.2-dev
Serial port /dev/ttyS0
Connecting...
Failed to get PID of a device on /dev/ttyS0, using standard reset sequence.

Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 8c:ce:4e:eb:9e:c3
Traceback (most recent call last):
  File "/home/pi/.local/bin/esptool.py", line 7, in <module>
    exec(compile(f.read(), __file__, 'exec'))
  File "/home/pi/esptool/esptool.py", line 4613, in <module>
    _main()
  File "/home/pi/esptool/esptool.py", line 4606, in _main
    main()
  File "/home/pi/esptool/esptool.py", line 4120, in main
    elif esp.stub_is_disabled:
AttributeError: 'ESP8266StubLoader' object has no attribute 'stub_is_disabled'

Do you have any other information from investigating this?

I suspected 1c9fe70 broke this. I checked out the commit before it,
1ca08af, and then I could flash without trouble.

Is there any other information you can think of which will help us reproduce this problem?

I don't think so.

[radimkarnis]

Hi @Habbie,
thanks for reporting this and for identifying the source of the issue.

The fix is already in the works!

Radim

[moefear85]

I'm facing the same issue. I'm using a rts/dtr capable pty<->pty bridge between esptool and a usb-uart bridge. The PID error always comes up, whereas the Exception only occasionally occurs, and it generally succeeds in the same way as if esptool directly communicated with the usb-uart. Without the pty<->pty bridge, no PID error occurs at all.

I suspect esptool's timings for rts/dtr are too tight, as it always expects to be directly connected to the target board, hence doesn't tolerate lag/latency when re-/setting the chip. Is it possible to extend esptool so that various timeout values can be passed on the command line? Even the 3 second timeout during flashing is occasionally limiting when flashing over a transparent wifi-bridge, with or without the socket:// option.

[radimkarnis]

@moefear85, this issue is completely unrelated to your question. We will continue the conversation in your issue ticket.