espefuse.py show struct.error: unpack requires a buffer of 20 bytes (IDFGH-12938) (ESPTOOL-867)

[AxelLin]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.2.1-537-g9cf323d4c6

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

What is the expected behavior?

Below commands should work:

esptool.py --chip esp32s3 -p /dev/ttyUSB0 --before default_reset --after hard_reset erase_flash --force
espefuse.py --before default_reset --chip esp32s3 --port /dev/ttyUSB0 summary

What is the actual behavior?

$ esptool.py --chip esp32s3 -p /dev/ttyUSB0 --before default_reset --after hard_reset erase_flash --force
espefuse.py --before default_reset --chip esp32s3 --port /dev/ttyUSB0 summary
esptool.py v4.7.0
Serial port /dev/ttyUSB0
Connecting...
Chip is ESP32-S3 (QFN56) (revision v0.1)
Features: WiFi, BLE, Embedded PSRAM 8MB (AP_3v3)
Crystal is 40MHz
MAC: f4:12:fa:fa:49:40
Stub is already running. No upload is necessary.
Erasing flash (this may take a while)...
Chip erase completed successfully in 12.1s
Hard resetting via RTS pin...
espefuse.py v4.7.0
Connecting...
Traceback (most recent call last):
  File "/home/axel/.espressif/python_env/idf5.2_py3.10_env/bin/espefuse.py", line 37, in <module>
    espefuse._main()
  File "/home/axel/.espressif/python_env/idf5.2_py3.10_env/lib/python3.10/site-packages/espefuse/__init__.py", line 295, in _main
    main()
  File "/home/axel/.espressif/python_env/idf5.2_py3.10_env/lib/python3.10/site-packages/espefuse/__init__.py", line 241, in main
    efuses, efuse_operations = get_efuses(
  File "/home/axel/.espressif/python_env/idf5.2_py3.10_env/lib/python3.10/site-packages/espefuse/__init__.py", line 97, in get_efuses
    efuse.EspEfuses(esp, skip_connect, debug_mode, do_not_confirm),
  File "/home/axel/.espressif/python_env/idf5.2_py3.10_env/lib/python3.10/site-packages/espefuse/efuse/esp32s3/fields.py", line 76, in __init__
    flags = self._esp.get_security_info()["flags"]
  File "/home/axel/.espressif/python_env/idf5.2_py3.10_env/lib/python3.10/site-packages/esptool/loader.py", line 941, in get_security_info
    res = struct.unpack("<IBBBBBBBB" if esp32s2 else "<IBBBBBBBBII", res)
struct.error: unpack requires a buffer of 20 bytes

Steps to reproduce.

Below script can reproduce this issue:

#!/usr/bin/env bash

esptool.py --chip esp32s3 -p /dev/ttyUSB0 --before default_reset --after hard_reset erase_flash --force
espefuse.py --before default_reset --chip esp32s3 --port /dev/ttyUSB0 summary

Build or installation Logs.

No response

More Information.

Also note if I don't execute erase_flash, the espefuse.py command works fine.

[radimkarnis]

Hello @AxelLin,

I cannot reproduce this issue locally, but I expected that. There are hints of possible HW issues in your logs:

The first step (erasing flash) should reset the chip after the operation is done (--after hard_reset).
The second step (reading eFuse summary) should reset the chip again before the operation begins (--before default_reset).

In total, there should be two resets between the operations - meaning there is no chance that the stub flasher or any other code loaded to RAM would continue to run. Yet, we get a confirmation that the stub flasher is still running (Stub is already running. No upload is necessary.).

That means there is a chance the resets are not happening, and the stub flasher keeps running - that confuses esptool, because the responses from the ROM bootloader have a different length than the ones from the stub flasher.

What's weird is that esptool should account for this if the stub is detected. Let's try to explore this assumption.

Can you verify that the chip is resetting? How do you connect the chip (with a classic USB-to-UART bridge, or the USB-Serial/JTAG peripheral)? If it is the classic way, are the DTR and RTS lines connected properly?

If you use the --no-stub argument, does anything change?

Thanks!

[AxelLin]

Hi @radimkarnis

I use a classic USB-to-UART bridge, the RTS line is not connected to chip_en pin.
I think that's the reason "--after hard_reset" does not work.
Is it possible to make it work without RTS pin?

Adding --no-stub argument does not help, I got below error:
A fatal error occurred: ESP32-S3 ROM does not support function erase_flash.

[radimkarnis]

@AxelLin, it seems like you hit a very specific case, which is not covered in esptool (it is not expected the RTS line will be disconnected).

A quick workaround is to delete the --chip esp32s3 part from the second command (esptool will autodetect the chip), the command should then work. You can also delete the --before default_reset and --after hard_reset parts since these do nothing without the RTS being connected.

Please let me know if that helped! I will try to fix this edge case in the meantime.