Update esptool reset method

[f5soh]

Related to #6296

This is my first PR here, so be patient :)

Since 2.5.1 the upload tool moved to esptool.py, reset methods are deprecated and all boards use in fact the default_reset with dtr.

First commit update the reset methods available:

• none becomes as 'no dtr' in menu,
• nodemcu, dtrset as 'dtr',
• ck (fixed) temporary handled like 'none' (not sure about this),
• new reset method 'no dtr, no_sync' in extra menu

Second commit is a workaround because the flash erase and write_flash is done in two commands and allow the two consecutive commands using 'no dtr, no_sync' without a reset circuit on board.
This workaround will not be needed if esptool.py handle the erase and write in one command.

[earlephilhower]

For a first PR, you did pretty well! Normally the boards.txt or an astyle problem hits users.

[earlephilhower]

I think @d-a-v is the expert on this, but he's on vacation for another week, so do please be patient.

[f5soh]

No issue, this PR still need some work and more information about how the ck method can be supported with esptool.py

Will be rebased when ready for merge

[d-a-v]

I would mention the old names with something like this:

• dtr (aka nodemcu)
• no dtr (aka ck)

so users are not lost

[f5soh]

Good idea, added changes.

[earlephilhower]

@f5soh, you'll need to pull in master to fix the compile problems the CI system is having. For some reason I can't do it for you from the website just now.

[f5soh]

Seems the build.py need update for tests:

Arduino/tools/build.py

Line 55 in 901410f

'ResetMethod=nodemcu'.format(**vars(args))

Error resolving FQBN: getting build properties for board esp8266com:esp8266:generic: invalid value 'nodemcu' for option 'ResetMethod'

[earlephilhower]

Ah, yeah. You'll need to fix that in your PR, too. There was also just 2 nights ago an update to the Arduino.cc executable nightly build which changes the FQBN format. See #6461 . Double whammy.

[d-a-v]

@f5soh Would you mind renaming back the internal fqbn part to what it currently is (nodemcu and not dtr, ck and not no-dtr) - It is OK to leave the displayed name though.
Mainly because of annoyance following such change, like #5572 (comment) (and included links, also the number of references to it show how many people are affected by such change).

[f5soh]

I keep all previous resetmethod names and simply translate them to new esptool.py options.
Hope this matches what you are talking about.

I can squash reset method changes in one commit for better clarity.

[d-a-v]

I am concerned about this change.
flash_id asks for a connection to the esp, while version is a no-op which is what we need in this case.

[f5soh]

Take a board without reset circuit and version as first default command as you want :

• "Only sketch" works only with the "no dtr" reset method
• "Flash erase" works only with the "no dtr, no sync" reset method or second programming step will fail.

Do we really want the user change the reset method every time the erasing flash option is changed ?

With flash_id, both "Only sketch" and "Flash erase" works with "no dtr, no sync" reset method.

As described, this is a workaround needed since the esptool do the erasing and programming in two consecutive commands. May need also the "no dtr, no sync" reset method for all "ck" boards.

[sampetrosyan]

Does anyone know what's wrong here? after I upload the code successfully, below that it says

Leaving...

Hard resetting via RTS pin..

[devyte]

What is pending here?

[d-a-v]

I'd merge but release is too soon, feedback from users with issues is welcome.
I tested it with nodemcu reset method and nothing seems broken.
If anyone with an esp-01 progammer could also test it, that'd be great.
@mcer12 @denisfou @IllyaMoskvin @ranger81

[d-a-v]

@f5soh
You'd need to update your local master, then on your branch locally remove boards.txt, merge master and regenerate boards.txt

[Jason2866]

@d-a-v There are more users using NodeMCU and wemos minis than users using ESP-01 devices with special programmer(s). There is no standard ESP-01 programmer. I have two different types... No change in behaviour of this two. One works as before (reset).
The other did not reset the device before this PR nor with this PR

IMHO: Merging this PR will solve more problems, than it maybe! generates

[d-a-v]

@Jason2866 This PR is not mergeable as-is and I don't know why.
@f5soh I made a subPR to see how it goes.

[Erik84750]

The issue I described in version 2.5.2 does not work when ESP8266 uses auto-reset #6631 is that when using the ESP8266 in conjunction with auto-reset circuitry (using DTR to set the ESP8266 in programming mode, and automatic restoring to normal mode after program download) there needs to be a hard (power-off power-on) reset to run the ESP8266 in normal mode.
Unless I am wrong, versions 2.5.1 and higher do not acknowledge the use of auto-reset circuitry, therefor requiring users to do a hard reset instead of automatically restarting in normal mode.

[JAndrassy]

The issue I described in version 2.5.2 does not work when ESP8266 uses auto-reset #6631 is that when using the ESP8266 in conjunction with auto-reset circuitry (using DTR to set the ESP8266 in programming mode, and automatic restoring to normal mode after program download) there needs to be a hard (power-off power-on) reset to run the ESP8266 in normal mode.
Unless I am wrong, versions 2.5.1 and higher do not acknowledge the use of auto-reset circuitry, therefor requiring users to do a hard reset instead of automatically restarting in normal mode.

and why don't you try the 2.6.1 which has this fix?

[Erik84750]

Oh I am so sorry, of course I will try it, and asap! I am not sufficiently familiar yet with the workings of Github, my apologies for undue inconvenience.