-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
esptool stopped working with v4.2 (ESPTOOL-1002) #1059
Comments
Hi Marcel, First of all, I am finally working on addressing all of the ideas mentioned in #208. In the next major release Now, to your issue - I am pretty sure this is caused by the way the stub flasher code is stored in esptool. After the MAC address is printed ( If that turns out not to be the culprit, maybe we could look at the specific commit that causes this - Let me know if this helps! |
Thank you Radim for looking into this so quickly. It sounds as if had heard of the PyFlasher before?
Hhhmm, I'm currently clutching at straws, but your description matches the behavior I'm seeing, thanks! PyFlasher is built with PyInstaller. I might have to tweak its configuration to include those "extra" files in the bundle (I vaguely remember there being such options). |
Of course, I have used it myself many times. Also, as it's one of the most popular GUIs for esptool, I have an eye on the project!
To verify, you can add the
Check the |
I can add that I too see the same behaviour with a fork of PyFlasher that I am working on... ![]() It also hangs at the mac address. However I also note that this only happens on the compiled binary. If I run PyFlasher from within VSCode, it works perfectly. This may support what @radimkarnis has reported I will try the --add-data argument suggested and report back |
I don't know how PyFLasher handles the output, but I don't think esptool is "hanging". There is probably a To support this, let's have a look at the new clue happening in This note is unrelated to the issue, but happens in the try:
esp = esp.run_stub()
except Exception:
# The CH9102 bridge (PID: 0x55D4) can have issues on MacOS
if sys.platform == "darwin" and esp._get_pid() == 0x55D4:
print()
print(
"If issues persist, "
"try installing the WCH USB-to-Serial MacOS driver."
)
raise |
Yes hanging is perhaps a poor choice of words. Execution appeared to stall. Unfortunately I was unable to see what was actually going as logs did not reveal anything to me. But some research highlighted that others have had the same issue and it was as you described related to the inclusion of the stubs files. So after a time and some experimentation I managed to get my fork of pyflasher working with esptool v4.8.1
This is my requirements.txt
The main changes were to add the stubs folders to the 'datas' section in the specs file... (pyflasher uses specs files to handle CLI options) 'build-on-mac.spec'
Filepaths could obviously be handled a bit more elegantly but it is working 😃 |
There's a minimally clever piece of code that redirects standard out to a UI component (called PyFlasher does not handle esptool exceptions explicitly except @DeeEmm thanks for testing Radim's proposal! |
@marcelstoer cool! I believe we can close this ticket, correct? |
Thanks again for all your support! The fix landed with marcelstoer/nodemcu-pyflasher@2d5daab. |
Operating System
macOS 14.7
Esptool Version
4.2
Python Version
3.12
Chip Description
ESP32-WROVER-B
Device Description
I am the author and main contributor of the popular esptool GUI "NodeMCU PyFlasher" (close to 500k downloads on GH): https://github.com/marcelstoer/nodemcu-pyflasher. Also, I initially created #157 in 2016 which Angus later rephrased in #208.
Side note, my tool just collects input from the GUI to build the esptool CLI flags and invokes it directly.
While analyzing the esptool v3 --> v4 upgrade issue in my project (marcelstoer/nodemcu-pyflasher#105), I noticed that esptool stopped working on v4.2 and everything more recent. When it fails, it simply hangs. I went through the v4.2 release notes, but nothing mentioned there would explain the behavior I am seeing.
I iterated through a number of esptool versions using the same hardware and the same CLI switches. Hence, the command created by my app was always the same:
esptool.py --baud 921600 --after no_reset write_flash --flash_size detect --flash_mode dio 0x00000 /Users/marcelstoer/Data/my-app.bin
. Please find the output below.v3.3.3
The baseline. Used by the latest version of my app (released in 2021).
(I skipped the "Writing at" progress output and everything that follows)
v4.0.1
Despite the refactoring that came with v4, this version still works just like before. I also tested v4.1 which behaves the same as v4.0.1.
(I skipped the "Writing at" progress output and everything that follows)
v4.2
After dumping the MAC address, esptool just hangs i.e. there's no further output after
MAC: 8c:4b:14:04:53:a4
. The behavior is the same with v4.2.1 and v4.5.1.v4.8.1
The behavior remains the same as with v4.2+ expect for new error/warning printed after the MAC address. It says
but it doesn't say which issue.
Hardware Configuration
ESP32-WROVER-B is embedded into the ThingPulse ESP32 ePulse Feather dev board. No components attached to it.
How is Esptool Run
from within PyFlasher
Full Esptool Command Line that Was Run
esptool.py --baud 921600 --after no_reset write_flash --flash_size detect --flash_mode dio 0x00000 /Users/marcelstoer/Data/my-app.bin
Esptool Output
More Information
No response
Other Steps to Reproduce
No response
I Have Read the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: