efuse: Correct block sizes for ESP32-C2, ESP32-C3, and ESP32-S3

[kyrias]

It seems like I've figured out how the incorrect base addresses that were corrected in #961 arose.

The esptool's eFuse field definitions do not include the last byte of the block0/register5. The technical reference manual lists the first 22 bits as a named field, it just happens to be that that field is a reserved one, and the remaining 8 bits is an unnamed reserved portions so the esptool definitions doesn't list it. It seems like the BLOCK_SIZES definitions in espflash were derived from the sizes as calculated by those field definitions, which therefore were a byte short for -C2/-C3/-S3.

It seems like the base addresses were changed to try to adjust for this, but in exchange it accidentally shifted the data in block0 by one byte and block1 by two bytes, and I ran into it while testing out my eFuse write changes against block0. On the other hand, changing fixing the base addresses without changing the block sizes means that we get the opposite problem where block0 works but the other blocks are shifted!

This PR corrects the block sizes for the three affected chips.

---

The simplest way to verify that these values are correct is by looking at the eFuse register summary tables and subtracting the start address of one block from the start address of the following one, which gives you the size of the block.

• ESP8686 (ESP32-C2) Technical Reference Manual
• ESP32-S3 Technical Reference Manual
• ESP32-C3 Technical Reference Manual

[kyrias]

Also, I'm wondering, since there are HIL tests set up for the supported devices, would it be possible to write unique values to each of the blocks on all of them so we could then have HIL tests that make sure that all blocks are read correctly?

[SergioGasquez]

LGTM! Thanks for the fixes, maybe we should add a comment explaining how the addresses are calculated so its easier to know where the numbers come from in the future

[SergioGasquez]

Also, I'm wondering, since there are HIL tests set up for the supported devices, would it be possible to write unique values to each of the blocks on all of them so we could then have HIL tests that make sure that all blocks are read correctly?

Thats definitely something we should do! Maybe not in this PR, but we should try to test as much as possible, and we already had some efuse issues in the past that could have been saved with such tests.

[kyrias]

Actually, I somehow completely missed the comment saying that these target files were automatically generated. And well, that does confirm that this is how the issue arose.

It seems like the data that we want here cannot be derived from the espefuse eFuse definition YAML files. (also cf. #960) Instead what we'd need to do to be able to derive this only from data in the espefuse project is reading the block definitions in their memory definitions. The problem is that these definitions are variables defined in Python classes.

I think we can pretty easily use PyO3 to get this data though, so I'll give that a shot.