version 2.5.2 does not work when ESP8266 uses auto-reset

[Erik84750]

----------------------------- Delete below -----------------------------

Basic Infos

• [x ] This issue complies with the issue POLICY doc.
• [x ] I have read the documentation at readthedocs and the issue is not addressed there.
• [ x] I have tested that the issue is present in current master branch (aka latest git).
• [ x] I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• [ x] I have filled out all fields below.

Platform

• Hardware: [ESP-12]
• Core Version: [2.5.2]
• Development Env: [Arduino IDE]
• Operating System: [Windows]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [dio]
• Flash Size: [4MB]
• lwip Variant: [v2 Lower Memory]
• Reset Method: [ck]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz]
• Upload Using: [SERIAL]
• Upload Speed: [115200)

Problem Description

When using external hardware to set the ESP8266 in programming mode (low signals on GPIO0 and CH_PD (or RST)) this version 2.5.2 does not work. This is when using a serial interface such as n FTDI (USB - to - RS232 converter) which connects to the RX and TX pins on the ESP8266.
Version 2.5.0 works ok.
In other words: an "auto-reset" hardware circuit that uses an external "low" signal (for example DTR from the FTDI-adapter) to allow automatic setting of the ESP8266 in programming mode on start-up and to allow downloads via RX and TX connections, does not work with this 2.5.2 version.

[devyte]

The esptool has changed.
This is a custom board? Does PR #6429 work for you? You'll have to install latest git (instructions in readthedocs), then pull the pr into a local branch to test it.

[Erik84750]

Thank you for your reply. After reading PR #6429 (which I am sorry to say goes beyond my skills to fully understand in details but I understand the essentials to know what is being proposed) I think this hits the nail on the head.
My board is indeed a custom board. And it uses DTR to reset (using hardware) the ESP8066 CH_PD (not RST due to stability issues).
So if (as I think is proposed in PR #6429) the previous possibilities for ck are restored ("
@f5soh
Keep previous resetmethod names and translate to esptool.py options ") then my problem should be solved.
My board uses the low-going pulse of DTR to pull low both GPIO0 and CH_PD, but while CH_PD is allowed back to 3.3V together with DTR, GPIO0 is kept "low" a bit longer, enough to bring the ESP8266 in programming mode.

[devyte]

Is this issue still valid with latest git? #6429 is merged.

[Erik84750]

Yes, issue is still valid. Version 2.5.1and higher do not acknowledge for ESP8266 devices where auto-reset is available.
Versions 2.5.1 and higher require power removed and restored for the controller to work after being programmed.
It would be very usefull if an option were present in the ESP8266 configuration table to allow an auto-reset (which does not require a hard power reset) to do its job.

[devyte]

@Erik84750 please retest with 2.6.3 or latest git. I can't reproduce any problems with my ESP12-based devices, but then I'm using standard Wemos d1 mini r2s.

[Erik84750]

@devyte: I will retry with 2.6.3. This will be next Thursday at the earliest, but I will feedback here asap.
The issue is that I have a custom board that uses the DRT signal to set the ESP8266 in program mode; once programmed the ESP8266 automatically is set back to run mode. This worked fine until version 2.5.0 ; I will try to set various options in the 2.6.3 version to verify if restart after programming is possible without hard reset (removing and replugging power).

[Tech-TX]

CH_PD should be similar to a full power cycle. If I knew how you were delaying GPIO0 I could probably duplicate your situation with an ESP-07. Are you also controlling GPIO15?
https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process#esp-boot-modes

[Erik84750]

Hi, indeed, version 2.6.3 allows the ESP8266 to be reset to normal mode after programming.
To Tech-TX: I use this idea to get the ESP8266 in auto reset mode:

DTR pulls GPIO 0 instantly low, and a high pass filter (cap in series with resistor to determine the RC constant) delays CH_PD restart.

[devyte]

Closing as already resolved in view of last comment.