espefuse.py burn_custom_mac incompatible with 3/4 Coding Scheme

[filzek]

./espefuse.py --port com3 burn_custom_mac AA:BB:CC:00:00:01
espefuse.py v2.7-dev
Connecting.....
CONFIRM BURN, AND BURN!

it ends normal without any warning, but there is a problem as it doenst burn correct macaddress and save in the flash.

$ espefuse.py --port com3 get_custom_mac
espefuse.py v2.7-dev
Connecting.....
Custom MAC Address is not set in the device.

./espefuse.py --port com3 burn_custom_mac AA:BB:CC:00:00:01
espefuse.py v2.7-dev
Connecting.....

A fatal error occurred: Custom MAC Address was previously burned (AA:BB:CC:00:00:00)!

IT is not AA:BB:CC:00:00:01 and also the esp-idf dev cant read the custom mac address from flash!!!

[projectgus]

HI @filzek ,

Thanks for reporting this. We'll look into this ASAP.

Can you please give us the output from espefuse.py summary for the device where this MAC was burned, as well?

[filzek]

Command run:

$ ./espefuse.py --port com3 burn_custom_mac 49:4f:54:00:00:01
espefuse.py v2.7-dev
Connecting.......

We confirmed BURN and BURN again, it finished without error, but when try to read custom mac or flash the firmware it cant read the custom

$ ./espefuse.py --port com3 get_custom_mac
espefuse.py v2.7-dev
Connecting.....
Custom MAC Address is not set in the device.

$ ./espefuse.py --port com3 summary
espefuse.py v2.7-dev
Connecting...
EFUSE_NAME Description = [Meaningful Value] [Readable/Writeable] (Hex Value)

Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 0 R/W (0x0)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 1 R/W (0x1)
ABS_DONE_0 secure boot enabled for bootloader = 0 R/W (0x0)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
JTAG_DISABLE Disable JTAG = 0 R/W (0x0)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0)
BLK1 Flash encryption key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK2 Secure boot key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK3 Variable Block 3
= ed 49 4f 54 00 00 00 00 00 00 00 00 05 f5 73 eb 00 00 00 00 00 00 00 00 R/W

Efuse fuses:
WR_DIS Efuse write disable mask = 0 R/W (0x0)
RD_DIS Efuse read disablemask = 0 R/W (0x0)
CODING_SCHEME Efuse variable block length scheme = 1 R/W (0x1)
KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
CLK8M_FREQ 8MHz clock freq override = 54 R/W (0x36)
SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0)
SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0)
SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0)
SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0)
DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0)

Identity fuses:
MAC Factory MAC Address
= 30:ae:a4:c9:d2:ac (CRC c3 OK) R/W
CHIP_VER_REV1 Silicon Revision 1 = 1 R/W (0x1)
CHIP_VERSION Reserved for future chip versions = 2 R/W (0x2)
CHIP_PACKAGE Chip package identifier = 1 R/W (0x1)

Calibration fuses:
BLK3_PART_RESERVE BLOCK3 partially served for ADC calibration data = 1 R/W (0x1)
ADC_VREF Voltage reference calibration = 1142 R/W (0x6)
ADC1_TP_LOW ADC1 150mV reading = 298 R/W (0x5)
ADC1_TP_HIGH ADC1 850mV reading = 3177 R/W (0x1ea)
ADC2_TP_LOW ADC2 150mV reading = 369 R/W (0x73)
ADC2_TP_HIGH ADC2 850mV reading = 3238 R/W (0x1d6)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
WARNING: Coding scheme has encoding bit error warnings (0x100)

We did try on more than 10 ESP32 Wrover-B and all of them same result, are now useless. Please advise!

[projectgus]

Hi @filzek ,

Thanks. You have WROVER-B modules with the factory 3/4 Coding Scheme set, and probably this is the bug in espefuse.py. (Some explanation of 3/4 Coding Scheme.)

Will let you know as soon as we have a solution. We will also look a way to still set a custom MAC on the modules which have been burned from espefuse v2.7.

[filzek]

Hi @filzek ,

Thanks. You have WROVER-B modules with the factory 3/4 Coding Scheme set, and probably this is the bug in espefuse.py. (Some explanation of 3/4 Coding Scheme.)

Will let you know as soon as we have a solution. We will also look a way to still set a custom MAC on the modules which have been burned from espefuse v2.7.

I Have read it, but those Wrover-B was order about 2 months ago direct from Espressif, we are finishing the mass production JIG and this is a huge problem now.

Awaiting for you guidance

[dobairoland]

Hi @filzek.

I'm sorry for the week of silence but I was working on the solution. The fix will be published soon.

I have good news regarding your already burned modules. If I'm not missing anything then a subsequent run with the fixed espefuse will fix them because the least significant byte of the MAC and the MAC version weren't written to the efuses. But you have to burn the given device with the same MAC as before, e.g. if you burned XX:XX:XX:XX:XX:01 before then you cannot burn XX:XX:XX:XX:XX:02 after because the CRC for the MAC address was already burned.

I can help you to determine the right MAC for a given device if you give me the content of EFUSE block 3 from the dump output. If you consider this a private information then you can give it to me privately, or through the company.

Thank you for reporting the issue and sorry for the inconvenience.

[filzek]

Hi @filzek.

I'm sorry for the week of silence but I was working on the solution. The fix will be published soon.

I have good news regarding your already burned modules. If I'm not missing anything then a subsequent run with the fixed espefuse will fix them because the least significant byte of the MAC and the MAC version weren't written to the efuses. But you have to burn the given device with the same MAC as before, e.g. if you burned XX:XX:XX:XX:XX:01 before then you cannot burn XX:XX:XX:XX:XX:02 after because the CRC for the MAC address was already burned.

I can help you to determine the right MAC for a given device if you give me the content of EFUSE block 3 from the dump output. If you consider this a private information then you can give it to me privately, or through the company.

Thank you for reporting the issue and sorry for the inconvenience.

yes, I can send you the dumps and macs, but I think you could explain in the correction code for the efuse burning to solve it, I think the final address of mac shall fit in the final crc8 math, right? so the fix shall burn the missing part of the mac but the al mac must match to the current crc8 burned, is that right?

can you send me your email address?

[dobairoland]

Yes, you are right.

Here is a simple script mac.zip which you can run to calculate the CRC.

Using your example we get:

$ python ./mac.py 49:4f:54:00:00:01
237 0xed

You can find as the first byte the CRC 0xED in the produced output:

BLK3 Variable Block 3
= ed 49 4f 54 00 00 00 00 00 00 00 00 05 f5 73 eb 00 00 00 00 00 00 00 00 R/W

That is why you cannot burn it to 49:4f:54:00:00:02 (or anything else) because the CRC of 49:4f:54:00:00:01 is already there only it was written without the least significant byte of 01.

The fix will write

49:4f:54:00:00:00 -> 49:4f:54:00:00:01, 
CRC 0xED -> 0xED, 
version 0 -> version 1.

and correct the MAC.

If you still want to send me anything then my address is removed.

[dobairoland]

Hi @filzek. The fix is now in the master branch. Can you please pull it and confirm that it works?

Please save all the logs and if anything goes wrong then report back to me immediately and don't try it on other devices. However, I've tested it and believe that it should work.

Note that on the previously (partially) burned devices you need to use the --force-write-always option.