Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flashing issues with esptool (2.5.1 and 2.5.2 relases with esptool) #6296

Closed
mcer12 opened this issue Jul 13, 2019 · 17 comments
Closed

Flashing issues with esptool (2.5.1 and 2.5.2 relases with esptool) #6296

mcer12 opened this issue Jul 13, 2019 · 17 comments
Labels
waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.

Comments

@mcer12
Copy link

mcer12 commented Jul 13, 2019

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.

@mcer12 mcer12 changed the title esptool flashing issue Flashing issues with esptool (2.5.1 and 2.5.2 relases with esptool) Jul 13, 2019
@earlephilhower
Copy link
Collaborator

@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?

@earlephilhower earlephilhower added the waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. label Jul 14, 2019
@f5soh
Copy link
Contributor

f5soh commented Jul 30, 2019

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.

@mcer12
Copy link
Author

mcer12 commented Jul 30, 2019

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?

@f5soh
Copy link
Contributor

f5soh commented Jul 30, 2019

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...

@d-a-v
Copy link
Collaborator

d-a-v commented Jul 31, 2019

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

@f5soh
Copy link
Contributor

f5soh commented Jul 31, 2019

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.

@mcer12
Copy link
Author

mcer12 commented Jul 31, 2019

@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?

@f5soh
Copy link
Contributor

f5soh commented Jul 31, 2019

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

@mcer12
Copy link
Author

mcer12 commented Jul 31, 2019

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.

@f5soh
Copy link
Contributor

f5soh commented Jul 31, 2019

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

@denisfou
Copy link

denisfou commented Aug 9, 2019

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"

@projectgus
Copy link

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?

@f5soh
Copy link
Contributor

f5soh commented Aug 19, 2019

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 ?

@IllyaMoskvin
Copy link

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.

@ranger81
Copy link

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

@JAndrassy
Copy link
Contributor

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

@earlephilhower
Copy link
Collaborator

#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting for feedback Waiting on additional info. If it's not received, the issue may be closed.
Projects
None yet
Development

No branches or pull requests

9 participants