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

[esptool.py] Sporadic "This command (0x14) is not supported in Secure Download Mode" with USB_SER_JTAG (ESPTOOL-577) #813

Closed
chipweinberger opened this issue Dec 15, 2022 · 8 comments

Comments

@chipweinberger
Copy link

chipweinberger commented Dec 15, 2022

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

Exception has occurred: UnsupportedCommandError
This command (0x14) is not supported in Secure Download Mode
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 505, in command
    raise UnsupportedCommandError(self, op)
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 520, in check_command
    val, data = self.command(op, data, chk, timeout=timeout)
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 902, in get_chip_id
    res = self.check_command('get security info', self.ESP_GET_SECURITY_INFO, b'')
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 168, in inner
    return func(*args, **kwargs)
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 1343, in check_chip_id
    chip_id = self.get_chip_id()
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 719, in connect
    self.check_chip_id()
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 116, in get_default_connected_device
    _esp.connect(before, connect_attempts)
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 4782, in main
    esp = esp or get_default_connected_device(ser_list, port=args.port, connect_attempts=args.connect_attempts,
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 5475, in _main
    main()
  File "/firmware/esp-idf/components/esptool_py/esptool/esptool.py", line 5482, in <module>
    _main()

What is the Expected Behaviour?

It should print this:

charlesweinberger@Chips-Macbook-Pro-2 jamcorder_app % esptool.py --chip esp32s3 get_security_info
esptool.py v3.3.2
Found 2 serial ports
Serial port /dev/cu.usbmodem2101
Connecting...
Chip is ESP32-S3 in Secure Download Mode
WARNING: Stub loader is not supported in Secure Download Mode, setting --no-stub
Enabling default SPI flash mode...
Flags: 0x00000084 (0b10000100)
Flash_Crypt_Cnt: 0x1
Key_Purposes: (0, 2, 3, 7, 0, 0, 12)
Chip_ID: 9
Api_Version: 0
Hard resetting via RTS pin...

Corresponds to this:

Flags: 132
[Flag] secureBootEn: False
[Flag] secureBootAggressiveRevoke: False
[Flag] secureDownloadEnable: True
[Flag] secureBootKeyRevoke0: False
[Flag] secureBootKeyRevoke1: False
[Flag] secureBootKeyRevoke2: False
[Flag] softDisableJtag: False
[Flag] hardDisableJtag: True
[Flag] disableUsb: False
[Flag] disableDownloadDCache: False
[Flag] disableDownloadICache: False

KeyPurposes: [0, 2, 3, 7, 0, 0, 12]
[Key] User: True
[Key] Reserved: False
[Key] XtsAes256Key1: True
[Key] XtsAes256Key2: True
[Key] XtsAes128Key1: False
[Key] HmacDownAll: False
[Key] HmacDownJtag: False
[Key] HmacDownDigitalSignature: True
[Key] HmacU: pFalse
[Key] SecureBootDigest0: False
[Key] SecureBootDigest1: False
[Key] SecureBootDigest2: False

FlashCryptCnt: 1

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

@github-actions github-actions bot changed the title [esptool.py] "This command (0x14) is not supported in Secure Download Mode" happens sporadically [esptool.py] "This command (0x14) is not supported in Secure Download Mode" happens sporadically (ESPTOOL-577) Dec 15, 2022
@chipweinberger chipweinberger changed the title [esptool.py] "This command (0x14) is not supported in Secure Download Mode" happens sporadically (ESPTOOL-577) [esptool.py] Sporadic "This command (0x14) is not supported in Secure Download Mode" with USB_SER_JTAG (ESPTOOL-577) Dec 15, 2022
@chipweinberger
Copy link
Author

Does not repro in UART mode

@radimkarnis
Copy link
Collaborator

radimkarnis commented Dec 20, 2022

Hi @chipweinberger,
Thanks for reporting. I tried to reproduce this and can confirm that there is a little bug, I am already fixing it.

Can you please try using the latest esptool from master and confirm that it works when you specify the chip with -c esp32s3 and doesn't work when autodetection is used (omit the -c arg)? EDIT: This happens in UART mode

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

@radimkarnis
Copy link
Collaborator

radimkarnis commented Dec 22, 2022

Update:
I suspect a bug in the ESP32S3 ROM.

This happens only when:

  • secure download mode is active
  • USB-Serial/JTAG is used
  • -c esp32s3 is specified (doesn't happen with autodetection)
  • the chip isn't placed into the download mode beforehand

For some reason, the ROM responds with an INVALID_COMMAND response on every second try.

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 -c/--chip OR switching manually into download mode beforehand.

I am going to try to come up with a solution in esptool. Will leave this open until then.

@chipweinberger
Copy link
Author

Thanks for the update. That's interesting. I added -chip because I would hit other "command not supported" issues when I didn't specify. I'll make sure to file another issue if I hit more.

@radimkarnis
Copy link
Collaborator

I added -chip because I would hit other "command not supported" issues when I didn't specify

@chipweinberger this and the originally reported issue should be now fixed! Could you please try pulling the latest master and see if it works? Thanks!

Jason2866 added a commit to Jason2866/esptool that referenced this issue Dec 28, 2022
* 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>
Jason2866 added a commit to Jason2866/esptool that referenced this issue Dec 28, 2022
* 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>
Jason2866 added a commit to tasmota/esptool that referenced this issue Dec 28, 2022
* 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>
@chipweinberger
Copy link
Author

Sorry for the slow response. I have not returned to this part of my codebase yet!

@chipweinberger
Copy link
Author

chipweinberger commented Mar 10, 2024

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

/.espressif/python_env/idf5.1_py3.9_env/bin/python /esp-idf/components/esptool_py/esptool/esptool.py --port /dev/cu.usbmodem101 --chip esp32s3 --no-stub get_security_info


Traceback (most recent call last):
  File "/.espressif/python_env/idf5.1_py3.9_env/lib/python3.9/site-packages/esptool/loader.py", line 690, in connect
    self.check_chip_id()
  File "/.espressif/python_env/idf5.1_py3.9_env/lib/python3.9/site-packages/esptool/loader.py", line 1455, in check_chip_id
    chip_id = self.get_chip_id()
  File "/.espressif/python_env/idf5.1_py3.9_env/lib/python3.9/site-packages/esptool/loader.py", line 131, in inner
    return func(*args, **kwargs)
  File "/.espressif/python_env/idf5.1_py3.9_env/lib/python3.9/site-packages/esptool/loader.py", line 913, in get_chip_id
    res = self.check_command(
  File "/.espressif/python_env/idf5.1_py3.9_env/lib/python3.9/site-packages/esptool/loader.py", line 436, in check_command
    val, data = self.command(op, data, chk, timeout=timeout)
  File "/.espressif/python_env/idf5.1_py3.9_env/lib/python3.9/site-packages/esptool/loader.py", line 419, in command
    raise UnsupportedCommandError(self, op)
esptool.util.UnsupportedCommandError: This command (0x14) is not supported in Secure Download Mode

@chipweinberger
Copy link
Author

has this been fixed in the ROM? If I purchase new chips? Pretty annoying bug!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants