eFuse Manager
Introduction
eFuse (Electronic Fuses) are microscopic one-time programmable fuses that can be "burned" (i.e., programmed) to store data into the ESP32-H4. eFuse bits are organized into different data fields, and these data fields could be used for system parameters (i.e., data parameters used by ESP-IDF of ESP32-H4) or user defined parameters.
The eFuse Manager component is a collection of tools and APIs that assist with defining, burning, accessing eFuses parameters. The notable tools and APIs include:
A table format used to define eFuse data fields in CSV file.
efuse_table_gen.pytool to generate C structure representation of eFuse data fields specified by the CSV file.Collection of C API to read/write eFuse data fields.
eFuse Manager vs idf.py
idf.py provides a subset of the functionality of the eFuse Manager via the idf.py efuse-<subcommand> commands. In this documentation, mostly idf.py based commands will be used, although you can still see some espefuse based commands for advanced or rare cases. To see all available commands, run idf.py --help and search for those prefixed with efuse-.
Hardware Description
The ESP32-H4 has a number of eFuses which can store system and user parameters. Each eFuse is a one-bit field which can be programmed to 1 after which it cannot be reverted back to 0. The eFuse bits are grouped into blocks of 256 bits, where each block is further divided into 8 32-bit registers. Some blocks are reserved for system parameters while the remaining blocks can be used for user parameters.
For more details, see ESP32-H4 Technical Reference Manual > eFuse Controller (eFuse) [PDF].
ESP32-H4 has 11 eFuse blocks each containing 256 bits (not all bits can be used for user parameters):
EFUSE_BLK0 is used entirely for system parameters
EFUSE_BLK1 is used entirely for system parameters
EFUSE_BLK2 is used entirely for system parameters
EFUSE_BLK3 (also named EFUSE_BLK_USER_DATA) can be used for user parameters
EFUSE_BLK4 to EFUSE_BLK8 (also named EFUSE_BLK_KEY0 to EFUSE_BLK_KEY4) can be used to store keys for Secure Boot or Flash Encryption. If both features are unused, these blocks can be used for user parameters.
EFUSE_BLK9 (also named EFUSE_BLK_KEY5) can be used for any purpose except for Flash Encryption or ECDSA (due to a HW errata);
EFUSE_BLK10 (also named EFUSE_BLK_SYS_DATA_PART2) is reserved for system parameters.
Defining eFuse Fields
eFuse fields are defined as a table of records in a CSV file according to a specific format. This record format provides the ability to form eFuse fields of any length and from any number of individual bits.
Moreover, the record format allows structured definition of eFuse fields consisting of sub-fields, meaning that a parent eFuse field may consist of multiple child eFuse fields occupying the same eFuse bits.
Record Format
In simple cases, each record occupies a single row in the table. Each record contains the following values (i.e., columns):
# field_name, efuse_block(EFUSE_BLK0..EFUSE_BLK10), bit_start(0..255), bit_count(1..256), comment
field_nameName of the eFuse field.
The prefix
ESP_EFUSE_is automatically added to the name, and this name will be used when referring to the field in C code.field_nameunique across all eFuse fields.If this value is left empty, then this record is combined with the previous record. This allows you define an eFuse field with arbitrary bit ordering (see
MAC_FACTORYfield in the common table).Using
.will define a child eFuse field. See Structured eFuse Fields for more details.
efuse_blockThe eFuse field's block number. E.g., EFUSE_BLK0 to EFUSE_BLK10.
This determines which block the eFuse field is placed.
bit_startBit offset (0 to 255) of the eFuse within the block.
bit_startis optional and can be omitted.In this case, it is set to
bit_start + bit_countfrom the previous record, given that the previous record is in the same eFuse block.If the previous record is in a different eFuse block, an error will be generated.
bit_countThe size of the eFuse field in bits (1 to N).
bit_countcannot be omitted.If set to
MAX_BLK_LENthe eFuse field's size will be the maximum allowable eFuse field size in the block.
commentComment describing the eFuse field.
The comment is copied verbatim into the C header file.
If an eFuse field requires non-sequential bit ordering, then the eFuse field will span multiple records (i.e., multiple rows). The first record's field_name should specify the eFuse field's name, and the following records should leave field_name blank to indicate that they belong to the same eFuse field.
The following example demonstrates the records to specify the non-sequential eFuse field MAC_FACTORY followed by a regular eFuse field MAC_FACTORY_CRC:
# Factory MAC address #
#######################
MAC_FACTORY, EFUSE_BLK0, 72, 8, Factory MAC addr [0]
, EFUSE_BLK0, 64, 8, Factory MAC addr [1]
, EFUSE_BLK0, 56, 8, Factory MAC addr [2]
, EFUSE_BLK0, 48, 8, Factory MAC addr [3]
, EFUSE_BLK0, 40, 8, Factory MAC addr [4]
, EFUSE_BLK0, 32, 8, Factory MAC addr [5]
MAC_FACTORY_CRC, EFUSE_BLK0, 80, 8, CRC8 for factory MAC address
This eFuse fields will be made available in C code as ESP_EFUSE_MAC_FACTORY and ESP_EFUSE_MAC_FACTORY_CRC.
Structured eFuse Fields
Typically, an eFuse field represents a particular parameter. However, in some cases where an eFuse field consists of multiple sub-fields, it may be useful to have isolated access to those sub-fields. For example, if an eFuse field contained a floating point parameter, it may be useful to be access the sign, exponent, and mantissa fields of the floating as separate eFuse fields.
Therefore, it is possible for records to define eFuse fields in a structured manner using the . operator in field_name. For example, XX.YY.ZZ defines a eFuse field ZZ that is a child of eFuse field YY which in turn is a child field of eFuse field XX.
The following records demonstrate the definition of eFuse fields in a structured manner:
WR_DIS, EFUSE_BLK0, 0, 32, Write protection
WR_DIS.RD_DIS, EFUSE_BLK0, 0, 1, Write protection for RD_DIS
WR_DIS.FIELD_1, EFUSE_BLK0, 1, 1, Write protection for FIELD_1
WR_DIS.FIELD_2, EFUSE_BLK0, 2, 4, Write protection for FIELD_2 (includes B1 and B2)
WR_DIS.FIELD_2.B1, EFUSE_BLK0, 2, 2, Write protection for FIELD_2.B1
WR_DIS.FIELD_2.B2, EFUSE_BLK0, 4, 2, Write protection for FIELD_2.B2
WR_DIS.FIELD_3, EFUSE_BLK0, 5, 1, Write protection for FIELD_3
WR_DIS.FIELD_3.ALIAS, EFUSE_BLK0, 5, 1, Write protection for FIELD_3 (just a alias for WR_DIS.FIELD_3)
WR_DIS.FIELD_4, EFUSE_BLK0, 7, 1, Write protection for FIELD_4
Some things to note regarding the example above:
The
WR_DISrecord defines the parent eFuse field. All the other records are child fields ofWR_DISdue to theirWR_DIS.prefix.The child fields must utilize the same bits as their parent field. Take note of
bit_startandbit_countof the child and parent fields:The bits of the child fields are always in the range of their parent field. For example,
WR_DIS.RD_DISandWR_DIS.RD_DISoccupy the first and second bit ofWR_DIS.Child fields cannot use overlapping bits (except for when aliasing).
It is possible to create aliases as a child field. For example,
WR_DIS.FIELD_3.ALIASis a child field and alias ofWR_DIS.FIELD_3as they both occupy the same bits.
All eFuse Fields are eventually converted to C structures via the efuse_table_gen.py tool. The C structure for each eFuse field will derive their identifier from the field_name of the eFuse field's record, where all . are replaced with _. For example, the C symbols for WR_DIS.RD_DIS and WR_DIS.FIELD_2.B1 will be ESP_EFUSE_WR_DIS_RD_DIS and ESP_EFUSE_WR_DIS_FIELD_2_B1 respectively.
The efuse_table_gen.py tool also checks that the fields do not overlap each other and must be within the range of a field. If there is a violation, then the following error is generated:
Field at USER_DATA, EFUSE_BLK3, 0, 256 intersected with SERIAL_NUMBER, EFUSE_BLK3, 0, 32
In this case, the error can be resolved by making SERIAL_NUMBER a child field of USER_DATA via USER_DATA.SERIAL_NUMBER.
Field at FIELD, EFUSE_BLK3, 0, 50 out of range FIELD.MAJOR_NUMBER, EFUSE_BLK3, 60, 32
In this case, the error can be resolved by changing bit_start for FIELD.MAJOR_NUMBER from 60 to 0 so that MAJOR_NUMBER overlaps with FIELD.
efuse_table_gen.py Tool
The efuse_table_gen.py tool is designed to generate C source files containing C structures (of type esp_efuse_desc_t) representing the eFuse fields defined in CSV files. Moreover, the tool also runs some checks on the provided CSV files before generation to ensure that:
the names of the eFuse fields are unique
the eFuse fields do not use overlapping bits
As mentioned previously, eFuse fields can be used to hold either system parameters or user parameters. Given that system parameter eFuse fields are inherently required by ESP-IDF and ESP32-H4, those eFuse fields are defined in a common CSV file (esp_efuse_table.csv) and distributed as part of ESP-IDF. For user parameter eFuse fields, users should define those fields in a custom CSV file (e.g., esp_efuse_custom_table.csv).
To generate C source files using the common CSV file, use the idf.py efuse-common-table or the following:
cd $IDF_PATH/components/efuse/
./efuse_table_gen.py --idf_target esp32h4 esp32h4/esp_efuse_table.csv
The following C source/header files will be generated by the tool in $IDF_PATH/components/efuse/esp32h4:
esp_efuse_table.cfile containing the C structures of the system parameter eFuse fieldsesp_efuse_table.hfile in theincludefolder. This header can be included by the application to use those C structures.
To generate C source files using a custom CSV file, use the command idf.py efuse-custom-table or the following:
cd $IDF_PATH/components/efuse/
./efuse_table_gen.py --idf_target esp32h4 esp32h4/esp_efuse_table.csv PROJECT_PATH/main/esp_efuse_custom_table.csv
The following C source/header files will be generated by the tool in PROJECT_PATH/main:
esp_efuse_custom_table.cfile containing the C structures of the user parameter eFuse fieldsesp_efuse_custom_table.hfile in theincludefolder. This header can be included by the application to use those C structures.
To use the generated fields, you need to include two files:
#include "esp_efuse.h"
#include "esp_efuse_table.h" // or "esp_efuse_custom_table.h"
Supported Coding Schemes
Various coding schemes are supported by eFuses which can protect eFuses against data corruption by detecting and/or correcting for errors.
ESP32-H4 does not support selection of coding schemes. The following coding schemes are automatically applied to various eFuse blocks:
None: Applied to EFUSE_BLK0RS: Applied to EFUSE_BLK1 - EFUSE_BLK10
None Coding Scheme
The None coding scheme is automatically applied to EFUSE_BLK0. This scheme does not involve any encoding, but simply maintains four backups of EFUSE_BLK0 in hardware, meaning each bit is stored four times. As a result, EFUSE_BLK0 can be written many times.
This scheme is automatically applied by the hardware and is not visible to software.
RS Coding Scheme
The RS coding scheme uses Reed-Solomon encoding and is automatically applied to EFUSE_BLK1 to EFUSE_BLK10. The coding scheme supports up to 6 bytes of automatic error correction.
Software encodes the 32-byte EFUSE_BLKx using RS(44, 32) to generate a 12-byte check-symbols, and then burn the EFUSE_BLKx and the check-symbols into eFuse at the same time.
The eFuse Controller automatically decodes the RS encoding and applies error correction when reading back the eFuse block. Because the RS check-symbols are generated across the entire 256-bit eFuse block, each block can only be written to one time. As a result of the check-symbols, Batch Writing Mode must be used.
Batch Writing Mode
When writing to eFuse fields at run time, it may be necessary to use the Batch Writing Mode depending on the coding scheme used for eFuse block. Batch writing mode can be used as follows:
Enable batch writing mode by calling
esp_efuse_batch_write_begin()Write to the eFuse fields as usual using various
esp_efuse_write_...functions.Once all writes are complete, call
esp_efuse_batch_write_commit()which burns prepared data to the eFuse blocks.
Warning
If there is already pre-written data in the eFuse block using the Reed-Solomon encoding scheme, then it is not possible to write anything extra (even if the required bits are empty) without breaking the previous data's checksums/check-symbols.
The checksums/check-symbols will be overwritten with new checksums/check-symbols and be completely destroyed (however, the payload eFuses are not damaged).
If you happen to find pre-written data in CUSTOM_MAC, SPI_PAD_CONFIG_HD, SPI_PAD_CONFIG_CS, etc., please contact Espressif to obtain the required pre-burnt eFuses.
FOR TESTING ONLY (NOT RECOMMENDED): You can ignore or suppress errors that violate encoding scheme data in order to burn the necessary bits in the eFuse block.
eFuse API
Access to the fields is via a pointer to the description structure. API functions have some basic operation:
esp_efuse_read_field_blob()- returns an array of read eFuse bits.esp_efuse_read_field_cnt()- returns the number of bits programmed as "1".esp_efuse_write_field_blob()- writes an array.esp_efuse_write_field_cnt()- writes a required count of bits as "1".esp_efuse_get_field_size()- returns the number of bits by the field name.esp_efuse_read_reg()- returns value of eFuse register.esp_efuse_write_reg()- writes value to eFuse register.esp_efuse_get_coding_scheme()- returns eFuse coding scheme for blocks.esp_efuse_read_block()- reads a key from an eFuse block starting at the offset with required size.esp_efuse_write_block()- writes a key to an eFuse block starting at the offset with required size.esp_efuse_batch_write_begin()- set the batch mode of writing fields.esp_efuse_batch_write_commit()- writes all prepared data for batch writing mode and reset the batch writing mode.esp_efuse_batch_write_cancel()- reset the batch writing mode and prepared data.esp_efuse_get_key_dis_read()- Returns a read protection for the key block.esp_efuse_set_key_dis_read()- Sets a read protection for the key block.esp_efuse_get_key_dis_write()- Returns a write protection for the key block.esp_efuse_set_key_dis_write()- Sets a write protection for the key block.esp_efuse_get_key_purpose()- Returns the current purpose set for an eFuse key block.esp_efuse_write_key()- Programs a block of key data to an eFuse block.esp_efuse_write_keys()- Programs keys to unused eFuse blocks.esp_efuse_find_purpose()- Finds a key block with the particular purpose set.esp_efuse_get_keypurpose_dis_write()- Returns a write protection of the key purpose field for an eFuse key block (for esp32 always true).esp_efuse_key_block_unused()- Returns true if the key block is unused, false otherwise.esp_efuse_destroy_block()- Destroys the data in this eFuse block. There are two things to do: (1) if write protection is not set, then the remaining unset bits are burned, (2) set read protection for this block if it is not locked.esp_efuse_token_dump()- Generates a compact, single-line eFuse token (EFSR,EFSW, orEFSRW) that can be copied from device logs and decoded on the host withespefuse --token ...(useful when direct eFuse access is not available).esp_efuse_token_burn()- Applies anEFSWtoken on the device by burning the staged eFuse writes encoded in the token (other token types are rejected).
For frequently used fields, special functions are made, like this esp_efuse_get_pkg_ver().
eFuse API for Keys
EFUSE_BLK_KEY0 - EFUSE_BLK_KEY5 are intended to keep up to 6 keys with a length of 256-bits. Each key has an ESP_EFUSE_KEY_PURPOSE_x field which defines the purpose of these keys. The purpose field is described in esp_efuse_purpose_t.
The purposes like ESP_EFUSE_KEY_PURPOSE_XTS_AES_... are used for flash encryption.
The purposes like ESP_EFUSE_KEY_PURPOSE_SECURE_BOOT_DIGEST... are used for secure boot.
There are some eFuse APIs useful to work with states of keys:
esp_efuse_get_purpose_field()- Returns a pointer to a key purpose for an eFuse key block.esp_efuse_get_key()- Returns a pointer to a key block.esp_efuse_set_key_purpose()- Sets a key purpose for an eFuse key block.esp_efuse_set_keypurpose_dis_write()- Sets a write protection of the key purpose field for an eFuse key block.esp_efuse_find_unused_key_block()- Search for an unused key block and return the first one found.esp_efuse_count_unused_key_blocks()- Returns the number of unused eFuse key blocks in the range EFUSE_BLK_KEY0 to EFUSE_BLK_KEY_MAX
esp_efuse_get_digest_revoke()- Returns the status of the Secure Boot public key digest revocation bit.esp_efuse_set_digest_revoke()- Sets the Secure Boot public key digest revocation bit.esp_efuse_get_write_protect_of_digest_revoke()- Returns a write protection of the Secure Boot public key digest revocation bit.esp_efuse_set_write_protect_of_digest_revoke()- Sets a write protection of the Secure Boot public key digest revocation bit.
How to Add a New Field
Find free bits for field. Refer to the
esp_efuse_table.csvfile, runningidf.py show-efuse-table, or running the following command:
$ ./efuse_table_gen.py --idf_target esp32h4 esp32h4/esp_efuse_table.csv --info
Parsing efuse CSV input file esp32h4/esp_efuse_table.csv ...
Verifying efuse table...
Max number of bits in BLK 256
Sorted efuse table:
# field_name efuse_block bit_start bit_count
1 WR_DIS EFUSE_BLK0 0 32
2 WR_DIS.RD_DIS EFUSE_BLK0 0 1
3 WR_DIS.KM_DISABLE_DEPLOY_MODE EFUSE_BLK0 1 1
4 WR_DIS.KM_RND_SWITCH_CYCLE EFUSE_BLK0 1 1
5 WR_DIS.KM_DEPLOY_ONLY_ONCE EFUSE_BLK0 1 1
6 WR_DIS.FORCE_USE_KEY_MANAGER_KEY EFUSE_BLK0 1 1
7 WR_DIS.FORCE_DISABLE_SW_INIT_KEY EFUSE_BLK0 1 1
8 WR_DIS.KM_XTS_KEY_LENGTH_256 EFUSE_BLK0 1 1
9 WR_DIS.LOCK_KM_KEY EFUSE_BLK0 1 1
10 WR_DIS.DIS_USB_JTAG EFUSE_BLK0 2 1
11 WR_DIS.DIS_FORCE_DOWNLOAD EFUSE_BLK0 2 1
12 WR_DIS.SPI_DOWNLOAD_MSPI_DIS EFUSE_BLK0 2 1
13 WR_DIS.DIS_TWAI EFUSE_BLK0 2 1
14 WR_DIS.JTAG_SEL_ENABLE EFUSE_BLK0 2 1
15 WR_DIS.DIS_PAD_JTAG EFUSE_BLK0 2 1
16 WR_DIS.DIS_DOWNLOAD_MANUAL_ENCRYPT EFUSE_BLK0 2 1
17 WR_DIS.PVT_GLITCH_EN EFUSE_BLK0 2 1
18 WR_DIS.PVT_GLITCH_MODE EFUSE_BLK0 2 1
19 WR_DIS.SPI_BOOT_CRYPT_CNT EFUSE_BLK0 4 1
20 WR_DIS.SECURE_BOOT_KEY_REVOKE0 EFUSE_BLK0 5 1
21 WR_DIS.SECURE_BOOT_KEY_REVOKE1 EFUSE_BLK0 6 1
22 WR_DIS.SECURE_BOOT_KEY_REVOKE2 EFUSE_BLK0 7 1
23 WR_DIS.KEY_PURPOSE_0 EFUSE_BLK0 8 1
24 WR_DIS.KEY_PURPOSE_1 EFUSE_BLK0 9 1
25 WR_DIS.KEY_PURPOSE_2 EFUSE_BLK0 10 1
26 WR_DIS.KEY_PURPOSE_3 EFUSE_BLK0 11 1
27 WR_DIS.KEY_PURPOSE_4 EFUSE_BLK0 12 1
28 WR_DIS.KEY_PURPOSE_5 EFUSE_BLK0 13 1
29 WR_DIS.SEC_DPA_LEVEL EFUSE_BLK0 14 1
30 WR_DIS.XTS_DPA_PSEUDO_LEVEL EFUSE_BLK0 14 1
31 WR_DIS.XTS_DPA_CLK_ENABLE EFUSE_BLK0 14 1
32 WR_DIS.ECC_FORCE_CONST_TIME EFUSE_BLK0 14 1
33 WR_DIS.SECURE_BOOT_SHA384_EN EFUSE_BLK0 14 1
34 WR_DIS.SECURE_BOOT_EN EFUSE_BLK0 15 1
35 WR_DIS.SECURE_BOOT_AGGRESSIVE_REVOKE EFUSE_BLK0 16 1
36 WR_DIS.FLASH_TPUW EFUSE_BLK0 18 1
37 WR_DIS.DIS_DOWNLOAD_MODE EFUSE_BLK0 18 1
38 WR_DIS.DIS_DIRECT_BOOT EFUSE_BLK0 18 1
39 WR_DIS.DIS_USB_SERIAL_JTAG_ROM_PRINT EFUSE_BLK0 18 1
40 WR_DIS.DIS_USB_SERIAL_JTAG_DOWNLOAD_MODE EFUSE_BLK0 18 1
41 WR_DIS.ENABLE_SECURITY_DOWNLOAD EFUSE_BLK0 18 1
42 WR_DIS.UART_PRINT_CONTROL EFUSE_BLK0 18 1
43 WR_DIS.FORCE_SEND_RESUME EFUSE_BLK0 18 1
44 WR_DIS.SECURE_VERSION EFUSE_BLK0 18 1
45 WR_DIS.HUK_GEN_STATE EFUSE_BLK0 19 1
46 WR_DIS.BLK1 EFUSE_BLK0 20 1
47 WR_DIS.MAC EFUSE_BLK0 20 1
48 WR_DIS.MAC_EXT EFUSE_BLK0 20 1
49 WR_DIS.PVT_LIMIT EFUSE_BLK0 20 1
50 WR_DIS.PVT_CELL_SELECT EFUSE_BLK0 20 1
51 WR_DIS.PVT_PUMP_LIMIT EFUSE_BLK0 20 1
52 WR_DIS.PUMP_DRV EFUSE_BLK0 20 1
53 WR_DIS.WDT_DELAY_SEL EFUSE_BLK0 20 1
54 WR_DIS.HYS_EN_PAD EFUSE_BLK0 20 1
55 WR_DIS.PVT_GLITCH_CHARGE_RESET EFUSE_BLK0 20 1
56 WR_DIS.VDD_SPI_LDO_ADJUST EFUSE_BLK0 20 1
57 WR_DIS.FLASH_LDO_POWER_SEL EFUSE_BLK0 20 1
58 WR_DIS.WAFER_VERSION_MINOR EFUSE_BLK0 20 1
59 WR_DIS.WAFER_VERSION_MAJOR EFUSE_BLK0 20 1
60 WR_DIS.DISABLE_WAFER_VERSION_MAJOR EFUSE_BLK0 20 1
61 WR_DIS.DISABLE_BLK_VERSION_MAJOR EFUSE_BLK0 20 1
62 WR_DIS.BLK_VERSION_MINOR EFUSE_BLK0 20 1
63 WR_DIS.BLK_VERSION_MAJOR EFUSE_BLK0 20 1
64 WR_DIS.FLASH_CAP EFUSE_BLK0 20 1
65 WR_DIS.FLASH_VENDOR EFUSE_BLK0 20 1
66 WR_DIS.PSRAM_CAP EFUSE_BLK0 20 1
67 WR_DIS.PSRAM_VENDOR EFUSE_BLK0 20 1
68 WR_DIS.TEMP EFUSE_BLK0 20 1
69 WR_DIS.PKG_VERSION EFUSE_BLK0 20 1
70 WR_DIS.PVT_DBIAS EFUSE_BLK0 20 1
71 WR_DIS.ADJUST_1V2 EFUSE_BLK0 20 1
72 WR_DIS.ADJUST_1V8 EFUSE_BLK0 20 1
73 WR_DIS.ACTIVE_DCDC_1V25 EFUSE_BLK0 20 1
74 WR_DIS.ACTIVE_DCDC_1V35 EFUSE_BLK0 20 1
75 WR_DIS.SLP_DCDC EFUSE_BLK0 20 1
76 WR_DIS.LSLP_HP_DRVB EFUSE_BLK0 20 1
77 WR_DIS.DSLP_LP_DBIAS EFUSE_BLK0 20 1
78 WR_DIS.TEMP_CALIB EFUSE_BLK0 20 1
79 WR_DIS.SYS_DATA_PART1 EFUSE_BLK0 21 1
80 WR_DIS.OPTIONAL_UNIQUE_ID EFUSE_BLK0 21 1
81 WR_DIS.OCODE EFUSE_BLK0 21 1
82 WR_DIS.DCDC_OCODE EFUSE_BLK0 21 1
83 WR_DIS.VDD_3V4_DOUT EFUSE_BLK0 21 1
84 WR_DIS.ADC1_AVE_INITCODE_ATTEN0 EFUSE_BLK0 21 1
85 WR_DIS.ADC1_AVE_INITCODE_ATTEN1 EFUSE_BLK0 21 1
86 WR_DIS.ADC1_AVE_INITCODE_ATTEN2 EFUSE_BLK0 21 1
87 WR_DIS.ADC1_AVE_INITCODE_ATTEN3 EFUSE_BLK0 21 1
88 WR_DIS.ADC1_HI_DOUT_ATTEN0 EFUSE_BLK0 21 1
89 WR_DIS.ADC1_HI_DOUT_ATTEN1 EFUSE_BLK0 21 1
90 WR_DIS.ADC1_HI_DOUT_ATTEN2 EFUSE_BLK0 21 1
91 WR_DIS.ADC1_HI_DOUT_ATTEN3 EFUSE_BLK0 21 1
92 WR_DIS.ADC1_CH0_ATTEN0_INITCODE_DIFF EFUSE_BLK0 21 1
93 WR_DIS.ADC1_CH1_ATTEN0_INITCODE_DIFF EFUSE_BLK0 21 1
94 WR_DIS.ADC1_CH2_ATTEN0_INITCODE_DIFF EFUSE_BLK0 21 1
95 WR_DIS.ADC1_CH3_ATTEN0_INITCODE_DIFF EFUSE_BLK0 21 1
96 WR_DIS.ADC1_CH4_ATTEN0_INITCODE_DIFF EFUSE_BLK0 21 1
97 WR_DIS.INITCODE_DIFF_1P8_3P3 EFUSE_BLK0 21 1
98 WR_DIS.HI_DOUT_DIFF_1P8_3P3 EFUSE_BLK0 21 1
99 WR_DIS.BLOCK_USR_DATA EFUSE_BLK0 22 1
100 WR_DIS.CUSTOM_MAC EFUSE_BLK0 22 1
101 WR_DIS.BLOCK_KEY0 EFUSE_BLK0 23 1
102 WR_DIS.BLOCK_KEY1 EFUSE_BLK0 24 1
103 WR_DIS.BLOCK_KEY2 EFUSE_BLK0 25 1
104 WR_DIS.BLOCK_KEY3 EFUSE_BLK0 26 1
105 WR_DIS.BLOCK_KEY4 EFUSE_BLK0 27 1
106 WR_DIS.BLOCK_KEY5 EFUSE_BLK0 28 1
107 WR_DIS.BLOCK_SYS_DATA2 EFUSE_BLK0 29 1
108 WR_DIS.USB_EXCHG_PINS EFUSE_BLK0 30 1
109 WR_DIS.USB_OTG_FS_EXCHG_PINS EFUSE_BLK0 30 1
110 WR_DIS.USB_PHY_SEL EFUSE_BLK0 30 1
111 WR_DIS.SOFT_DIS_JTAG EFUSE_BLK0 31 1
112 RD_DIS EFUSE_BLK0 32 7
113 RD_DIS.BLOCK_KEY0 EFUSE_BLK0 32 1
114 RD_DIS.BLOCK_KEY1 EFUSE_BLK0 33 1
115 RD_DIS.BLOCK_KEY2 EFUSE_BLK0 34 1
116 RD_DIS.BLOCK_KEY3 EFUSE_BLK0 35 1
117 RD_DIS.BLOCK_KEY4 EFUSE_BLK0 36 1
118 RD_DIS.BLOCK_KEY5 EFUSE_BLK0 37 1
119 RD_DIS.BLOCK_SYS_DATA2 EFUSE_BLK0 38 1
120 DIS_USB_JTAG EFUSE_BLK0 39 1
121 DIS_FORCE_DOWNLOAD EFUSE_BLK0 41 1
122 SPI_DOWNLOAD_MSPI_DIS EFUSE_BLK0 42 1
123 DIS_TWAI EFUSE_BLK0 43 1
124 JTAG_SEL_ENABLE EFUSE_BLK0 44 1
125 DIS_PAD_JTAG EFUSE_BLK0 45 1
126 DIS_DOWNLOAD_MANUAL_ENCRYPT EFUSE_BLK0 46 1
127 PVT_GLITCH_EN EFUSE_BLK0 50 1
128 PVT_GLITCH_MODE EFUSE_BLK0 52 2
129 DIS_CORE1 EFUSE_BLK0 54 1
130 SPI_BOOT_CRYPT_CNT EFUSE_BLK0 55 3
131 SECURE_BOOT_KEY_REVOKE0 EFUSE_BLK0 58 1
132 SECURE_BOOT_KEY_REVOKE1 EFUSE_BLK0 59 1
133 SECURE_BOOT_KEY_REVOKE2 EFUSE_BLK0 60 1
134 KEY_PURPOSE_0 EFUSE_BLK0 64 5
135 KEY_PURPOSE_1 EFUSE_BLK0 69 5
136 KEY_PURPOSE_2 EFUSE_BLK0 74 5
137 KEY_PURPOSE_3 EFUSE_BLK0 79 5
138 KEY_PURPOSE_4 EFUSE_BLK0 84 5
139 KEY_PURPOSE_5 EFUSE_BLK0 89 5
140 SEC_DPA_LEVEL EFUSE_BLK0 94 2
141 XTS_DPA_PSEUDO_LEVEL EFUSE_BLK0 96 2
142 XTS_DPA_CLK_ENABLE EFUSE_BLK0 98 1
143 ECC_FORCE_CONST_TIME EFUSE_BLK0 99 1
144 SECURE_BOOT_SHA384_EN EFUSE_BLK0 100 1
145 SECURE_BOOT_EN EFUSE_BLK0 101 1
146 SECURE_BOOT_AGGRESSIVE_REVOKE EFUSE_BLK0 102 1
147 KM_DISABLE_DEPLOY_MODE EFUSE_BLK0 103 5
148 KM_RND_SWITCH_CYCLE EFUSE_BLK0 108 2
149 KM_DEPLOY_ONLY_ONCE EFUSE_BLK0 110 5
150 FORCE_USE_KEY_MANAGER_KEY EFUSE_BLK0 115 5
151 FORCE_DISABLE_SW_INIT_KEY EFUSE_BLK0 120 1
152 KM_XTS_KEY_LENGTH_256 EFUSE_BLK0 121 1
153 LOCK_KM_KEY EFUSE_BLK0 122 1
154 FLASH_TPUW EFUSE_BLK0 123 3
155 DIS_DOWNLOAD_MODE EFUSE_BLK0 127 1
156 DIS_DIRECT_BOOT EFUSE_BLK0 128 1
157 DIS_USB_SERIAL_JTAG_ROM_PRINT EFUSE_BLK0 129 1
158 DIS_USB_SERIAL_JTAG_DOWNLOAD_MODE EFUSE_BLK0 130 1
159 ENABLE_SECURITY_DOWNLOAD EFUSE_BLK0 131 1
160 UART_PRINT_CONTROL EFUSE_BLK0 132 2
161 FORCE_SEND_RESUME EFUSE_BLK0 134 1
162 SECURE_VERSION EFUSE_BLK0 135 16
163 HUK_GEN_STATE EFUSE_BLK0 151 5
164 FLASH_LDO_EFUSE_SEL EFUSE_BLK0 156 1
165 USB_EXCHG_PINS EFUSE_BLK0 168 1
166 USB_OTG_FS_EXCHG_PINS EFUSE_BLK0 169 1
167 USB_PHY_SEL EFUSE_BLK0 170 1
168 SOFT_DIS_JTAG EFUSE_BLK0 171 3
169 IO_LDO_ADJUST EFUSE_BLK0 174 8
170 IO_LDO_1P8 EFUSE_BLK0 182 1
171 DCDC_CCM_EN EFUSE_BLK0 183 1
172 MAC EFUSE_BLK1 0 8
173 MAC EFUSE_BLK1 8 8
174 MAC EFUSE_BLK1 16 8
175 MAC EFUSE_BLK1 24 8
176 MAC EFUSE_BLK1 32 8
177 MAC EFUSE_BLK1 40 8
178 MAC_EXT EFUSE_BLK1 48 8
179 MAC_EXT EFUSE_BLK1 56 8
180 PVT_LIMIT EFUSE_BLK1 64 16
181 PVT_CELL_SELECT EFUSE_BLK1 80 7
182 PVT_PUMP_LIMIT EFUSE_BLK1 87 8
183 PUMP_DRV EFUSE_BLK1 96 4
184 WDT_DELAY_SEL EFUSE_BLK1 100 2
185 HYS_EN_PAD EFUSE_BLK1 102 1
186 PVT_GLITCH_CHARGE_RESET EFUSE_BLK1 103 1
187 VDD_SPI_LDO_ADJUST EFUSE_BLK1 105 8
188 FLASH_LDO_POWER_SEL EFUSE_BLK1 113 1
189 WAFER_VERSION_MINOR EFUSE_BLK1 114 4
190 WAFER_VERSION_MAJOR EFUSE_BLK1 118 2
191 DISABLE_WAFER_VERSION_MAJOR EFUSE_BLK1 120 1
192 DISABLE_BLK_VERSION_MAJOR EFUSE_BLK1 121 1
193 BLK_VERSION_MINOR EFUSE_BLK1 122 3
194 BLK_VERSION_MAJOR EFUSE_BLK1 125 2
195 FLASH_CAP EFUSE_BLK1 127 3
196 FLASH_VENDOR EFUSE_BLK1 130 3
197 PSRAM_CAP EFUSE_BLK1 133 3
198 PSRAM_VENDOR EFUSE_BLK1 136 2
199 TEMP EFUSE_BLK1 138 2
200 PKG_VERSION EFUSE_BLK1 140 3
201 PVT_DBIAS EFUSE_BLK1 143 5
202 ADJUST_1V2 EFUSE_BLK1 148 4
203 ADJUST_1V8 EFUSE_BLK1 152 4
204 ACTIVE_DCDC_1V25 EFUSE_BLK1 156 4
205 ACTIVE_DCDC_1V35 EFUSE_BLK1 160 4
206 SLP_DCDC EFUSE_BLK1 164 5
207 LSLP_HP_DRVB EFUSE_BLK1 169 5
208 DSLP_LP_DBIAS EFUSE_BLK1 174 2
209 TEMP_CALIB EFUSE_BLK1 176 10
210 SYS_DATA_PART2 EFUSE_BLK10 0 256
211 OPTIONAL_UNIQUE_ID EFUSE_BLK2 0 128
212 OCODE EFUSE_BLK2 128 8
213 DCDC_OCODE EFUSE_BLK2 136 8
214 VDD_3V4_DOUT EFUSE_BLK2 144 10
215 ADC1_AVE_INITCODE_ATTEN0 EFUSE_BLK2 154 9
216 ADC1_AVE_INITCODE_ATTEN1 EFUSE_BLK2 163 9
217 ADC1_AVE_INITCODE_ATTEN2 EFUSE_BLK2 172 9
218 ADC1_AVE_INITCODE_ATTEN3 EFUSE_BLK2 181 9
219 ADC1_HI_DOUT_ATTEN0 EFUSE_BLK2 190 9
220 ADC1_HI_DOUT_ATTEN1 EFUSE_BLK2 199 9
221 ADC1_HI_DOUT_ATTEN2 EFUSE_BLK2 208 9
222 ADC1_HI_DOUT_ATTEN3 EFUSE_BLK2 217 9
223 ADC1_CH0_ATTEN0_INITCODE_DIFF EFUSE_BLK2 226 3
224 ADC1_CH1_ATTEN0_INITCODE_DIFF EFUSE_BLK2 229 3
225 ADC1_CH2_ATTEN0_INITCODE_DIFF EFUSE_BLK2 232 3
226 ADC1_CH3_ATTEN0_INITCODE_DIFF EFUSE_BLK2 235 3
227 ADC1_CH4_ATTEN0_INITCODE_DIFF EFUSE_BLK2 238 3
228 INITCODE_DIFF_1P8_3P3 EFUSE_BLK2 241 5
229 HI_DOUT_DIFF_1P8_3P3 EFUSE_BLK2 246 5
230 USER_DATA EFUSE_BLK3 0 256
231 USER_DATA.MAC_CUSTOM EFUSE_BLK3 200 48
232 KEY0 EFUSE_BLK4 0 256
233 KEY1 EFUSE_BLK5 0 256
234 KEY2 EFUSE_BLK6 0 256
235 KEY3 EFUSE_BLK7 0 256
236 KEY4 EFUSE_BLK8 0 256
237 KEY5 EFUSE_BLK9 0 256
Used bits in efuse table:
EFUSE_BLK0
[0 31] [0 1] [1 1] ... [50 50] [52 60] [64 125] [127 156] [168 183]
EFUSE_BLK1
[0 94] [96 103] [105 185]
EFUSE_BLK10
[0 255]
EFUSE_BLK2
[0 250]
EFUSE_BLK3
[0 255] [200 247]
EFUSE_BLK4
[0 255]
EFUSE_BLK5
[0 255]
EFUSE_BLK6
[0 255]
EFUSE_BLK7
[0 255]
EFUSE_BLK8
[0 255]
EFUSE_BLK9
[0 255]
Note: Not printed ranges are free for using. (bits in EFUSE_BLK0 are reserved for Espressif)
The number of bits not included in square brackets are free (some bits are reserved by Espressif). All fields are checked for overlapping bits.
To add child fields to an existing field, Structured eFuse Fields can be used. The following example demonstrates adding of the fields SERIAL_NUMBER, MODEL_NUMBER and HARDWARE_REV to an existing USER_DATA field by using the . operator:
USER_DATA.SERIAL_NUMBER, EFUSE_BLK3, 0, 32,
USER_DATA.MODEL_NUMBER, EFUSE_BLK3, 32, 10,
USER_DATA.HARDWARE_REV, EFUSE_BLK3, 42, 10,
In general, to add new eFuse Fields:
Add a record for each eFuse field in CSV file.
Run the
show_efuse_tablecommand to check eFuse table.To generate source files run the
efuse_common_tableorefuse_custom_tablecommands.
You may get errors such as intersects with or out of range. Please see how to solve them in the Structured eFuse Fields article.
Bit Order
The eFuses bit order is little endian (see the example below), meaning that eFuse bits are read and written from LSB to MSB:
$ idf.py efuse-dump
USER_DATA (BLOCK3 ) [3 ] read_regs: 03020100 07060504 0B0A0908 0F0E0D0C 13121111 17161514 1B1A1918 1F1E1D1C
BLOCK4 (BLOCK4 ) [4 ] read_regs: 03020100 07060504 0B0A0908 0F0E0D0C 13121111 17161514 1B1A1918 1F1E1D1C
where is the register representation:
EFUSE_RD_USR_DATA0_REG = 0x03020100
EFUSE_RD_USR_DATA1_REG = 0x07060504
EFUSE_RD_USR_DATA2_REG = 0x0B0A0908
EFUSE_RD_USR_DATA3_REG = 0x0F0E0D0C
EFUSE_RD_USR_DATA4_REG = 0x13121111
EFUSE_RD_USR_DATA5_REG = 0x17161514
EFUSE_RD_USR_DATA6_REG = 0x1B1A1918
EFUSE_RD_USR_DATA7_REG = 0x1F1E1D1C
where is the byte representation:
byte[0] = 0x00, byte[1] = 0x01, ... byte[3] = 0x03, byte[4] = 0x04, ..., byte[31] = 0x1F
For example, CSV file describes the USER_DATA field, which occupies all 256 bits (a whole block).
USER_DATA, EFUSE_BLK3, 0, 256, User data
USER_DATA.FIELD1, EFUSE_BLK3, 16, 16, Field1
ID, EFUSE_BLK4, 8, 3, ID bit[0..2]
, EFUSE_BLK4, 16, 2, ID bit[3..4]
, EFUSE_BLK4, 32, 3, ID bit[5..7]
Thus, reading the eFuse USER_DATA block written as above gives the following results:
uint8_t buf[32] = { 0 };
esp_efuse_read_field_blob(ESP_EFUSE_USER_DATA, &buf, sizeof(buf) * 8);
// buf[0] = 0x00, buf[1] = 0x01, ... buf[31] = 0x1F
uint32_t field1 = 0;
size_t field1_size = ESP_EFUSE_USER_DATA[0]->bit_count; // can be used for this case because it only consists of one entry
esp_efuse_read_field_blob(ESP_EFUSE_USER_DATA, &field1, field1_size);
// field1 = 0x0302
uint32_t field1_1 = 0;
esp_efuse_read_field_blob(ESP_EFUSE_USER_DATA, &field1_1, 2); // reads only first 2 bits
// field1 = 0x0002
uint8_t id = 0;
size_t id_size = esp_efuse_get_field_size(ESP_EFUSE_ID); // returns 6
// size_t id_size = ESP_EFUSE_USER_DATA[0]->bit_count; // cannot be used because it consists of 3 entries. It returns 3 not 6
esp_efuse_read_field_blob(ESP_EFUSE_ID, &id, id_size);
// id = 0x91
// b'100 10 001
// [3] [2] [3]
uint8_t id_1 = 0;
esp_efuse_read_field_blob(ESP_EFUSE_ID, &id_1, 3);
// id = 0x01
// b'001
Get eFuses During Build
There is a way to get the state of eFuses at the build stage of the project. There are two CMake functions for this:
espefuse_get_json_summary()- It calls theespefuse summary --format jsoncommand and returns a JSON string (it is not stored in a file).espefuse_get_efuse()- It finds a given eFuse name in the JSON string and returns its property.
The JSON string has the following properties:
{
"MAC": {
"bit_len": 48,
"block": 0,
"category": "identity",
"description": "Factory MAC Address",
"efuse_type": "bytes:6",
"name": "MAC",
"pos": 0,
"readable": true,
"value": "94:b9:7e:5a:6e:58 (CRC 0xe2 OK)",
"word": 1,
"writeable": true
},
}
These functions can be used from a top-level project CMakeLists.txt (system/efuse/CMakeLists.txt):
# ...
project(hello_world)
espefuse_get_json_summary(efuse_json)
espefuse_get_efuse(ret_data ${efuse_json} "MAC" "value")
message("MAC:" ${ret_data})
The format of the value property is the same as shown in espefuse summary or idf.py efuse-summary.
MAC:94:b9:7e:5a:6e:58 (CRC 0xe2 OK)
There is an example test system/efuse/CMakeLists.txt which adds a custom target efuse-filter. This allows you to run the idf.py efuse-filter command to read the required eFuses (specified in the efuse_names list) at any time, not just during the project build.
Debug eFuse & Unit Tests
Virtual eFuses
The Kconfig option virtualizes eFuse values inside the eFuse Manager, so writes are emulated and no eFuse values are permanently changed. This can be useful for debugging and unit testing.
During startup, the eFuses are copied to RAM. All eFuse operations (read and write) are performed with RAM instead of the real eFuse registers.
In addition to the option, there is the option that adds a feature to keep eFuses in flash memory. To use this mode, the partition_table should have include an efuse partition in partition.csv:
efuse_em, data, efuse, , 0x2000,
During startup, the eFuses are copied from flash, or in case where flash is empty, copied from real eFuse to RAM and then write flash. This option allows keeping eFuses after reboots, making it possible to test Secure Boot and Flash Encryption features.
Flash Encryption Testing
Flash encryption is a hardware feature that requires the physical burning of eFuses key and FLASH_CRYPT_CNT. If flash encryption is not actually enabled, then enabling the option just provides testing possibilities and does not encrypt anything in the flash, even though the logs indicates that encryption happens.
The bootloader_flash_write() is adapted for this purpose. But if flash encryption is already enabled on the chip when the application is run, or if the bootloader is created with the option, then the flash encryption/decryption operations will work properly. This means that data are encrypted as it is written into an encrypted flash partition and decrypted when they are read from an encrypted partition.
espefuse
esptool includes a useful tool for reading/writing ESP32-H4 eFuse bits - espefuse.
Part of the functionality of this tool is also provided directly by idf.py commands. For example, the idf.py efuse-summary command is equivalent to espefuse summary.
idf.py -p PORT efuse-summary
Executing action: efuse-summary
(...)
=== Run "summary" command ===
EFUSE_NAME (Block) Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Config fuses:
WR_DIS (BLOCK0) Disable programming of individual eFuses = 0 R/W (0x00000000)
RD_DIS (BLOCK0) Disable reading from BlOCK4-10 = 0 R/W (0b0000000)
DIS_TWAI (BLOCK0) Represents whether TWAI function is disabled or en = False R/W (0b0)
abled. 1: disabled 0: enabled
PVT_GLITCH_EN (BLOCK0) Represents whether to enable PVT power glitch moni = False R/W (0b0)
tor function.1:Enable. 0:Disable
PVT_GLITCH_MODE (BLOCK0) Use to configure glitch mode = 0 R/W (0b00)
DIS_CORE1 (BLOCK0) Represents whether the CPU-Core1 is disabled. 1: = False R/W (0b0)
Disabled. 0: Not disable
ECC_FORCE_CONST_TIME (BLOCK0) Represents whether to force ecc to use const-time = False R/W (0b0)
calculation mode. 1: Enable. 0: Disable
KM_DISABLE_DEPLOY_MODE (BLOCK0) Represents whether the new key deployment of key m = 0 R/W (0b00000)
anager is disabled. Bit0: Represents whether the n
ew ECDSA key deployment is disabled0: Enabled1: Di
sabledBit1: Represents whether the new XTS-AES (fl
ash and PSRAM) key deployment is disabled0: Enable
d1: DisabledBit2: Represents whether the new HMAC
key deployment is disabled0: Enabled1: DisabledBit
3: Represents whether the new DS key deployment is
disabled0: Enabled1: Disabled
KM_RND_SWITCH_CYCLE (BLOCK0) Represents the cycle at which the Key Manager swit = 0 R/W (0b00)
ches random numbers.0: Controlled by the \hyperref
[fielddesc:KEYMNGRNDSWITCHCYCLE]{KEYMNG\_RND\_SWIT
CH\_CYCLE} register. For more information; please
refer to Chapter \ref{mod:keymng} \textit{\nameref
{mod:keymng}}1: 8 Key Manager clock cycles2: 16 Ke
y Manager clock cycles3: 32 Key Manager clock cycl
es
KM_DEPLOY_ONLY_ONCE (BLOCK0) Represents whether the corresponding key can be de = 0 R/W (0b00000)
ployed only once.Bit0: Represents whether the ECDS
A key can be deployed only once0: The key can be d
eployed multiple times1: The key can be deployed o
nly onceBit1: Represents whether the XTS-AES (flas
h and PSRAM) key can be deployed only once0: The k
ey can be deployed multiple times1: The key can be
deployed only onceBit2: Represents whether the HM
AC key can be deployed only once0: The key can be
deployed multiple times1: The key can be deployed
only onceBit3: Represents whether the DS key can b
e deployed only once0: The key can be deployed
multiple times1: The key can be deployed only once
DIS_DIRECT_BOOT (BLOCK0) Represents whether direct boot mode is disabled or = False R/W (0b0)
enabled. 1: disabled 0: enabled
UART_PRINT_CONTROL (BLOCK0) Represents the type of UART printing. 00: force en = 0 R/W (0b00)
able printing 01: enable printing when GPIO8 is re
set at low level 10: enable printing when GPIO8 is
reset at high level 11: force disable printing
HUK_GEN_STATE (BLOCK0) Represents whether the HUK generate mode is valid. = 0 R/W (0b00000)
Odd count of bits with a value of 1: InvalidEven c
ount of bits with a value of 1: Valid
DCDC_CCM_EN (BLOCK0) Represents whether change DCDC to CCM mode = False R/W (0b0)
PVT_LIMIT (BLOCK1) Power glitch monitor threthold = 0 R/W (0x0000)
PVT_CELL_SELECT (BLOCK1) Power glitch monitor PVT cell select = 0 R/W (0b0000000)
PVT_PUMP_LIMIT (BLOCK1) Use to configure voltage monitor limit for charge = 0 R/W (0x00)
pump
PUMP_DRV (BLOCK1) Use to configure charge pump voltage gain = 0 R/W (0x0)
HYS_EN_PAD (BLOCK1) Represents whether the hysteresis function of = False R/W (0b0)
corresponding PAD is enabled. 1: enabled 0:disabled
PVT_GLITCH_CHARGE_RESET (BLOCK1) Represents whether to trigger reset or charge pump = False R/W (0b0)
when PVT power glitch happened.1:Trigger charge p
ump. 0:Trigger reset
PSRAM_CAP (BLOCK1) Psram capacity = 0 R/W (0b000)
PSRAM_VENDOR (BLOCK1) Psram vendor = 0 R/W (0b00)
TEMP (BLOCK1) Temp (die embedded inside) = 0 R/W (0b00)
ADJUST_1V2 (BLOCK1) SPI LDO adjust of 1.2v = 0 R/W (0x0)
ADJUST_1V8 (BLOCK1) SPI LDO adjust of 1.8v = 0 R/W (0x0)
ACTIVE_DCDC_1V25 (BLOCK1) DCDC-DCDC DBIAS of 1.25v = 0 R/W (0x0)
ACTIVE_DCDC_1V35 (BLOCK1) DCDC-DCDC DBIAS of 1.35v = 0 R/W (0x0)
SLP_DCDC (BLOCK1) DCDC DBIAS in sleep = 0 R/W (0b00000)
VDD_3V4_DOUT (BLOCK2) ADC dout of vdd 3.4v = 0 R/W (0b0000000000)
INITCODE_DIFF_1P8_3P3 (BLOCK2) Initcode diff between IO LDO 1.8v and 3.3v = 0 R/W (0b00000)
HI_DOUT_DIFF_1P8_3P3 (BLOCK2) HI dout diff between IO LDO 1.8v and 3.3v = 0 R/W (0b00000)
BLOCK_USR_DATA (BLOCK3) User data
= 00 00 00 00 00 00 00 00 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
BLOCK_SYS_DATA2 (BLOCK10) System data part 2 (reserved)
= 00 00 00 00 00 00 00 00 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
Flash fuses:
FLASH_TPUW (BLOCK0) Represents the flash waiting time after power-up; = 0 R/W (0b000)
in unit of ms. When the value less than 15; the wa
iting time is the programmed value. Otherwise; the
waiting time is 2 times the programmed value
FORCE_SEND_RESUME (BLOCK0) Represents whether ROM code is forced to send a re = False R/W (0b0)
sume command during SPI boot. 1: forced 0:not forc
ed
FLASH_LDO_EFUSE_SEL (BLOCK0) Represents whether to select efuse control flash l = False R/W (0b0)
do default voltage. 1 : efuse 0 : strapping
FLASH_LDO_POWER_SEL (BLOCK1) Represents which flash ldo be select: 1: FLASH LDO = False R/W (0b0)
1P2 0 : FLASH LDO 1P8
FLASH_CAP (BLOCK1) Flash capacity = 0 R/W (0b000)
FLASH_VENDOR (BLOCK1) Flash vendor = 0 R/W (0b000)
Identity fuses:
WAFER_VERSION_MINOR (BLOCK1) Minor chip version = 1 R/W (0x1)
WAFER_VERSION_MAJOR (BLOCK1) Major chip version = 0 R/W (0b00)
DISABLE_WAFER_VERSION_MAJOR (BLOCK1) Disables check of wafer version major = False R/W (0b0)
DISABLE_BLK_VERSION_MAJOR (BLOCK1) Disables check of blk version major = False R/W (0b0)
BLK_VERSION_MINOR (BLOCK1) BLK_VERSION_MINOR of BLOCK2 = 0 R/W (0b000)
BLK_VERSION_MAJOR (BLOCK1) BLK_VERSION_MAJOR of BLOCK2 = 0 R/W (0b00)
PKG_VERSION (BLOCK1) Package version = 0 R/W (0b000)
OPTIONAL_UNIQUE_ID (BLOCK2) Optional unique 128-bit ID
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
Jtag fuses:
JTAG_SEL_ENABLE (BLOCK0) Represents whether the selection between usb_to_jt = False R/W (0b0)
ag and pad_to_jtag through strapping gpio15 when b
oth EFUSE_DIS_PAD_JTAG and EFUSE_DIS_USB_JTAG are
equal to 0 is enabled or disabled. 1: enabled 0: d
isabled
DIS_PAD_JTAG (BLOCK0) Represents whether JTAG is disabled in the hard wa = False R/W (0b0)
y(permanently). 1: disabled 0: enabled
SOFT_DIS_JTAG (BLOCK0) Represents whether JTAG is disabled in soft way. O = 0 R/W (0b000)
dd number: disabled Even number: enabled
Mac fuses:
MAC (BLOCK1) MAC address
= 30:ed:a0:ed:57:cc (OK) R/W
MAC_EXT (BLOCK1) Represents the extended bits of MAC address = 00:00 (OK) R/W
CUSTOM_MAC (BLOCK3) Custom MAC
= 00:00:00:00:00:00 (OK) R/W
MAC_EUI64 (BLOCK1) calc MAC_EUI64 = MAC[0]:MAC[1]:MAC[2]:MAC_EXT[0]:M
= 30:ed:a0:00:00:ed:57:cc (OK) R/W
AC_EXT[1]:MAC[3]:MAC[4]:MAC[5]
Security fuses:
DIS_FORCE_DOWNLOAD (BLOCK0) Represents whether the function that forces chip i = False R/W (0b0)
nto download mode is disabled or enabled. 1: disab
led 0: enabled
SPI_DOWNLOAD_MSPI_DIS (BLOCK0) Represents whether SPI0 controller during boot_mod = False R/W (0b0)
e_download is disabled or enabled. 1: disabled 0:
enabled
DIS_DOWNLOAD_MANUAL_ENCRYPT (BLOCK0) Represents whether flash encrypt function is disab = False R/W (0b0)
led or enabled(except in SPI boot mode). 1: disabled
0: enabled
SPI_BOOT_CRYPT_CNT (BLOCK0) Enables flash encryption when 1 or 3 bits are set = Disable R/W (0b000)
and disables otherwise
SECURE_BOOT_KEY_REVOKE0 (BLOCK0) Revoke 1st secure boot key = False R/W (0b0)
SECURE_BOOT_KEY_REVOKE1 (BLOCK0) Revoke 2nd secure boot key = False R/W (0b0)
SECURE_BOOT_KEY_REVOKE2 (BLOCK0) Revoke 3rd secure boot key = False R/W (0b0)
KEY_PURPOSE_0 (BLOCK0) Represents the purpose of Key0 = USER R/W (0b00000)
KEY_PURPOSE_1 (BLOCK0) Represents the purpose of Key1 = USER R/W (0b00000)
KEY_PURPOSE_2 (BLOCK0) Represents the purpose of Key2 = USER R/W (0b00000)
KEY_PURPOSE_3 (BLOCK0) Represents the purpose of Key3 = USER R/W (0b00000)
KEY_PURPOSE_4 (BLOCK0) Represents the purpose of Key4 = USER R/W (0b00000)
KEY_PURPOSE_5 (BLOCK0) Represents the purpose of Key5 = USER R/W (0b00000)
SEC_DPA_LEVEL (BLOCK0) Represents the spa secure level by configuring the = 0 R/W (0b00)
clock random divide mode
XTS_DPA_PSEUDO_LEVEL (BLOCK0) Represents the pseudo round level of xts-aes anti- = 0 R/W (0b00)
dpa attack. 3: High. 2: Moderate 1. Low 0: Disabled
XTS_DPA_CLK_ENABLE (BLOCK0) Represents whether xts-aes anti-dpa attack clock i = False R/W (0b0)
s enabled. 1. Enable. 0: Disable.
SECURE_BOOT_SHA384_EN (BLOCK0) Represents if the chip supports Secure Boot using = False R/W (0b0)
SHA-384
SECURE_BOOT_EN (BLOCK0) Represents whether secure boot is enabled or disab = False R/W (0b0)
led. 1: enabled 0: disabled
SECURE_BOOT_AGGRESSIVE_REVOKE (BLOCK0) Represents whether revoking aggressive secure boot = False R/W (0b0)
is enabled or disabled. 1: enabled. 0: disabled
FORCE_USE_KEY_MANAGER_KEY (BLOCK0) Represents whether the corresponding key must come = 0 R/W (0b00000)
from Key Manager. Bit0: Represents whether the EC
DSA key must come from Key Manager.0: The key does
not need to come from Key Manager1: The key must
come from Key ManagerBit1: Represents whether the
XTS-AES (flash and PSRAM) key must come from Key M
anager.0: The key does not need to come from Key M
anager1: The key must come from Key ManagerBit2: R
epresents whether the HMAC key must come from Key
Manager.0: The key does not need to come from Key
Manager1: The key must come from Key ManagerBit3:
Represents whether the DS key must come from Key M
anager.0: The key does not need to come from Key M
anager1: The key must come from Key Manager
FORCE_DISABLE_SW_INIT_KEY (BLOCK0) Represents whether to disable the use of the initi = False R/W (0b0)
alization key written by software and instead forc
e use efuse\_init\_key.0: Enable1: Disable
KM_XTS_KEY_LENGTH_256 (BLOCK0) Represents which key flash encryption uses.0: XTS- = False R/W (0b0)
AES-256 key1: XTS-AES-128 key
LOCK_KM_KEY (BLOCK0) Represents whether the keys in the Key Manager are = False R/W (0b0)
locked after deployment.0: Not locked1: Locked
DIS_DOWNLOAD_MODE (BLOCK0) Represents whether Download mode is disabled or en = False R/W (0b0)
abled. 1: disabled 0: enabled
ENABLE_SECURITY_DOWNLOAD (BLOCK0) Represents whether security download is enabled or = False R/W (0b0)
disabled. 1: enabled 0: disabled
SECURE_VERSION (BLOCK0) Represents the version used by ESP-IDF anti-rollba = 0 R/W (0x0000)
ck feature
BLOCK_KEY0 (BLOCK4)
Purpose: USER
Key0 or user data
= 00 00 00 00 00 00 00 00 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
BLOCK_KEY1 (BLOCK5)
Purpose: USER
Key1 or user data
= 00 00 00 00 00 00 00 00 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
BLOCK_KEY2 (BLOCK6)
Purpose: USER
Key2 or user data
= 00 00 00 00 00 00 00 00 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
BLOCK_KEY3 (BLOCK7)
Purpose: USER
Key3 or user data
= 00 00 00 00 00 00 00 00 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
BLOCK_KEY4 (BLOCK8)
Purpose: USER
Key4 or user data
= 00 00 00 00 00 00 00 00 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
BLOCK_KEY5 (BLOCK9)
Purpose: USER
Key5 or user data
= 00 00 00 00 00 00 00 00 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
Usb fuses:
DIS_USB_JTAG (BLOCK0) Represents whether the function of usb switch to j = False R/W (0b0)
tag is disabled or enabled. 1: disabled 0: enabled
DIS_USB_SERIAL_JTAG_ROM_PRINT (BLOCK0) Represents whether print from USB-Serial-JTAG is d = False R/W (0b0)
isabled or enabled. 1: disabled 0: enabled
DIS_USB_SERIAL_JTAG_DOWNLOAD_MODE (BLOCK0) Represents whether the USB-Serial-JTAG download fu = False R/W (0b0)
nction is disabled or enabled. 1: Disable 0: Enabl
e
USB_EXCHG_PINS (BLOCK0) Represents whether the D+ and D- pins of USB_SERIA = False R/W (0b0)
L_JTAG PHY is exchanged. 1: exchanged 0: not excha
nged
USB_OTG_FS_EXCHG_PINS (BLOCK0) Represents whether the D+ and D- pins of USB_OTG_F = False R/W (0b0)
S PHY is exchanged. 1: exchanged 0: not exchanged
USB_PHY_SEL (BLOCK0) Represents whether to exchange the USB_SERIAL_JTAG = False R/W (0b0)
PHY with USB_OTG_FS PHY. 1: exchanged. 0: not e
xchanged
Vdd fuses:
VDD_SPI_LDO_ADJUST (BLOCK1) Represents configuration of FLASH LDO mode and = 0 R/W (0x00)
voltage.
Wdt fuses:
WDT_DELAY_SEL (BLOCK1) Represents the threshold level of the RTC watchdog = 0 R/W (0b00)
STG0 timeout. 0: Original threshold configuration
value of STG0 *2 1: Original threshold configurat
ion value of STG0 *4 2: Original threshold configu
ration value of STG0 *8 3: Original threshold conf
iguration value of STG0 *16
To get a dump for all eFuse registers.
idf.py -p PORT efuse-dump
Executing action: efuse-dump
Running espefuse in directory <project-directory>
Executing "espefuse dump --chip esp32h4"...
espefuse v5.3.dev3
Connecting....
=== Run "dump" command ===
BLOCK0 ( ) [0 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000
MAC_SPI_8M_0 (BLOCK1 ) [1 ] dump: a0ed57cc 000030ed 00000000 00040000 00000000 00000000
BLOCK_SYS_DATA (BLOCK2 ) [2 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_USR_DATA (BLOCK3 ) [3 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY0 (BLOCK4 ) [4 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY1 (BLOCK5 ) [5 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY2 (BLOCK6 ) [6 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY3 (BLOCK7 ) [7 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY4 (BLOCK8 ) [8 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY5 (BLOCK9 ) [9 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA2 (BLOCK10 ) [10] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Deferred WR_DIS Burning
WR_DIS (Write Disable) is a special eFuse field that implements permanent write-protection. Each bit in WR_DIS disables further programming of one (or more) associated eFuse fields. Once a WR_DIS bit is burned, its associated fields can no longer be modified.
When burning staged data in BLOCK0, the WR_DIS bits are burned separately after all other BLOCK0 data to ensure the burn function can recover from coding errors via its retry mechanism. This approach guarantees that write-protection is applied only after other BLOCK0 data is successfully burned.
Token Dump
The token dump feature provides a compact, single-line representation of an eFuse state that can be copied from device logs and decoded later on the host. This is designed for cases where reading eFuses directly with host tools is not possible or not convenient (for example, UART download is disabled, secure download is enabled, secure boot/flash encryption is deployed, or the device is remote).
EFSR:esp32c3:004:AAGAAAEAAAAAAAAEAAAAAAAAAAAAAAAA:AAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAA:AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA::::::::::epNVBg
A token can represent:
the currently programmed eFuses (read snapshot, EFSR),
the staged (not yet burned) write set (write snapshot, EFSW) — in batch write mode you can dump the pending writes before calling
esp_efuse_batch_write_commit(),both the programmed eFuses and the staged writes in a single token (combined snapshot, EFSRW).
Tokens include a CRC32 checksum to detect truncation and accidental modifications.
Typical Use Cases
Production/field diagnostics: export the eFuse state from a locked-down device and decode it offline.
Post-provisioning verification: confirm security configuration and key purposes after manufacturing steps.
Coding error investigation: capture and share coding-error register snapshots alongside block data.
Audit and traceability: store a token as a provisioning artifact for later review.
Staged write transfer: generate
EFSWin firmware (or on the host) and apply it later using a controlled workflow.
Supported Workflows
On the device:
esp_efuse_token_dump()— always supportsEFSRtokens;EFSWandEFSRWrequire because they expose staged values that are not yet burned and not yet read-protected.esp_efuse_token_burn()— accepts anEFSWtoken and applies staged writes on the device.
On the host:
espefuse --token EFS... summary— decodes tokens and shows the eFuse summary without connecting to a device.espefuse dump --format EFSR— generates anEFSRtoken from a connected chip for sharing/backup.espefuse burn-efuse ... --show-token— generates anEFSWtoken representing staged writes.
Security Note
Important
Tokens are not encrypted. Treat tokens as sensitive data:
Tokens can include unique identifiers (for example MAC/UUID-like fields) and security-relevant configuration bits (secure boot, flash encryption, JTAG/UART disablement, key purposes).
EFSWtokens represent staged writes. They may include write-only key data in plaintext because the staged view shows values that have not yet been burned and are not yet protected by the eFuse read-protection bits. This can disclose provisioning intent and secret material before it is irreversibly locked down.EFSRWtokens include the same staged portion and therefore carry the same plaintext key-exposure risk.Even when certain eFuses are read-protected on the target, the token may still carry operationally sensitive values.
If firmware exposes a console command, remote endpoint, or other runtime API that prints eFuse tokens, the firmware must authenticate and authorize that request before generating the token.
Recommendations:
Share tokens only with trusted parties and via trusted channels (avoid public issue trackers).
Store tokens as you would store other manufacturing/provisioning artifacts (restricted access, limited retention).
Prefer
EFSRtokens for diagnostics and auditing; useEFSWtokens only when you explicitly need to transfer staged write state.
Token format
A token is a colon-separated sequence:
<token_name>:<chip>:<ver>:<b64_block0>:...:<b64_blockN>:<b64_cerr>:<b64_crc32>
Fields:
token_name— one ofEFSR,EFSW, orEFSRW.chip— chip name (lowercase, without dashes), for exampleesp32c3.ver— chip revision as three decimal digits (leading zeros), for example004. Constructed from major and minor wafer version fields using the formulaver = major * 100 + minor, where the major version occupies the first digit and the minor version occupies the last two digits.b64_block0 ... b64_blockN— Base64URL-encoded per-block data. Each block is a concatenation of 32-bit words in little-endian byte order. The number of blocks is not explicitly encoded in the format. It is derived from the chip type. The number of blocks can be determined by counting the colon separators (:) in the token. Empty blocks are represented as consecutive colons (::).b64_cerr— optional Base64URL-encoded coding-error registers snapshot. It may be empty if there are no errors.b64_crc32— Base64URL-encoded CRC32 over whole token"<token_name>:<chip>:<ver>:<b64_block0>:...:<b64_blockN>:<b64_cerr>:". CRC32 is stored little-endian and encoded as unpadded Base64URL.
A token can be decoded and interpreted correctly only when it is processed using the same target it was created for. ESP-IDF APIs and espefuse validate and rely on the following fields: chip name, chip revision, and block layout, as well as CRC32 integrity. If any of these do not match the target chip, decoding errors or missing fields may occur.
Base64URL uses the same alphabet as Base64 but replaces + with - and / with _, and omits padding (=).
Generating Token On-Device
Use esp_efuse_token_dump() to create a token in a buffer or print it to the log:
char token[1024]; /* size depends on target and eFuses */
esp_efuse_token_type_t token_type = ESP_EFUSE_TOKEN_FROM_READ;
ESP_ERROR_CHECK(esp_efuse_token_dump(token_type, token, sizeof(token)));
ESP_LOGI(TAG, "IDF_MONITOR_EXECUTE_ESPEFUSE_SUMMARY %s", token);
Token type values:
ESP_EFUSE_TOKEN_FROM_READ— token of programmed eFuses (starts withEFSR).ESP_EFUSE_TOKEN_FROM_STAGED— token of staged writes (starts withEFSW). It can expose keys in plaintext because it shows values that are not yet burned and not yet read-protected. Requires . Only this type can be burned back.ESP_EFUSE_TOKEN_FROM_READ_STAGED— combined token (starts withEFSRW). It includes the same staged portion and the same plaintext key-exposure risk. Requires .
If buf == NULL, the token is printed to the console (INFO level) without colors, tag, or timestamp.
Burn Token On-Device
Use esp_efuse_token_burn() to apply an EFSW token on the device by burning the staged eFuse writes encoded in the token. The function validates the token integrity (CRC32) and checks compatibility using the chip name and revision. The token is rejected if the major wafer version does not match the target chip. To bypass the version check, use the ignore argument. Example of burning a token:
esp_efuse_batch_write_begin();
esp_efuse_token_burn(token, false); // set true to ignore major version mismatch
esp_efuse_batch_write_commit();
You can skip the major-version check only when you know the token was generated for the same eFuse layout (for example, the same target with only a minor wafer revision difference); in that case the token version may differ only in the last two digits, while the first digit (major version) must normally match.
ESP-IDF Monitor Integration
When running idf.py monitor, the host can automatically decode eFuse tokens printed by the target and display the result inline if the log line starts with one of the following markers:
IDF_MONITOR_EXECUTE_ESPEFUSE_SUMMARY→espefuse --token {ARGS} summary --activeIDF_MONITOR_EXECUTE_ESPEFUSE_DUMP→espefuse --token <TOKEN> dump
{ARGS} must include an eFuse token (EFSR/EFSW/EFSRW) and may include --extend-efuse-table <csv> to load custom eFuse definitions.
Example: The following shows executing the summary command with --active to display only non-zero eFuse fields, which reduces output size. The --extend-efuse-table option loads a custom eFuse table definition:
I (441) example: IDF_MONITOR_EXECUTE_ESPEFUSE_SUMMARY EFSR:esp32c3:100:AAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAA:zIH3-VVgAAAAAAAAAAAAS8kmEVKwQgYB:ZSd8yloMSAJssOWmfZQw8lFbphuTZH574QcV3ggAAAA:AAAAAAAAAAEayAcAAAAAAAAAAAAAAAAAAAAAAAAAAAA:::::::::ydrNkQ --extend-efuse-table main/esp_efuse_custom_table.csv
--- Executing monitor command: espefuse --token EFSR:esp32c3:100:AAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAA:zIH3-VVgAAAAAAAAAAAAS8kmEVKwQgYB:ZSd8yloMSAJssOWmfZQw8lFbphuTZH574QcV3ggAAAA:AAAAAAAAAAEayAcAAAAAAAAAAAAAAAAAAAAAAAAAAAA:::::::::ydrNkQ --extend-efuse-table main/esp_efuse_custom_table.csv summary --active
espefuse v5.1.0
=== Run "summary" command ===
EFUSE_NAME (Block) Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Calibration fuses:
K_RTC_LDO (BLOCK1) BLOCK1 K_RTC_LDO = 77 R/W (0b1001101)
K_DIG_LDO (BLOCK1) BLOCK1 K_DIG_LDO = 68 R/W (0b1000100)
V_RTC_DBIAS20 (BLOCK1) BLOCK1 voltage of rtc dbias20 = 144 R/W (0x90)
V_DIG_DBIAS20 (BLOCK1) BLOCK1 voltage of digital dbias20 = 130 R/W (0x82)
DIG_DBIAS_HVT (BLOCK1) BLOCK1 digital dbias when hvt = 21 R/W (0b10101)
THRES_HVT (BLOCK1) BLOCK1 pvt threshold when hvt = 400 R/W (0b0110010000)
TEMP_CALIB (BLOCK2) Temperature calibration data = -10.600000000000001 R/W (0b101101010)
OCODE (BLOCK2) ADC OCode = 101 R/W (0x65)
ADC1_INIT_CODE_ATTEN0 (BLOCK2) ADC1 init code at atten0 = 442 R/W (0b0110111010)
ADC1_INIT_CODE_ATTEN1 (BLOCK2) ADC1 init code at atten1 = 588 R/W (0b1001001100)
ADC1_INIT_CODE_ATTEN2 (BLOCK2) ADC1 init code at atten2 = 612 R/W (0b1001100100)
ADC1_INIT_CODE_ATTEN3 (BLOCK2) ADC1 init code at atten3 = 735 R/W (0b1011011111)
ADC1_CAL_VOL_ATTEN0 (BLOCK2) ADC1 calibration voltage at atten0 = 535 R/W (0b1000010111)
ADC1_CAL_VOL_ATTEN1 (BLOCK2) ADC1 calibration voltage at atten1 = 31 R/W (0b0000011111)
ADC1_CAL_VOL_ATTEN2 (BLOCK2) ADC1 calibration voltage at atten2 = 533 R/W (0b1000010101)
ADC1_CAL_VOL_ATTEN3 (BLOCK2) ADC1 calibration voltage at atten3 = 567 R/W (0b1000110111)
Config fuses:
ERR_RST_ENABLE (BLOCK0) Use BLOCK0 to check error record registers = with check R/W (0b1)
BLOCK_USR_DATA (BLOCK3) User data
= 00 00 00 00 00 00 00 01 1a c8 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
Flash fuses:
FLASH_CAP (BLOCK1) Flash capacity = 4M R/W (0b001)
FLASH_TEMP (BLOCK1) Flash temperature = 105C R/W (0b01)
FLASH_VENDOR (BLOCK1) Flash vendor = XMC R/W (0b001)
Identity fuses:
BLK_VERSION_MINOR (BLOCK1) BLK_VERSION_MINOR = 3 R/W (0b011)
WAFER_VERSION_MAJOR (BLOCK1) WAFER_VERSION_MAJOR = 1 R/W (0b01)
OPTIONAL_UNIQUE_ID (BLOCK2) Optional unique 128-bit ID
= 65 27 7c ca 5a 0c 48 02 6c b0 e5 a6 7d 94 30 f2 R/W
BLK_VERSION_MAJOR (BLOCK2) BLK_VERSION_MAJOR of BLOCK2 = With calibration R/W (0b01)
Mac fuses:
MAC (BLOCK1) MAC address
= 60:55:f9:f7:81:cc (OK) R/W
User fuses:
MODULE_VERSION (BLOCK3) Module version (56-63) = 1 R/W (0x01)
DEVICE_ROLE (BLOCK3) Device role (64-66) = 2 R/W (0b010)
SETTING_1 (BLOCK3) Setting 1 (67-72) = 3 R/W (0b000011)
SETTING_2 (BLOCK3) Setting 2 (73-77) = 4 R/W (0b00100)
CUSTOM_SECURE_VERSION (BLOCK3) Custom secure version (78-93) = 31 R/W (0x001f)
...
Example (dump):
I (441) example: IDF_MONITOR_EXECUTE_ESPEFUSE_DUMP EFSR:esp32c3:100:AAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAA:zIH3-VVgAAAAAAAAAAAAS8kmEVKwQgYB:ZSd8yloMSAJssOWmfZQw8lFbphuTZH574QcV3ggAAAA:AAAAAAAAAAEayAcAAAAAAAAAAAAAAAAAAAAAAAAAAAA:::::::::ydrNkQ
--- Executing monitor command: espefuse --token EFSR:esp32c3:100:AAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAA:zIH3-VVgAAAAAAAAAAAAS8kmEVKwQgYB:ZSd8yloMSAJssOWmfZQw8lFbphuTZH574QcV3ggAAAA:AAAAAAAAAAEayAcAAAAAAAAAAAAAAAAAAAAAAAAAAAA:::::::::ydrNkQ dump
espefuse v5.1.0
=== Run "dump" command ===
BLOCK0 ( ) [0 ] dump: 00000000 00000000 00000000 00000000 80000000 00000000
MAC_SPI_8M_0 (BLOCK1 ) [1 ] dump: f9f781cc 00006055 00000000 4b000000 521126c9 010642b0
BLOCK_SYS_DATA (BLOCK2 ) [2 ] dump: ca7c2765 02480c5a a6e5b06c f230947d 1ba65b51 7b7e6493 de1507e1 00000008
BLOCK_USR_DATA (BLOCK3 ) [3 ] dump: 00000000 01000000 0007c81a 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY0 (BLOCK4 ) [4 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY1 (BLOCK5 ) [5 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY2 (BLOCK6 ) [6 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY3 (BLOCK7 ) [7 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY4 (BLOCK8 ) [8 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_KEY5 (BLOCK9 ) [9 ] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK_SYS_DATA2 (BLOCK10 ) [10] dump: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Application Examples
system/efuse demonstrates how to use the eFuse API on ESP32-H4, showing read and write operations with fields from the common and custom eFuse tables, and explaining the use of virtual eFuses for debugging purposes.
API Reference
Header File
This header file can be included with:
#include "esp_efuse_chip.h"
This header file is a part of the API provided by the
efusecomponent. To declare that your component depends onefuse, add the following to your CMakeLists.txt:REQUIRES efuse
or
PRIV_REQUIRES efuse
Enumerations
-
enum esp_efuse_block_t
Type of eFuse blocks ESP32H4.
Values:
-
enumerator EFUSE_BLK0
Number of eFuse BLOCK0. REPEAT_DATA
-
enumerator EFUSE_BLK1
Number of eFuse BLOCK1. MAC_SPI_8M_SYS
-
enumerator EFUSE_BLK2
Number of eFuse BLOCK2. SYS_DATA_PART1
-
enumerator EFUSE_BLK_SYS_DATA_PART1
Number of eFuse BLOCK2. SYS_DATA_PART1
-
enumerator EFUSE_BLK3
Number of eFuse BLOCK3. USER_DATA
-
enumerator EFUSE_BLK_USER_DATA
Number of eFuse BLOCK3. USER_DATA
-
enumerator EFUSE_BLK4
Number of eFuse BLOCK4. KEY0
-
enumerator EFUSE_BLK_KEY0
Number of eFuse BLOCK4. KEY0
-
enumerator EFUSE_BLK5
Number of eFuse BLOCK5. KEY1
-
enumerator EFUSE_BLK_KEY1
Number of eFuse BLOCK5. KEY1
-
enumerator EFUSE_BLK6
Number of eFuse BLOCK6. KEY2
-
enumerator EFUSE_BLK_KEY2
Number of eFuse BLOCK6. KEY2
-
enumerator EFUSE_BLK7
Number of eFuse BLOCK7. KEY3
-
enumerator EFUSE_BLK_KEY3
Number of eFuse BLOCK7. KEY3
-
enumerator EFUSE_BLK8
Number of eFuse BLOCK8. KEY4
-
enumerator EFUSE_BLK_KEY4
Number of eFuse BLOCK8. KEY4
-
enumerator EFUSE_BLK9
Number of eFuse BLOCK9. KEY5
-
enumerator EFUSE_BLK_KEY5
Number of eFuse BLOCK9. KEY5
-
enumerator EFUSE_BLK_KEY_MAX
-
enumerator EFUSE_BLK10
Number of eFuse BLOCK10. SYS_DATA_PART2
-
enumerator EFUSE_BLK_SYS_DATA_PART2
Number of eFuse BLOCK10. SYS_DATA_PART2
-
enumerator EFUSE_BLK_MAX
-
enumerator EFUSE_BLK0
-
enum esp_efuse_coding_scheme_t
Type of coding scheme.
Values:
-
enumerator EFUSE_CODING_SCHEME_NONE
None
-
enumerator EFUSE_CODING_SCHEME_RS
Reed-Solomon coding
-
enumerator EFUSE_CODING_SCHEME_NONE
-
enum esp_efuse_purpose_t
Type of key purpose.
Values:
-
enumerator ESP_EFUSE_KEY_PURPOSE_USER
User purposes (software-only use)
-
enumerator ESP_EFUSE_KEY_PURPOSE_ECDSA_KEY
ECDSA private key (P256) (Expected in little endian order)
-
enumerator ESP_EFUSE_KEY_PURPOSE_ECDSA_KEY_P256
ECDSA private key (P256) (Expected in little endian order)
-
enumerator ESP_EFUSE_KEY_PURPOSE_XTS_AES_256_KEY_1
Flash encryption key (XTS_AES_256_KEY_1)
-
enumerator ESP_EFUSE_KEY_PURPOSE_XTS_AES_256_KEY_2
Flash encryption key (XTS_AES_256_KEY_2)
-
enumerator ESP_EFUSE_KEY_PURPOSE_XTS_AES_128_KEY
XTS_AES_128_KEY (flash/PSRAM encryption)
-
enumerator ESP_EFUSE_KEY_PURPOSE_HMAC_DOWN_ALL
HMAC Downstream mode
-
enumerator ESP_EFUSE_KEY_PURPOSE_HMAC_DOWN_JTAG
JTAG soft enable key (uses HMAC Downstream mode)
-
enumerator ESP_EFUSE_KEY_PURPOSE_HMAC_DOWN_DIGITAL_SIGNATURE
Keep for compatibility although H4 has no DS peripheral
-
enumerator ESP_EFUSE_KEY_PURPOSE_HMAC_UP
HMAC Upstream mode
-
enumerator ESP_EFUSE_KEY_PURPOSE_SECURE_BOOT_DIGEST0
SECURE_BOOT_DIGEST0 (Secure Boot key digest)
-
enumerator ESP_EFUSE_KEY_PURPOSE_SECURE_BOOT_DIGEST1
SECURE_BOOT_DIGEST1 (Secure Boot key digest)
-
enumerator ESP_EFUSE_KEY_PURPOSE_SECURE_BOOT_DIGEST2
SECURE_BOOT_DIGEST2 (Secure Boot key digest)
-
enumerator ESP_EFUSE_KEY_PURPOSE_KM_INIT_KEY
KM_INIT_KEY
-
enumerator ESP_EFUSE_KEY_PURPOSE_XTS_AES_256_PSRAM_KEY_1
PSRAM encryption key (XTS_AES_256_KEY_1)
-
enumerator ESP_EFUSE_KEY_PURPOSE_XTS_AES_256_PSRAM_KEY_2
PSRAM encryption key (XTS_AES_256_KEY_2)
-
enumerator ESP_EFUSE_KEY_PURPOSE_XTS_AES_128_PSRAM_KEY
PSRAM encryption key (XTS_AES_128_KEY)
-
enumerator ESP_EFUSE_KEY_PURPOSE_ECDSA_KEY_P192
ECDSA private key (P192)
-
enumerator ESP_EFUSE_KEY_PURPOSE_ECDSA_KEY_P384_L
ECDSA private key (P384 low)
-
enumerator ESP_EFUSE_KEY_PURPOSE_ECDSA_KEY_P384_H
ECDSA private key (P384 high)
-
enumerator ESP_EFUSE_KEY_PURPOSE_MAX
MAX PURPOSE
-
enumerator ESP_EFUSE_KEY_PURPOSE_USER
Header File
This header file can be included with:
#include "esp_efuse.h"
This header file is a part of the API provided by the
efusecomponent. To declare that your component depends onefuse, add the following to your CMakeLists.txt:REQUIRES efuse
or
PRIV_REQUIRES efuse
Functions
-
esp_err_t esp_efuse_read_field_blob(const esp_efuse_desc_t *field[], void *dst, size_t dst_size_bits)
Reads bits from EFUSE field and writes it into an array.
The number of read bits will be limited to the minimum value from the description of the bits in "field" structure or "dst_size_bits" required size. Use "esp_efuse_get_field_size()" function to determine the length of the field.
Note
Please note that reading in the batch mode does not show uncommitted changes.
- Parameters:
field -- [in] A pointer to the structure describing the fields of efuse.
dst -- [out] A pointer to array that will contain the result of reading.
dst_size_bits -- [in] The number of bits required to read. If the requested number of bits is greater than the field, the number will be limited to the field size.
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
-
bool esp_efuse_read_field_bit(const esp_efuse_desc_t *field[])
Read a single bit eFuse field as a boolean value.
Note
The value must exist and must be a single bit wide. If there is any possibility of an error in the provided arguments, call esp_efuse_read_field_blob() and check the returned value instead.
Note
If assertions are enabled and the parameter is invalid, execution will abort
Note
Please note that reading in the batch mode does not show uncommitted changes.
- Parameters:
field -- [in] A pointer to the structure describing the fields of efuse.
- Returns:
true: The field parameter is valid and the bit is set.
false: The bit is not set, or the parameter is invalid and assertions are disabled.
-
esp_err_t esp_efuse_read_field_cnt(const esp_efuse_desc_t *field[], size_t *out_cnt)
Reads bits from EFUSE field and returns number of bits programmed as "1".
If the bits are set not sequentially, they will still be counted.
Note
Please note that reading in the batch mode does not show uncommitted changes.
- Parameters:
field -- [in] A pointer to the structure describing the fields of efuse.
out_cnt -- [out] A pointer that will contain the number of programmed as "1" bits.
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
-
esp_err_t esp_efuse_write_field_blob(const esp_efuse_desc_t *field[], const void *src, size_t src_size_bits)
Writes array to EFUSE field.
The number of write bits will be limited to the minimum value from the description of the bits in "field" structure or "src_size_bits" required size. Use "esp_efuse_get_field_size()" function to determine the length of the field. After the function is completed, the writing registers are cleared.
- Parameters:
field -- [in] A pointer to the structure describing the fields of efuse.
src -- [in] A pointer to array that contains the data for writing.
src_size_bits -- [in] The number of bits required to write.
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
-
esp_err_t esp_efuse_write_field_cnt(const esp_efuse_desc_t *field[], size_t cnt)
Writes a required count of bits as "1" to EFUSE field.
If there are no free bits in the field to set the required number of bits to "1", ESP_ERR_EFUSE_CNT_IS_FULL error is returned, the field will not be partially recorded. After the function is completed, the writing registers are cleared.
- Parameters:
field -- [in] A pointer to the structure describing the fields of efuse.
cnt -- [in] Required number of programmed as "1" bits.
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_CNT_IS_FULL: Not all requested cnt bits is set.
-
esp_err_t esp_efuse_write_field_bit(const esp_efuse_desc_t *field[])
Write a single bit eFuse field to 1.
For use with eFuse fields that are a single bit. This function will write the bit to value 1 if it is not already set, or does nothing if the bit is already set.
This is equivalent to calling esp_efuse_write_field_cnt() with the cnt parameter equal to 1, except that it will return ESP_OK if the field is already set to 1.
- Parameters:
field -- [in] Pointer to the structure describing the efuse field.
- Returns:
ESP_OK: The operation was successfully completed, or the bit was already set to value 1.
ESP_ERR_INVALID_ARG: Error in the passed arguments, including if the efuse field is not 1 bit wide.
-
esp_err_t esp_efuse_set_write_protect(esp_efuse_block_t blk)
Sets a write protection for the whole block.
After that, it is impossible to write to this block. The write protection does not apply to block 0.
- Parameters:
blk -- [in] Block number of eFuse. (EFUSE_BLK1, EFUSE_BLK2 and EFUSE_BLK3)
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_CNT_IS_FULL: Not all requested cnt bits is set.
ESP_ERR_NOT_SUPPORTED: The block does not support this command.
ESP_ERR_BURN_WR_DIS: Failed to burn WR_DIS field.
-
esp_err_t esp_efuse_set_read_protect(esp_efuse_block_t blk)
Sets a read protection for the whole block.
After that, it is impossible to read from this block. The read protection does not apply to block 0.
- Parameters:
blk -- [in] Block number of eFuse. (EFUSE_BLK1, EFUSE_BLK2 and EFUSE_BLK3)
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_CNT_IS_FULL: Not all requested cnt bits is set.
ESP_ERR_NOT_SUPPORTED: The block does not support this command.
-
int esp_efuse_get_field_size(const esp_efuse_desc_t *field[])
Returns the number of bits used by field.
- Parameters:
field -- [in] A pointer to the structure describing the fields of efuse.
- Returns:
Returns the number of bits used by field.
-
uint32_t esp_efuse_read_reg(esp_efuse_block_t blk, unsigned int num_reg)
Returns value of efuse register.
This is a thread-safe implementation. Example: EFUSE_BLK2_RDATA3_REG where (blk=2, num_reg=3)
Note
Please note that reading in the batch mode does not show uncommitted changes.
- Parameters:
blk -- [in] Block number of eFuse.
num_reg -- [in] The register number in the block.
- Returns:
Value of register
-
esp_err_t esp_efuse_write_reg(esp_efuse_block_t blk, unsigned int num_reg, uint32_t val)
Write value to efuse register.
Apply a coding scheme if necessary. This is a thread-safe implementation. Example: EFUSE_BLK3_WDATA0_REG where (blk=3, num_reg=0)
- Parameters:
blk -- [in] Block number of eFuse.
num_reg -- [in] The register number in the block.
val -- [in] Value to write.
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
-
esp_efuse_coding_scheme_t esp_efuse_get_coding_scheme(esp_efuse_block_t blk)
Return efuse coding scheme for blocks.
Note
The coding scheme is applicable only to 1, 2 and 3 blocks. For 0 block, the coding scheme is always
NONE.- Parameters:
blk -- [in] Block number of eFuse.
- Returns:
Return efuse coding scheme for blocks
-
esp_err_t esp_efuse_read_block(esp_efuse_block_t blk, void *dst_key, size_t offset_in_bits, size_t size_bits)
Read key to efuse block starting at the offset and the required size.
Note
Please note that reading in the batch mode does not show uncommitted changes.
- Parameters:
blk -- [in] Block number of eFuse.
dst_key -- [in] A pointer to array that will contain the result of reading.
offset_in_bits -- [in] Start bit in block.
size_bits -- [in] The number of bits required to read.
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
-
esp_err_t esp_efuse_write_block(esp_efuse_block_t blk, const void *src_key, size_t offset_in_bits, size_t size_bits)
Write key to efuse block starting at the offset and the required size.
- Parameters:
blk -- [in] Block number of eFuse.
src_key -- [in] A pointer to array that contains the key for writing.
offset_in_bits -- [in] Start bit in block.
size_bits -- [in] The number of bits required to write.
- Returns:
ESP_OK: The operation was successfully completed.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits
-
uint32_t esp_efuse_get_pkg_ver(void)
Returns chip package from efuse.
- Returns:
chip package
-
esp_err_t esp_efuse_set_recovery_bootloader_offset(const uint32_t offset)
Sets the recovery bootloader flash offset in eFuse.
This function is used to set the flash offset in eFuse for the recovery bootloader. If an offset is already set in eFuse, it will be validated against the provided offset.
- Parameters:
offset -- Flash offset where the recovery bootloader is located.
- Returns:
ESP_OK: Successfully set or given offset is already set.
ESP_ERR_NOT_ALLOWED: Recovery bootloader feature is disabled in eFuse.
ESP_FAIL: Failed to update the recovery bootloader flash offset.
Error code from eFuse read/write operations if an error occurs.
-
void esp_efuse_reset(void)
Reset efuse write registers.
Efuse write registers are written to zero, to negate any changes that have been staged here.
Note
This function is not threadsafe, if calling code updates efuse values from multiple tasks then this is caller's responsibility to serialise.
-
esp_err_t esp_efuse_disable_rom_download_mode(void)
Disable ROM Download Mode via eFuse.
Permanently disables the ROM Download Mode feature. Once disabled, if the SoC is booted with strapping pins set for ROM Download Mode then an error is printed instead.
Note
Not all SoCs support this option. An error will be returned if called on an ESP32 with a silicon revision lower than 3, as these revisions do not support this option.
Note
If ROM Download Mode is already disabled, this function does nothing and returns success.
- Returns:
ESP_OK If the eFuse was successfully burned, or had already been burned.
ESP_ERR_NOT_SUPPORTED (ESP32 only) This SoC is not capable of disabling UART download mode
ESP_ERR_INVALID_STATE (ESP32 only) This eFuse is write protected and cannot be written
-
esp_err_t esp_efuse_set_rom_log_scheme(esp_efuse_rom_log_scheme_t log_scheme)
Set boot ROM log scheme via eFuse.
Note
By default, the boot ROM will always print to console. This API can be called to set the log scheme only once per chip, once the value is changed from the default it can't be changed again.
- Parameters:
log_scheme -- Supported ROM log scheme
- Returns:
ESP_OK If the eFuse was successfully burned, or had already been burned.
ESP_ERR_NOT_SUPPORTED (ESP32 only) This SoC is not capable of setting ROM log scheme
ESP_ERR_INVALID_STATE This eFuse is write protected or has been burned already
-
uint32_t esp_efuse_read_secure_version(void)
Return secure_version from efuse field.
- Returns:
Secure version from efuse field
-
bool esp_efuse_check_secure_version(uint32_t secure_version)
Check secure_version from app and secure_version and from efuse field.
- Parameters:
secure_version -- Secure version from app.
- Returns:
True: If version of app is equal or more then secure_version from efuse.
-
esp_err_t esp_efuse_update_secure_version(uint32_t secure_version)
Write efuse field by secure_version value.
Update the secure_version value is available if the coding scheme is None. Note: Do not use this function in your applications. This function is called as part of the other API.
- Parameters:
secure_version -- [in] Secure version from app.
- Returns:
ESP_OK: Successful.
ESP_FAIL: secure version of app cannot be set to efuse field.
ESP_ERR_NOT_SUPPORTED: Anti rollback is not supported with the 3/4 and Repeat coding scheme.
-
esp_err_t esp_efuse_batch_write_begin(void)
Set the batch mode of writing fields.
This mode allows you to write the fields in the batch mode when need to burn several efuses at one time. To enable batch mode call begin() then perform as usually the necessary operations read and write and at the end call commit() to actually burn all written efuses. The batch mode can be used nested. The commit will be done by the last commit() function. The number of begin() functions should be equal to the number of commit() functions.
Note: If batch mode is enabled by the first task, at this time the second task cannot write/read efuses. The second task will wait for the first task to complete the batch operation.
// Example of using the batch writing mode. // set the batch writing mode esp_efuse_batch_write_begin(); // use any writing functions as usual esp_efuse_write_field_blob(ESP_EFUSE_...); esp_efuse_write_field_cnt(ESP_EFUSE_...); esp_efuse_set_write_protect(EFUSE_BLKx); esp_efuse_write_reg(EFUSE_BLKx, ...); esp_efuse_write_block(EFUSE_BLKx, ...); esp_efuse_write(ESP_EFUSE_1, 3); // ESP_EFUSE_1 == 1, here we write a new value = 3. The changes will be burn by the commit() function. esp_efuse_read_...(ESP_EFUSE_1); // this function returns ESP_EFUSE_1 == 1 because uncommitted changes are not readable, it will be available only after commit. ... // esp_efuse_batch_write APIs can be called recursively. esp_efuse_batch_write_begin(); esp_efuse_set_write_protect(EFUSE_BLKx); esp_efuse_batch_write_commit(); // the burn will be skipped here, it will be done in the last commit(). ... // Write all of these fields to the efuse registers esp_efuse_batch_write_commit(); esp_efuse_read_...(ESP_EFUSE_1); // this function returns ESP_EFUSE_1 == 3.
Note
Please note that reading in the batch mode does not show uncommitted changes.
- Returns:
ESP_OK: Successful.
-
esp_err_t esp_efuse_batch_write_cancel(void)
Reset the batch mode of writing fields.
It will reset the batch writing mode and any written changes.
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_STATE: The batch mode was not set.
-
esp_err_t esp_efuse_batch_write_commit(void)
Writes all prepared data for the batch mode.
Must be called to ensure changes are written to the efuse registers. After this the batch writing mode will be reset.
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_STATE: The deferred writing mode was not set.
ESP_FAIL: Failed to write efuse fields.
ESP_ERR_BURN_WR_DIS: Failed to burn WR_DIS field.
-
bool esp_efuse_block_is_empty(esp_efuse_block_t block)
Checks that the given block is empty.
- Returns:
True: The block is empty.
False: The block is not empty or was an error.
-
bool esp_efuse_get_key_dis_read(esp_efuse_block_t block)
Returns a read protection for the key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
True: The key block is read protected False: The key block is readable.
-
esp_err_t esp_efuse_set_key_dis_read(esp_efuse_block_t block)
Sets a read protection for the key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
-
bool esp_efuse_get_key_dis_write(esp_efuse_block_t block)
Returns a write protection for the key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
True: The key block is write protected False: The key block is writeable.
-
esp_err_t esp_efuse_set_key_dis_write(esp_efuse_block_t block)
Sets a write protection for the key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
ESP_ERR_BURN_WR_DIS: Failed to burn WR_DIS field.
-
bool esp_efuse_key_block_unused(esp_efuse_block_t block)
Returns true if the key block is unused, false otherwise.
An unused key block is all zero content, not read or write protected, and has purpose 0 (ESP_EFUSE_KEY_PURPOSE_USER)
- Parameters:
block -- key block to check.
- Returns:
True if key block is unused,
False if key block is used or the specified block index is not a key block.
-
bool esp_efuse_find_purpose(esp_efuse_purpose_t purpose, esp_efuse_block_t *block)
Find a key block with the particular purpose set.
- Parameters:
purpose -- [in] Purpose to search for.
block -- [out] Pointer in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX which will be set to the key block if found. Can be NULL, if only need to test the key block exists.
- Returns:
True: If found,
False: If not found (value at block pointer is unchanged).
-
bool esp_efuse_get_keypurpose_dis_write(esp_efuse_block_t block)
Returns a write protection of the key purpose field for an efuse key block.
Note
For ESP32: no keypurpose, it returns always True.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
True: The key purpose is write protected. False: The key purpose is writeable.
-
esp_efuse_purpose_t esp_efuse_get_key_purpose(esp_efuse_block_t block)
Returns the current purpose set for an efuse key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
Value: If Successful, it returns the value of the purpose related to the given key block.
ESP_EFUSE_KEY_PURPOSE_MAX: Otherwise.
-
const esp_efuse_desc_t **esp_efuse_get_purpose_field(esp_efuse_block_t block)
Returns a pointer to a key purpose for an efuse key block.
To get the value of this field use esp_efuse_read_field_blob() or esp_efuse_get_key_purpose().
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
Pointer: If Successful returns a pointer to the corresponding efuse field otherwise NULL.
-
const esp_efuse_desc_t **esp_efuse_get_key(esp_efuse_block_t block)
Returns a pointer to a key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
Pointer: If Successful returns a pointer to the corresponding efuse field otherwise NULL.
-
esp_err_t esp_efuse_set_key_purpose(esp_efuse_block_t block, esp_efuse_purpose_t purpose)
Sets a key purpose for an efuse key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
purpose -- [in] Key purpose.
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
-
esp_err_t esp_efuse_set_keypurpose_dis_write(esp_efuse_block_t block)
Sets a write protection of the key purpose field for an efuse key block.
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
ESP_ERR_BURN_WR_DIS: Failed to burn WR_DIS field.
-
esp_efuse_block_t esp_efuse_find_unused_key_block(void)
Search for an unused key block and return the first one found.
See esp_efuse_key_block_unused for a description of an unused key block.
- Returns:
First unused key block, or EFUSE_BLK_KEY_MAX if no unused key block is found.
-
unsigned esp_efuse_count_unused_key_blocks(void)
Return the number of unused efuse key blocks in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX.
-
bool esp_efuse_get_digest_revoke(unsigned num_digest)
Returns the status of the Secure Boot public key digest revocation bit.
- Parameters:
num_digest -- [in] The number of digest in range 0..2
- Returns:
True: If key digest is revoked,
False; If key digest is not revoked.
-
esp_err_t esp_efuse_set_digest_revoke(unsigned num_digest)
Sets the Secure Boot public key digest revocation bit.
- Parameters:
num_digest -- [in] The number of digest in range 0..2
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
-
bool esp_efuse_get_write_protect_of_digest_revoke(unsigned num_digest)
Returns a write protection of the Secure Boot public key digest revocation bit.
- Parameters:
num_digest -- [in] The number of digest in range 0..2
- Returns:
True: The revocation bit is write protected. False: The revocation bit is writeable.
-
esp_err_t esp_efuse_set_write_protect_of_digest_revoke(unsigned num_digest)
Sets a write protection of the Secure Boot public key digest revocation bit.
- Parameters:
num_digest -- [in] The number of digest in range 0..2
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
ESP_ERR_BURN_WR_DIS: Failed to burn WR_DIS field.
-
esp_err_t esp_efuse_write_key(esp_efuse_block_t block, esp_efuse_purpose_t purpose, const void *key, size_t key_size_bytes)
Program a block of key data to an efuse block.
The burn of a key, protection bits, and a purpose happens in batch mode.
Note
This API also enables the read protection efuse bit for certain key blocks like XTS-AES, HMAC, ECDSA etc. This ensures that the key is only accessible to hardware peripheral.
Note
For SoC's with capability
SOC_EFUSE_ECDSA_USE_HARDWARE_K(e.g., ESP32-H2), this API writes an additional efuse bit for ECDSA key purpose to enforce hardware TRNG generated k mode in the peripheral.- Parameters:
block -- [in] Block to read purpose for. Must be in range EFUSE_BLK_KEY0 to EFUSE_BLK_KEY_MAX. Key block must be unused (esp_efuse_key_block_unused).
purpose -- [in] Purpose to set for this key. Purpose must be already unset.
key -- [in] Pointer to data to write.
key_size_bytes -- [in] Bytes length of data to write.
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_INVALID_STATE: Error in efuses state, unused block not found.
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
ESP_ERR_BURN_WR_DIS: Failed to burn WR_DIS field.
-
esp_err_t esp_efuse_write_keys(const esp_efuse_purpose_t purposes[], uint8_t keys[][32], unsigned number_of_keys)
Program keys to unused efuse blocks.
The burn of keys, protection bits, and purposes happens in batch mode.
Note
This API also enables the read protection efuse bit for certain key blocks like XTS-AES, HMAC, ECDSA etc. This ensures that the key is only accessible to hardware peripheral.
Note
For SoC's with capability
SOC_EFUSE_ECDSA_USE_HARDWARE_K(e.g., ESP32-H2), this API writes an additional efuse bit for ECDSA key purpose to enforce hardware TRNG generated k mode in the peripheral.- Parameters:
purposes -- [in] Array of purposes (purpose[number_of_keys]).
keys -- [in] Array of keys (uint8_t keys[number_of_keys][32]). Each key is 32 bytes long.
number_of_keys -- [in] The number of keys to write (up to 6 keys).
- Returns:
ESP_OK: Successful.
ESP_ERR_INVALID_ARG: Error in the passed arguments.
ESP_ERR_INVALID_STATE: Error in efuses state, unused block not found.
ESP_ERR_NOT_ENOUGH_UNUSED_KEY_BLOCKS: Error not enough unused key blocks available
ESP_ERR_EFUSE_REPEATED_PROG: Error repeated programming of programmed bits is strictly forbidden.
ESP_ERR_CODING: Error range of data does not match the coding scheme.
ESP_ERR_BURN_WR_DIS: Failed to burn WR_DIS field.
-
esp_err_t esp_secure_boot_read_key_digests(esp_secure_boot_key_digests_t *trusted_key_digests)
Read key digests from efuse. Any revoked/missing digests will be marked as NULL.
- Parameters:
trusted_key_digests -- [out] Trusted keys digests, stored in this parameter after successfully completing this function. The number of digests depends on the SOC's capabilities.
- Returns:
ESP_OK: Successful.
ESP_FAIL: If trusted_keys is NULL or there is no valid digest.
-
esp_err_t esp_efuse_check_errors(void)
Checks eFuse errors in BLOCK0.
It does a BLOCK0 check if eFuse EFUSE_ERR_RST_ENABLE is set. If BLOCK0 has an error, it prints the error and returns ESP_FAIL, which should be treated as esp_restart.
Note
Refers to ESP32-C3 only.
- Returns:
ESP_OK: No errors in BLOCK0.
ESP_FAIL: Error in BLOCK0 requiring reboot.
-
esp_err_t esp_efuse_destroy_block(esp_efuse_block_t block)
Destroys the data in the given efuse block, if possible.
Data destruction occurs through the following steps: 1) Destroy data in the block:
If write protection is inactive for the block, then unset bits are burned.
If write protection is active, the block remains unaltered. 2) Set read protection for the block if possible (check write-protection for RD_DIS). In this case, data becomes inaccessible, and the software reads it as all zeros. If write protection is enabled and read protection can not be set, data in the block remains readable (returns an error).
Do not use the batch mode with this function as it does the burning itself!
- Parameters:
block -- [in] A key block in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX
- Returns:
ESP_OK: Successful.
ESP_FAIL: Data remained readable because the block is write-protected and read protection can not be set.
-
bool esp_efuse_is_flash_encryption_enabled(void)
Checks if flash encryption is enabled.
This function checks if the current eFuse configuration supports flash encryption.
-
bool esp_efuse_is_ecdsa_p192_curve_supported(void)
Checks if 192-bit ECDSA curve operations are supported.
This function checks if the current eFuse configuration supports 192-bit ECDSA curve operations.
-
bool esp_efuse_is_ecdsa_p256_curve_supported(void)
Checks if 256-bit ECDSA curve operations are supported.
This function checks if the current eFuse configuration supports 256-bit ECDSA curve operations.
-
esp_err_t esp_efuse_token_dump(esp_efuse_token_type_t dump_type, char *buf, size_t buf_len)
Print a single-line dump token that serializes all eFuse blocks.
Token formats (null-terminated strings):
Read efuse area EFSR:chip_name:chip_version:b64_blocks:b64_cerr:b64_crc32
Staged efuse area EFSW:chip_name:chip_version:b64_blocks:b64_cerr:b64_crc32
Combination of two areas (read and staged) EFSRW:...
This token is useful when a host tool cannot read the device directly (for example, when UART download mode is disabled, secure download is enabled). Copy the entire token string and decode it on a host that has access to espefuse.
Example (decode token and show only active fields):
espefuse --token EFSR:esp32:300:AAABAAAAAAAAAAAAAIAAAAAAAAAAABAAAAAAAA::oKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr8:::fPaC-A summary --active
Where:
token_marker = EFSR, EFSW, or EFSRW
chip_name = CONFIG_IDF_TARGET (e.g., "esp32c5")
chip_version = chip version (e.g., "100" for v1.0). version = major wafer version * 100 + minor wafer version.
b64_blocks = concatenation of all blocks’ 32-bit words (little-endian byte order), encoded as Base64URL without padding, for BLK0..BLK_MAX-1.
b64_cerr = optional coding-error snapshot.
b64_crc32 = crc32("token_marker:chip:ver:b64_blocks:b64_cerr:") b64 - base 64 format (Base64URL, UNPADDED)
Note
Dump modes that include staged data (ESP_EFUSE_TOKEN_FROM_STAGED and ESP_EFUSE_TOKEN_FROM_READ_STAGED) can expose sensitive data, including plaintext key material, because they show values before they are burned and before read-protection is applied. Treat EFSW/EFSRW tokens as sensitive artifacts and enable them only with CONFIG_EFUSE_ENABLE_STAGED_TOKEN_API.
Note
When
bufis NULL, the token is printed with esp_log() using a non-constrained logging configuration. If the token must be emitted from a constrained environment, pass a buffer to this function and print or transport the resulting token with a constrained-safe method.- Parameters:
dump_type -- Select which efuse data to dump: read, staged writes, or both.
buf -- Buffer to store the resulting token string. If NULL, output goes to console.
buf_len -- Length of the buffer. Must be at least ESP_EFUSE_TOKEN_DUMP_MIN_LEN bytes to hold the full token for esp32xx series.
- Returns:
ESP_OK on success.
ESP_ERR_NOT_SUPPORTED if
dump_typerequests staged data and CONFIG_EFUSE_ENABLE_STAGED_TOKEN_API is disabled to avoid exposing staged values, including plaintext key material, before burn/read-protect.ESP_ERR_INVALID_ARG if
dump_typeis invalid.ESP_ERR_INVALID_SIZE if buf_len is too small
-
esp_err_t esp_efuse_token_burn(const char *token_in, bool ignore_ver)
Burns the EFSW token dump.
EFSW:chip_name:chip_version:b64_blocks::b64_crc32
The function validates:
Token marker EFSW
Chip name (must match CONFIG_IDF_TARGET)
Chip version is validated unless ignore_ver is set to true. The major version must be equal.
Chip version unless ignore_ver is true
CRC32
Note
The EFSW token dump can be produced from a host or from-device utility. Examples:
Host:
espefuse burn-bit BLOCK2 1 --show-tokenDevice:
esp_efuse_token_dump(ESP_EFUSE_TOKEN_FROM_STAGED, buf, len)
- Parameters:
token_in -- Null-terminated EFSW token string.
ignore_ver -- If true, skip enforcing the wafer chip version in the token.
- Returns:
ESP_OK on success (token parsed and write efuse area is populated).
ESP_ERR_INVALID_ARG on format/mismatch errors (bad token marker/chip/ver/layout)
ESP_ERR_INVALID_CRC if CRC verification fails
ESP_ERR_INVALID_VERSION if chip version mismatches and ignore_ver is false
Other esp_err_t from lower layers if writing/burning fails
Structures
-
struct esp_efuse_desc_t
Type definition for an eFuse field.
Public Members
-
esp_efuse_block_t efuse_block
Block of eFuse
-
uint16_t bit_start
Start bit [0..511]
-
uint16_t bit_count
Length of bit field [1..-]
-
esp_efuse_block_t efuse_block
Macros
-
ESP_ERR_EFUSE
Base error code for efuse api.
-
ESP_OK_EFUSE_CNT
OK the required number of bits is set.
-
ESP_ERR_EFUSE_CNT_IS_FULL
Error field is full.
-
ESP_ERR_EFUSE_REPEATED_PROG
Error repeated programming of programmed bits is strictly forbidden.
-
ESP_ERR_CODING
Error while a encoding operation.
-
ESP_ERR_NOT_ENOUGH_UNUSED_KEY_BLOCKS
Error not enough unused key blocks available
-
ESP_ERR_DAMAGED_READING
Error. Burn or reset was done during a reading operation leads to damage read data. This error is internal to the efuse component and not returned by any public API.
-
ESP_ERR_BURN_WR_DIS
Error to burn WR_DIS field.
-
ESP_EFUSE_MONITOR_EXECUTE_ESPEFUSE_SUMMARY
Flags specifying which source(s) to use when dumping eFUSE data.
Prefix used in device log lines to trigger automatic token decoding in idf.py monitor.
-
ESP_EFUSE_MONITOR_EXECUTE_ESPEFUSE_DUMP
Prefix used in device log lines to trigger token dump decoding in idf.py monitor.
-
ESP_EFUSE_TOKEN_DUMP_MIN_LEN
Recommended minimum buffer length for esp_efuse_token_dump().
Enumerations
-
enum esp_efuse_rom_log_scheme_t
Type definition for ROM log scheme.
Values:
-
enumerator ESP_EFUSE_ROM_LOG_ALWAYS_ON
Always enable ROM logging
-
enumerator ESP_EFUSE_ROM_LOG_ON_GPIO_LOW
ROM logging is enabled when specific GPIO level is low during start up
-
enumerator ESP_EFUSE_ROM_LOG_ON_GPIO_HIGH
ROM logging is enabled when specific GPIO level is high during start up
-
enumerator ESP_EFUSE_ROM_LOG_ALWAYS_OFF
Disable ROM logging permanently
-
enumerator ESP_EFUSE_ROM_LOG_ALWAYS_ON
-
enum esp_efuse_token_type_t
Values:
-
enumerator ESP_EFUSE_TOKEN_FROM_READ
Dump from the eFUSE read registers (the final, permanently programmed values).
-
enumerator ESP_EFUSE_TOKEN_FROM_STAGED
Dump from write/staging registers or programming buffer (pending or staged writes). This can expose keys in plaintext because it shows values that are not yet burned and not yet read-protected. Requires CONFIG_EFUSE_ENABLE_STAGED_TOKEN_API.
-
enumerator ESP_EFUSE_TOKEN_FROM_READ_STAGED
Combine both read and staged sources to show committed and pending values. The staged portion can expose keys in plaintext because it shows values that are not yet burned and not yet read-protected. Requires CONFIG_EFUSE_ENABLE_STAGED_TOKEN_API.
-
enumerator ESP_EFUSE_TOKEN_FROM_READ