-
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.py] Sporadic "This command (0x14) is not supported in Secure Download Mode" with USB_SER_JTAG (ESPTOOL-577) #813
Comments
Does not repro in UART mode |
Hi @chipweinberger, Can you please try using the latest esptool from master and confirm that it works when you specify the chip with EDIT: ok now I see that I actually accidentally found another bug (I was in UART mode). I just reproduced the issue you are describing - 50/50 fail/success. I will look into it |
Update: This happens only when:
For some reason, the ROM responds with an Fortunately, this seems to be only a minor inconvenience that happens only in particular conditions (see above). This can be easily solved on the user side by either running the command again OR not specifying the chip with I am going to try to come up with a solution in esptool. Will leave this open until then. |
Thanks for the update. That's interesting. I added |
@chipweinberger this and the originally reported issue should be now fixed! Could you please try pulling the latest |
* fix(setup): Use latest reedsolo package which can be installed with Python3.10 and Cython Closes espressif#711 * feat(ci): Publish development releases with custom pipeline * fix(ci): The development release job should not run by default Gitlab rules:if adds the job if any of the rules are true. * fix(ci): Merge two "ci" directories and build_tools into one * fix(secure download mode): Fix SDM detection on S2/S3 * fix(secure download mode): Reconnect if ROM refuses to respond Closes espressif#813 * fix(flasher_stub): Correct boundaries for SPIWrite4B and SPIRead4B SPIWrite4B and SPIRead4B functions are required for flash sizes bigger than 16MB. This fix corrects the boundaries so SPIWrite and SPIRead would be used for the whole 16MB area. The octal flash support for 32 MB chips (espressif#795) will be added in a follow-up commit. Closes espressif#745 Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com>
* Tasmota changes * stubs updated * S3 16MB fix (#4) * fix(setup): Use latest reedsolo package which can be installed with Python3.10 and Cython Closes espressif#711 * feat(ci): Publish development releases with custom pipeline * fix(ci): The development release job should not run by default Gitlab rules:if adds the job if any of the rules are true. * fix(ci): Merge two "ci" directories and build_tools into one * fix(secure download mode): Fix SDM detection on S2/S3 * fix(secure download mode): Reconnect if ROM refuses to respond Closes espressif#813 * fix(flasher_stub): Correct boundaries for SPIWrite4B and SPIRead4B SPIWrite4B and SPIRead4B functions are required for flash sizes bigger than 16MB. This fix corrects the boundaries so SPIWrite and SPIRead would be used for the whole 16MB area. The octal flash support for 32 MB chips (espressif#795) will be added in a follow-up commit. Closes espressif#745 Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com> * Update stub_flasher_32s3beta2.json * Update build_esptool.yml * Update build_esptool.yml * stubs updated Co-authored-by: Github BUILD <github-actions@github.com> Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com>
* S3 16MB fix (#4) * fix(setup): Use latest reedsolo package which can be installed with Python3.10 and Cython Closes espressif#711 * feat(ci): Publish development releases with custom pipeline * fix(ci): The development release job should not run by default Gitlab rules:if adds the job if any of the rules are true. * fix(ci): Merge two "ci" directories and build_tools into one * fix(secure download mode): Fix SDM detection on S2/S3 * fix(secure download mode): Reconnect if ROM refuses to respond Closes espressif#813 * fix(flasher_stub): Correct boundaries for SPIWrite4B and SPIRead4B SPIWrite4B and SPIRead4B functions are required for flash sizes bigger than 16MB. This fix corrects the boundaries so SPIWrite and SPIRead would be used for the whole 16MB area. The octal flash support for 32 MB chips (espressif#795) will be added in a follow-up commit. Closes espressif#745 Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com> * Update stub_flasher_32s3beta2.json * Update build_esptool.yml * Update build_esptool.yml * stubs updated Co-authored-by: Github BUILD <github-actions@github.com> Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com> * stubs updated * stubs updated Co-authored-by: Github BUILD <github-actions@github.com> Co-authored-by: Roland Dobai <roland@espressif.com> Co-authored-by: radim.karnis <radim.karnis@espressif.com>
Sorry for the slow response. I have not returned to this part of my codebase yet! |
So I just hit this again. Had not hit it in awhile. I think because I usually use UART & now I'm using USB_SERIAL_JTAG again. ESP-IDF: v5.1.2
|
has this been fixed in the ROM? If I purchase new chips? Pretty annoying bug! |
Operating System
macOS 12.5.1
Esptool Version
v4.4.3-215-g9f3f82f54b
Python Version
3.9.9
Full Esptool Command Line that Was Run
/firmware/.espressif/python_env/idf4.4_py3.9_env/bin/python /firmware/esp-idf/components/esptool_py/esptool/esptool.py --port /dev/cu.usbmodem2101 --chip esp32s3 --no-stub get_security_info
Esptool Output
What is the Expected Behaviour?
It should print this:
Corresponds to this:
More Information
It happens literally about 50% of the time, maybe perfectly alternating between working at not working.
Note: Im using USB_SERIAL_JTAG!
Other Steps to Reproduce
No response
The text was updated successfully, but these errors were encountered: