Arduino: Flashing issues with esptool (2.5.1 and 2.5.2 relases with esptool)

Created on 14 Jul 2019  路  17Comments  路  Source: esp8266/Arduino

Esptool erases memory and attempts to reset the device via RTS before upload which won't work if the device doesn't have a reset button or auto-reset circuitry. Devices like Sonoff plugs and others can't be flashed with this. The reset between memory wipe and actual upload should be removed.

waiting for feedback

Most helpful comment

After some tests, adding "--after soft_reset" to the 2nd command allow ESP to restart after flashing.

In platform.txt the upload pattern becomes:

tools.esptool.upload.pattern="{cmd}" "{runtime.platform.path}/tools/upload.py" --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" {upload.erase_cmd} --end --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" --before no_reset_no_sync --after soft_reset write_flash 0x0 "{build.path}/{build.project_name}.bin" --end

All 17 comments

@mcer12, I don't think any of the maintainers have such a device. Would you be able to submit a PR with your proposed change?

Hi,
I encountered the same issue with a ESP-01 and basic usb serial + programming button since esptool is used.
The "Only Sketch" works fine but others options erasing or partially erasing flash fails while starting binary upload.

In platform.txt i added "--before no_reset_no_sync" before the write_flash command:

tools.esptool.upload.pattern="{cmd}" "{runtime.platform.path}/tools/upload.py" --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" {upload.erase_cmd} --end --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" --before no_reset_no_sync write_flash 0x0 "{build.path}/{build.project_name}.bin" --end

and replaced
generic.menu.wipe.none.upload.erase_cmd=version
with
generic.menu.wipe.none.upload.erase_cmd=flash_id
into the board.txt so the first command do something with serial without erase_flash or erase_region.

This workaround allow the "Flash erase: > Only Sketch / Sketch + Wifi settings / All flash contents"
3 options to work in my case, not sure what happens for boards with a functional RTS reset.

Glad somebody picket this up, thanks @f5soh . The erase should stay there otherwise you will basically just skip the erase step or do I get this wrong?

I'm not sure what do you mean, with the workaround above all the options works here:
1 - Only sketch upload (without erase or partial erase, as previously)
2 - Partial erase (wifi settings) + sketch upload
3 - Full erase + sketch upload

While adding "--before no_reset_no_sync" to the second part of command (used for upload) in platform.txt, the 2 and 3 case works but case 1 do not work any more.

To make the simple sketch upload (aka erase=none) to work again, the first command (used for erase options) is "flash_id" instead of "version" which just output esptool version without talking with serial.

Only sketch output:

esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: 68:c6:3a:ab:c9:55
Uploading stub...
Running stub...
Stub running...
Manufacturer: 85
Device: 6014
Detected flash size: 1MB
Hard resetting via RTS pin...
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting...
Chip is ESP8266EX
Features: WiFi
MAC: 68:c6:3a:ab:c9:55
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Flash params set to 0x0320
Compressed 412976 bytes to 269980...

Writing at 0x00000000... (5 %)
Writing at 0x00004000... (11 %)
Writing at 0x00008000... (17 %)...

Partial erase (wifi settings) + sketch upload output:

esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: 68:c6:3a:ab:c9:55
Uploading stub...
Running stub...
Stub running...
Erasing region (may be slow depending on size)...
Erase completed successfully in 0.1 seconds.
Hard resetting via RTS pin...
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting...
Chip is ESP8266EX
Features: WiFi
MAC: 68:c6:3a:ab:c9:55
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Flash params set to 0x0320
Compressed 412976 bytes to 269980...

Writing at 0x00000000... (5 %)
Writing at 0x00004000... (11 %)
Writing at 0x00008000... (17 %)...

Full erase + sketch upload output:

esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: 68:c6:3a:ab:c9:55
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 0.0s
Hard resetting via RTS pin...
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting...
Chip is ESP8266EX
Features: WiFi
MAC: 68:c6:3a:ab:c9:55
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Flash params set to 0x0320
Compressed 412976 bytes to 269980...

Writing at 0x00000000... (5 %)
Writing at 0x00004000... (11 %)
Writing at 0x00008000... (17 %)...

Here the full erase take only 0.0s but indeed my eeprom contents are lost...

What was the "Reset Option" working entry before we used esptool, "ck" or "none" ?

Tested with 2.5.0: Upload works in both cases (ck or none) and esp is running at end.
With esptool (2.5.2) i need to unplug/replug to get esp running.

@f5soh What I meant is that since you removed the wipe it only rewrites the memory. That lead me to believe that with your changes no matter which option of erase memory you pick, it'll act as if "only sketch" was selected. Or am I wrong here?

Look output for every option above, full erase (eeprom settings lost) or partial erase still done.

Oh, sorry I see it now thank you! Any idea why the device doesnt run at the end and needs to be resetted manually? But this is a minor issue I think.

After some tests, adding "--after soft_reset" to the 2nd command allow ESP to restart after flashing.

In platform.txt the upload pattern becomes:

tools.esptool.upload.pattern="{cmd}" "{runtime.platform.path}/tools/upload.py" --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" {upload.erase_cmd} --end --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" --before no_reset_no_sync --after soft_reset write_flash 0x0 "{build.path}/{build.project_name}.bin" --end

After some tests, adding "--after soft_reset" to the 2nd command allow ESP to restart after flashing.

In platform.txt the upload pattern becomes:

tools.esptool.upload.pattern="{cmd}" "{runtime.platform.path}/tools/upload.py" --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" {upload.erase_cmd} --end --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" --before no_reset_no_sync --after soft_reset write_flash 0x0 "{build.path}/{build.project_name}.bin" --end

Thank you :)

It worked for me but without "--before no_reset_no_sync"

Hi all,

Greetings from the esptool side of the fence.

If I understand correctly, if a full flash erase is configured then ESP8266 Arduino currently needs to run esptool.py erase_flash and then esptool.py write_flash as two separate commands.

Would an option like esptool.py write_flash --full-erase ... be helpful, to do both in one command?

Hi,
sorry for the late reply.

One command including the erase option (full/partial) will be useful i think.

Previous upload tool was using those reset methods:

  • none: No DTR/RTS manipulation
  • ck: RTS controls RESET or CH_PD, DTR controls GPIO0
  • nodemcu: GPIO0 and RESET controlled using two NPN transistors as in NodeMCU devkit.
  • dtrset: DTR is set during serial communications

Since 2.5.1 all boards are handled with default reset method (--before default_reset --after hard_reset) whatever the reset option selected in menu or defined in board.txt

boards.txt.py will need some changes to match the current reset methods with new upload tool as no_reset, no_reset_no_sync and default_reset.

After testing with a nodemcu board and esptool.py, seems working with default reset method so maybe previous nodemcu+dtrset becomes default_reset but how about the previous 'ck' method ?

I'm new, so I'm not entirely sure if this is related, but since upgrading from v2.5.0 to v2.5.2, I'm still able to upload sketches, but the board does not reset automatically anymore after the upload is complete. After resetting it manually, it runs the new sketch fine. I'm using the Adafruit HUZZAH ESP8266 breakout.

Just wanted to share my experience. Sounds similar to the issue @f5soh described above.

Hi,
I can confirm having issues with flashing since upgrading to 2.5.1 and 2.5.2. With 2.5.0 everything was fine for me. I tried to flash an ESP12-F module with GPIO0 tied to GND. Upload seems to be successful in the Arduino IDE (with 2.5.1 and 2.5.2), but the ESP8266 is no properly running my code. It looks like it's constantly crashing and rebooting. Haven't had the chance to check the serial output so far. Uploading the same code with 2.5.0 works flawlessly and the code runs fine. I assume it has something to do with the new upload method?!
Thanks

Hi all,

Greetings from the esptool side of the fence.

If I understand correctly, if a full flash erase is configured then ESP8266 Arduino currently needs to run esptool.py erase_flash and then esptool.py write_flash as two separate commands.

Would an option like esptool.py write_flash --full-erase ... be helpful, to do both in one command?

yes, please

6429 changed the reset method to something we believe to be more compatible. Closing this issue, but if you have something similar even with the latest GIT or release, please open a new issue so we can track it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hulkco picture hulkco  路  3Comments

rudydevolder picture rudydevolder  路  3Comments

treii28 picture treii28  路  3Comments

mechanic98 picture mechanic98  路  3Comments

Marcelphilippeandrade picture Marcelphilippeandrade  路  3Comments