efuse question

[ESP_Angus]

I'm not sure exactly which documentation you're referring to (if you find any of it confusing, please link to it and we'll try to improve it), but to help clarify:

- Encryption keys used by hardware accelerators (flash encryption & secure boot) are written in reverse order to hardware (first byte last, etc), in order to get matching AES behaviour on the host. This is the difference between "espefuse.py burn_key" (reverses order) and "espefuse.py burn_data_block" (doesn't reverse). This is a "quirk" of the ESP32 hardware encryption engines.

- Since esptool.py v2.6, "espefuse.py summary" prints bytes in the "normal" byte order (first byte of efuse registers first). Before this, it printed them in the "hardware key" order (ie backwards). The blocks are printed by "summary" as a sequence of 32 bytes not a sequence of 8 words.

The data you have in BLK3 from "espefuse.py dump" seems to match the data you have in the file and the command you ran. I think the source of confusion is this: burn_block_data --offset option is in bytes, not words.

So you have 8 bytes starting at offset 6, and ending at offset 14. This means the the bytes are spread across 3 register words (and each word is shown in little endian order by 'dump', making it harder to read off the bytes. You should see correct order in 'espefuse.py summary', starting from byte 6, or if you memcpy() the entire block of registers into a 32 byte char array, and then start from index 6).

[ESP_Angus]

I've updated the wiki here to explicitly mention "bytes" whenever possible: https://github.com/espressif/esptool/wi ... n-key-data

EDIT: I also realised this section was confusing in other ways, because the section of "burn_block_data" began by describing limitations in burn_key command. Have edited it a bit to try and make it more straightforward to read.

[fly135]

This is the print from the command executing. It says offset 4 and 12 bytes instead of 8.

Burning efuse BLK3 (Variable Block 3) with 12 bytes of data at offset 4 in the block. This is an irreversible operation.

This is the python code I use to call the espefuse.py...

port_cmd = '--port'
offset_cmd = '--offset'
dnc_cmd = '--do-not-confirm'
subprocess.call(['python', idf_path + esp_fuse,port_cmd,ser_port,dnc_cmd,'burn_block_data', offset_cmd, '6', 'BLK3', 'device_id.bin'])

The instructions seem perfectly clear, but it appears that I didn't interpret offset correctly. I gave it an 8 byte file at offset 6. I thought that the offset was in 32 bit words, since that's the only way it can be written. I indicated that in my earlier post. I was led to think it was 32 bit words because of the definitions for accessing (eg. EFUSE_BLK3_RDATA6_REG) seemed to indicate that the block was with 32 bit offsets.

But this makes only sense if offset is in bytes. I said offset 6 and it wrote offset 4 to make it word aligned. So it added two zero bytes in the beginning and two at the end upping the number of bytes written by four. So it seems I need an offset of 24 to start at bit 192.

[ESP_Angus]

But this makes only sense if offset is in bytes. I said offset 6 and it wrote offset 4 to make it word aligned. So it added two zero bytes in the beginning and two at the end upping the number of bytes written by four. So it seems I need an offset of 24 to start at bit 192.

That's right. espefuse is being "helpful" here and padding the data to word boundaries when it writes to hardware. And becauses efuse bits can be written 0->1, you can still store something in these "end" bytes later on provided the "None" encoding is set (which it is, in your case).

I'll add an additional informational message in espefuse.py burn_block_data when it does the padding, so the whole flow is clearer to understand.