using efuse BLK3

[mzimmers]

Hi Angus - if it truly will be very soon, I can wait. Otherwise, I guess I'll have to use NVS and just hope the user never figures out a way to erase it.

I'm curious, though...why can't I just write to BLK3 with 0s where the information is already stored? I don't want to try it, lest I do any irreversible damage, but I'm wondering why I can't.

[WiFive]

Well you have to use the existing values because they are part of the check codes and presumably if you fail to write the check code bits correctly you will read corrupt data because the efuse controller will apply the error correction.

[RalimTEk]

This can't be done easily at the moment. Support is being added right now, so something should be available in ESP-IDF very soon.

I would also love to see support for this added to the idf or at the least espefuse.py

Is there any idea on if the timeline is weeks, months or a year ?

[ESP_Angus]

Is there any idea on if the timeline is weeks, months or a year ?

Support for 3/4 Coding Scheme is in review now, and should be merged to master branch next week.

It will be released as part of ESP-IDF V3.1.2, planned for November.

There is a new "espefuse.py burn_block_data" command which can be used to write arbitrary (non-key) data to parts of a block. This allows making use of the remaining words in BLK3 to store other data, even if BLK3_PART_RESERVE is set.

[mzimmers]

Hi Angus - this is great news. Is there a mailing list that I can subscribe to that will inform me when this is available?

[ESP_Angus]

Thanks everyone for your patience. 3/4 Coding Scheme support is now available in the ESP-IDF master branch, as of this commit.

Hi Angus - this is great news. Is there a mailing list that I can subscribe to that will inform me when this is available?

No mailing list for this kind of thing, unfortunately. The most automated way to track bugs or requests like this is to open an issue on github and we can link the git commit to the github issue number, so that it updates automatically when the change arrives (and will send an email to any subscribed users). In this case there wasn't any GitHub issue about 3/4 Coding Scheme support.

[mzimmers]

Hi Angus -

Can you point me to a reference for reading/writing efuse BLK3 programmatically? I'm still evaluating the merits of using this vs. an NVS partition, but I'd like to pursue this a bit further.

Thanks...

[ESP_Angus]

Hi mzimmers,

You can use the "espefuse.py burn_block_data" command for this:
https://github.com/espressif/esptool/wi ... n-key-data

Once the data is written to BLK3 efuse, it will be available in the registers EFUSE_BLK3_RDATA0_REG ... EFUSE_BLK3_RDATA7_REG (or, for 3/4 Coding Scheme, the range is EFUSE_BLK3_RDATA0_REG .. EFUSE_BLK3_RDATA5_REG). "espefuse.py dump" is an easy way to view the contents of these words from a host computer.

If you have a device with BLK3_PART_RESERVE set then you'll need to write to a part of BLK3 which is not already occupied by ADC calibration data.


Angus

[mzimmers]

I don’t suppose there’s an option for doing this without a file? Ideally I would do it with a C program and a data structure. Maybe I’m asking for too much.

EDIT: disregard; the powers that be have decided they'd rather use NVS than the fuses for storing this data. I'll be back with some questions about doing that soon. Thanks...

[ESP_Angus]

I don’t suppose there’s an option for doing this without a file? Ideally I would do it with a C program and a data structure. Maybe I’m asking for too much.

You're not asking for too much. A C-based function in ESP-IDF to calculate the 3/4 coding scheme error correction bytes is planned, and it should be easy to adapt into a host-based program.

Until that's available, the best way to do this would be to adapt the Python code in espefuse.py. However if you're going with NVS then I guess it's less important.