espefuse.py: No stub support for write commands? (ESPTOOL-674)

[someburner]

Due to some engineering / time constraints, our programming fixture doesn't have the ability to hard reset the ESP32 in a single programming "session" (e.g. toggling rts/cts etc has no effect). Once the chip has entered stub mode, you can read efuses, but cannot write them.

For example, using an ESP Prog jumper programmer you can emulate this behavior:

export ESP_PORT=/dev/ttyUSB0

# put chip into stub mode
./esptool.py --chip esp32 -p $ESP_PORT --after no_reset_stub flash_id

# keep in stub mode - reads OK
espefuse.py --chip esp32 --port $ESP_PORT --before no_reset summary

# keep in stub mode - writes fail
espefuse.py --port $ESP_PORT --before no_reset --do-not-confirm burn_efuse FLASH_CRYPT_CNT 0x7F

The issue appears to be due to stub loader expecting different status byte lengths:

class ESP32StubLoader(ESP32ROM):
    """Access class for ESP32 stub loader, runs on top of ROM."""

    FLASH_WRITE_SIZE = 0x4000  # matches MAX_WRITE_BLOCK in stub_loader.c
    STATUS_BYTES_LENGTH = 2  # same as ESP8266, different to ESP32 ROM
    IS_STUB = True

but current espefuse.py appears to have no way to load those overrides. I thought perhaps stub loader might not be suited for efuses but I saw this commit: 343bca1

I'm using a hacked up version of esptool and passing an esp object around, and found these changes actually work well:
esptool.patch.txt

So not sure if this is a bug/oversight, a needed feature, or if programming efuses with the stub is not recommended.

[KonstantinKondrashov]

Hi @someburner!
The way that you have tried should work. I will check out this feature to make it workable.
Thanks for the good description.

[someburner]

Also, you can test this behavior without burning any fuses, it errors out before anything is actually written.

[KonstantinKondrashov]

Hi @someburner!
I do not see any issue with the following setup (I think it is the same case as yours, correct me if your case is different):

• ESP32 is connected to the USB-SERIAL with only RX, TX, and GND. This COM port is used for the connection (flash/burn).
• ESP32's EN and BOOT are not connected to the USB-SERIAL. (you said that your case does not have the ability to hard reset, e.g. toggling rts/cts etc has no effect.). I manually connect to GND to go to download mode. I do it in the following sequence:
  • EN ->GND, (keep it)
  • BOOT -> GND, (keep it)
  • Release EN,
  • Release BOOT.
  • Chip goes into the Download mode.
• When the chip is in the Download mode using any --after or --before does not make sense because EN and BOOT are not connected to the chip.
• Then you can use any commands from esptool and espefuse.

> esptool.py chip_id
esptool.py v4.6-dev
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v0.0)
Features: WiFi, BT, Dual Core, Coding Scheme None
Crystal is 40MHz
MAC: 00:00:00:00:00:00
Uploading stub...
Running stub...
Stub running...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: 00:00:00:00:00:00
Hard resetting via RTS pin...  <- It does not happen because RTS is not connected, so chip is still in stub

> esptool.py chip_id
esptool.py v4.6-dev
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v0.0)
Features: WiFi, BT, Dual Core, Coding Scheme None
Crystal is 40MHz
MAC: 00:00:00:00:00:00
Stub is already running. No upload is necessary.
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: 00:00:00:00:00:00
Hard resetting via RTS pin...  <- It does not happen because RTS is not connected, so chip is still in stub

> espefuse.py --port /dev/ttyUSB0  --do-not-confirm burn_bit BLOCK3 246
espefuse.py v4.6-dev
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
=== Run "burn_bit" command ===
bit_number:   [255]........................................................[0]
BLOCK3    : 0x0040000000000000000000000000000000000000000000000000000000000000
BLOCK3          (                ) [3 ] regs_to_write: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00400000
Check all blocks for burn...
idx, BLOCK_NAME,          Conclusion
[03] BLOCK3               is not empty
        (written ): 0xfe80000000000000000000000000000000000000000000000000000000000000
        (to write): 0x0040000000000000000000000000000000000000000000000000000000000000
        (coding scheme = NONE)
This is an irreversible operation!
BURN BLOCK3  - OK (all write block bits are set)
Reading updated efuses...
Successful

[KonstantinKondrashov]

@someburner
Please help to reach your case.

According to your fix. Will this fix work for you as well?

diff --git a/espefuse/__init__.py b/espefuse/__init__.py
index 681a9ba..6a4ff50 100755
--- a/espefuse/__init__.py
+++ b/espefuse/__init__.py
@@ -178,6 +178,14 @@ def main(custom_commandline=None):
         default="default_reset",
     )
 
+    init_parser.add_argument(
+        "--after",
+        "-a",
+        help="What to do after espefuse.py is finished",
+        choices=["hard_reset", "soft_reset", "no_reset", "no_reset_stub"],
+        default="no_reset",
+    )
+
     init_parser.add_argument(
         "--debug",
         "-d",
@@ -276,6 +284,18 @@ def main(custom_commandline=None):
             if not efuses.burn_all(check_batch_mode=True):
                 raise esptool.FatalError("BURN was not done")
     finally:
+        if args.after == "hard_reset":
+            esp.hard_reset()
+        elif args.after == "soft_reset":
+            print("Soft resetting...")
+            esp.soft_reset(False)
+        elif args.after == "no_reset_stub":
+            print("Staying in flasher stub.")
+        else:  # args.after == 'no_reset'
+            print("Staying in bootloader.")
+            if esp.IS_STUB:
+                esp.soft_reset(True)  # exit stub back to ROM loader
+
         if not common_args.virt and esp._port:
             esp._port.close()

What is the reason do not close the port? Do you want to burn some efuses? We have a batch mode for this https://docs.espressif.com/projects/esptool/en/latest/esp32/espefuse/index.html#perform-multiple-operations-in-a-single-espefuse-run

[someburner]

Did you try my steps with an ESP Prog adapter? I don't believe the issue is specifically tied to our manufacturing setup. In our case, however, I don't think we can release the EN -> Gnd or Boot -> Gnd. In the case of using ESP Prog it seems like the commands I listed for that should work- shouldn't they?

The part about not closing serial is just due to me passing in an existing esp object, but if I can get the write command to work while it's in stub mode then that wouldn't be necessary.

Thanks for trying it out though. I'll have to double check on my end.

[KonstantinKondrashov]

Yes, I tried your steps with the ESP-Prog adapter.

> esptool.py -b 115200  --chip esp32 -p /dev/ttyUSB1 --after no_reset_stub    flash_id
esptool.py v4.6-dev
Serial port /dev/ttyUSB1
Connecting....
Chip is ESP32-D0WD-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 94:b9:7e:59:7c:b4
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Staying in flasher stub.

Here you can see that the chip is in "Staying in flasher stub". To make sure that after this cmd the chip is really in the stub state you can run the same cmd but with --before no_reset :

> esptool.py -b 115200  --chip esp32 -p /dev/ttyUSB1 --after no_reset_stub  --before no_reset  flash_id
esptool.py v4.6-dev
Serial port /dev/ttyUSB1
WARNING: Pre-connection option "no_reset" was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
Connecting...
Chip is ESP32-D0WD-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 94:b9:7e:59:7c:b4
Stub is already running. No upload is necessary.
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Staying in flasher stub.

The msg says that the chip is in "Stub is already running. No upload is necessary".

> espefuse.py --chip esp32 --port /dev/ttyUSB1  --before no_reset summary
espefuse.py v4.6-dev
WARNING: Pre-connection option "no_reset" was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
Connecting...
=== Run "summary" command ===
....

Summary cmd works, and the chip is still in stub mode. You can make sure it running esptool.py -b 115200 --chip esp32 -p /dev/ttyUSB1 --after no_reset_stub --before no_reset flash_id again.

Then run burning efuses (I use burn_bit cmd, it does not matter which burn cmd is used, but I also tried your's cmd)

> espefuse.py --port /dev/ttyUSB1 --before no_reset --after no_reset_stub  --do-not-confirm burn_bit BLOCK3 246
espefuse.py v4.6-dev
WARNING: Pre-connection option "no_reset" was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
...
BURN BLOCK3  - OK (all write block bits are set)
Reading updated efuses...
Successful

In the case of using ESP Prog it seems like the commands I listed for that should work- shouldn't they?

Yes, they should work.

keep in stub mode - writes fail
espefuse.py --port $ESP_PORT --before no_reset --do-not-confirm burn_efuse FLASH_CRYPT_CNT 0x7F

BTW, you can provide the log with all these cmds including the error.

FYI, you did not mention which esptool version you use. I tested on the latest version.

The part about not closing serial is just due to me passing in an existing esp object,

I can add this feature.

[KonstantinKondrashov]

patch_espefuse_expernal_esp_instance.txt
Please take a look this patch. Is it good for your case?
I did not take the --noclose flag into this patch because it looks excessively becuase if an esp instanse was given from above layer then that layer should be responsible for closing and connection to a chip.

[someburner]

@KonstantinKondrashov yes that's great, thank you

I will try again soon. strange it wasn't working for me but thank you for confirming. I'll tag you in a comment if I get the error again.