# 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. 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) 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.py` tool 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 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 Technical Reference Manual > eFuse Controller (eFuse) [PDF].

ESP32 has 4 eFuse blocks each containing 256 bits (not all bits can be used for user parameters):

- EFUSE_BLK0 is used entirely for system purposes

- EFUSE_BLK1 is used for Flash Encryption keys. If the Flash Encryption feature is not used, this block can be used for user parameters.

- EFUSE_BLK2 is used for the Secure Boot key. If the Secure Boot feature is not used, this block can be used for user parameters.

- EFUSE_BLK3 can be partially reserved to store a custom MAC address, or can be used entirely for user parameters. Note that some bits are already used in ESP-IDF.

## 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_BLK3), bit_start(0..255), bit_count(1..256), comment

- `field_name`

  > - Name 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_name` unique 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_FACTORY` field in the common table).

  > - Using `.` will define a child eFuse field. See Structured eFuse Fields for more details.

- `efuse_block`

  > - The eFuse field's block number. E.g., EFUSE_BLK0 to EFUSE_BLK3.

  > - This determines which block the eFuse field is placed.

- `bit_start`

  > - Bit offset (0 to 255) of the eFuse within the block.

  > - `bit_start` is optional and can be omitted.

  >   > - In this case, it is set to `bit_start + bit_count` from 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_count`

  > - The size of the eFuse field in bits (1 to N).

  > - `bit_count` cannot be omitted.

  > - If set to `MAX_BLK_LEN` the eFuse field's size will be the maximum allowable eFuse field size in the block.

  >   > - `MAX_BLK_LEN` takes into account the coding scheme of eFuse.

  >   > - Depending on the coding scheme selected via CONFIG_EFUSE_CODE_SCHEME_SELECTOR, `MAX_BLK_LEN` could be 256 ("None"), 192 ("3/4"), or 128 ("REPEAT").

- `comment`

  > - Comment 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_DIS` record defines the parent eFuse field. All the other records are child fields of `WR_DIS` due to their `WR_DIS.` prefix.

- The child fields must utilize the same bits as their parent field. Take note of `bit_start` and `bit_count` of 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_DIS` and `WR_DIS.RD_DIS` occupy the first and second bit of `WR_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.ALIAS` is a child field and alias of `WR_DIS.FIELD_3` as 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, 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 esp32 esp32/esp_efuse_table.csv

The following C source/header files will be generated by the tool in `$IDF_PATH/components/efuse/esp32`:

- `esp_efuse_table.c` file containing the C structures of the system parameter eFuse fields

- `esp_efuse_table.h` file in the `include` folder. 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 esp32 esp32/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.c` file containing the C structures of the user parameter eFuse fields

- `esp_efuse_custom_table.h` file in the `include` folder. 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 supports the following eFuse coding schemes:

- `None` (value 0), meaning no coding scheme is applied.

- `3/4` (value 1).

- `Repeat` (value 2). It is not entirely supported by IDF, not recommended for use.

The coding schemes will encode each eFuse block individually. Furthermore, only EFUSE_BLK1, EFUSE_BLK2 and EFUSE_BLK3 will be encoded, meaning EUSE_BLK0 always uses the `None` coding scheme.

Coding schemes require some bits within an eFuse block to be used as overhead. Thus, by applying a coding scheme, only a subset of the 256 bits within an eFuse block will be usable as eFuse fields.

- `None`: 256 usable bits

- `3/4`: 192 usable bits

- `Repeat`: 128 usable bits

When using a coding scheme, the length of the payload that can be written is limited. For more details, Please Refer to ESP32 Technical Reference Manual > Chapter 20 eFuse Controller [PDF] > Section 20.3.1.3 System Parameter coding_scheme.

You can find out the coding scheme of your chip:

- run the `idf.py efuse-summary` command.

- from `esptool` utility logs (during flashing).

- calling the function `esp_efuse_get_coding_scheme()` in the application for the EFUSE_BLK3 block.

The eFuse fields specified in the CSV files must always comply with the eFuse coding scheme used by the chip. The CONFIG_EFUSE_CODE_SCHEME_SELECTOR option selects which coding scheme is used by the CSV files. When generating source files, if the records in the CSV files do not adhere to the coding scheme, an error message will be displayed. In that case, you must adjust the `bit_start` and `bit_count` of the records to comply with the limitations of the selected coding scheme.

Note

After changing the coding scheme, run `efuse_common_table` and `efuse_custom_table` commands to check the tables of the new coding scheme.

If your program was compiled with `None` encoding but `3/4` is used by the chip, then the `ESP_ERR_CODING` error may occur when calling the eFuse API (The field is outside the block boundaries). If the field matches the new block boundaries, then the API will work without errors.

### `None` Coding Scheme

The `None` coding scheme indicates that no coding scheme is applied, thus all 256 bits of each eFuse block are usable. However, there will be no protection against the corruption of eFuse bits.

### `3/4` Coding Scheme

The `3/4` coding scheme imposes restrictions on writing bits belonging to one coding unit. The whole block with a length of 256 bits is divided into 4 coding units. In each coding unit there are 6 bytes of useful data and 2 service bytes. These 2 service bytes contain the checksum of the previous 6 data bytes.

Due to the calculation of the checksum for each coding unit, the writing process must be divided into the coding units. As such, the normal method (used by the `None` coding scheme) of burning eFuse bits separately over multiple write operations will no longer work. The data for the eFuse fields of a particular coding unit and the unit's associated checksum must be burned in one go. This is known as Batch Writing Mode.

As a result of Batch Writing Mode, a particular coding unit can only be written once (i.e., repeated writing to the same coding unit is prohibited). Thus, any coding unit that is written at run time can only contain one eFuse field. However, if the eFuse fields of a coding unit was specified in advance (via CSV records) or written to via `esp_efuse_write_block()`, then a coding unit can still contain multiple eFuse fields.

### `Repeat` Coding Scheme

The `Repeat` coding scheme simply repeats each eFuse bit, thus does not impose the same Batch Writing Mode restrictions as the `3/4` coding scheme. However, this comes at the cost of a larger overhead, leaving only 128 usable bits per eFuse block.

### 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:

1. Enable batch writing mode by calling `esp_efuse_batch_write_begin()`

2. Write to the eFuse fields as usual using various `esp_efuse_write_...` functions.

3. 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 `3/4 or Repeat` 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`, or `EFSRW`) that can be copied from device logs and decoded on the host with `espefuse --token ...` (useful when direct eFuse access is not available).

- `esp_efuse_token_burn()` - Applies an `EFSW` token 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()`.

## How to Add a New Field

1. Find free bits for field. Refer to the `esp_efuse_table.csv` file, running `idf.py show-efuse-table`, or running the following command:

    $ ./efuse_table_gen.py esp32/esp_efuse_table.csv --info

    Parsing efuse CSV input file $IDF_PATH/components/efuse/esp32/esp_efuse_table.csv ...
    Verifying efuse table...
    Max number of bits in BLK 192
    Sorted efuse table:
    #       field_name                      efuse_block     bit_start       bit_count
    1       WR_DIS                          EFUSE_BLK0         0               16
    2       WR_DIS.RD_DIS                   EFUSE_BLK0         0               1
    3       WR_DIS.WR_DIS                   EFUSE_BLK0         1               1
    4       WR_DIS.FLASH_CRYPT_CNT          EFUSE_BLK0         2               1
    5       WR_DIS.UART_DOWNLOAD_DIS        EFUSE_BLK0         2               1
    6       WR_DIS.MAC                      EFUSE_BLK0         3               1
    7       WR_DIS.MAC_CRC                  EFUSE_BLK0         3               1
    8       WR_DIS.DISABLE_APP_CPU          EFUSE_BLK0         3               1
    9       WR_DIS.DISABLE_BT               EFUSE_BLK0         3               1
    10      WR_DIS.DIS_CACHE                EFUSE_BLK0         3               1
    11      WR_DIS.VOL_LEVEL_HP_INV         EFUSE_BLK0         3               1
    12      WR_DIS.CLK8M_FREQ               EFUSE_BLK0         4               1
    13      WR_DIS.ADC_VREF                 EFUSE_BLK0         4               1
    14      WR_DIS.XPD_SDIO_REG             EFUSE_BLK0         5               1
    15      WR_DIS.XPD_SDIO_TIEH            EFUSE_BLK0         5               1
    16      WR_DIS.XPD_SDIO_FORCE           EFUSE_BLK0         5               1
    17      WR_DIS.SPI_PAD_CONFIG_CLK       EFUSE_BLK0         6               1
    18      WR_DIS.SPI_PAD_CONFIG_Q         EFUSE_BLK0         6               1
    19      WR_DIS.SPI_PAD_CONFIG_D         EFUSE_BLK0         6               1
    20      WR_DIS.SPI_PAD_CONFIG_CS0       EFUSE_BLK0         6               1
    21      WR_DIS.BLOCK1                   EFUSE_BLK0         7               1
    22      WR_DIS.BLOCK2                   EFUSE_BLK0         8               1
    23      WR_DIS.BLOCK3                   EFUSE_BLK0         9               1
    24      WR_DIS.CUSTOM_MAC_CRC           EFUSE_BLK0         9               1
    25      WR_DIS.CUSTOM_MAC               EFUSE_BLK0         9               1
    26      WR_DIS.ADC1_TP_LOW              EFUSE_BLK0         9               1
    27      WR_DIS.ADC1_TP_HIGH             EFUSE_BLK0         9               1
    28      WR_DIS.ADC2_TP_LOW              EFUSE_BLK0         9               1
    29      WR_DIS.ADC2_TP_HIGH             EFUSE_BLK0         9               1
    30      WR_DIS.SECURE_VERSION           EFUSE_BLK0         9               1
    31      WR_DIS.MAC_VERSION              EFUSE_BLK0         9               1
    32      WR_DIS.BLK3_PART_RESERVE        EFUSE_BLK0         10              1
    33      WR_DIS.FLASH_CRYPT_CONFIG       EFUSE_BLK0         10              1
    34      WR_DIS.CODING_SCHEME            EFUSE_BLK0         10              1
    35      WR_DIS.KEY_STATUS               EFUSE_BLK0         10              1
    36      WR_DIS.ABS_DONE_0               EFUSE_BLK0         12              1
    37      WR_DIS.ABS_DONE_1               EFUSE_BLK0         13              1
    38      WR_DIS.JTAG_DISABLE             EFUSE_BLK0         14              1
    39      WR_DIS.CONSOLE_DEBUG_DISABLE    EFUSE_BLK0         15              1
    40      WR_DIS.DISABLE_DL_ENCRYPT       EFUSE_BLK0         15              1
    41      WR_DIS.DISABLE_DL_DECRYPT       EFUSE_BLK0         15              1
    42      WR_DIS.DISABLE_DL_CACHE         EFUSE_BLK0         15              1
    43      RD_DIS                          EFUSE_BLK0         16              4
    44      RD_DIS.BLOCK1                   EFUSE_BLK0         16              1
    45      RD_DIS.BLOCK2                   EFUSE_BLK0         17              1
    46      RD_DIS.BLOCK3                   EFUSE_BLK0         18              1
    47      RD_DIS.CUSTOM_MAC_CRC           EFUSE_BLK0         18              1
    48      RD_DIS.CUSTOM_MAC               EFUSE_BLK0         18              1
    49      RD_DIS.ADC1_TP_LOW              EFUSE_BLK0         18              1
    50      RD_DIS.ADC1_TP_HIGH             EFUSE_BLK0         18              1
    51      RD_DIS.ADC2_TP_LOW              EFUSE_BLK0         18              1
    52      RD_DIS.ADC2_TP_HIGH             EFUSE_BLK0         18              1
    53      RD_DIS.SECURE_VERSION           EFUSE_BLK0         18              1
    54      RD_DIS.MAC_VERSION              EFUSE_BLK0         18              1
    55      RD_DIS.BLK3_PART_RESERVE        EFUSE_BLK0         19              1
    56      RD_DIS.FLASH_CRYPT_CONFIG       EFUSE_BLK0         19              1
    57      RD_DIS.CODING_SCHEME            EFUSE_BLK0         19              1
    58      RD_DIS.KEY_STATUS               EFUSE_BLK0         19              1
    59      FLASH_CRYPT_CNT                 EFUSE_BLK0         20              7
    60      UART_DOWNLOAD_DIS               EFUSE_BLK0         27              1
    61      MAC                             EFUSE_BLK0         32              8
    62      MAC                             EFUSE_BLK0         40              8
    63      MAC                             EFUSE_BLK0         48              8
    64      MAC                             EFUSE_BLK0         56              8
    65      MAC                             EFUSE_BLK0         64              8
    66      MAC                             EFUSE_BLK0         72              8
    67      MAC_CRC                         EFUSE_BLK0         80              8
    68      DISABLE_APP_CPU                 EFUSE_BLK0         96              1
    69      DISABLE_BT                      EFUSE_BLK0         97              1
    70      CHIP_PACKAGE_4BIT               EFUSE_BLK0         98              1
    71      DIS_CACHE                       EFUSE_BLK0         99              1
    72      SPI_PAD_CONFIG_HD               EFUSE_BLK0        100              5
    73      CHIP_PACKAGE                    EFUSE_BLK0        105              3
    74      CHIP_CPU_FREQ_LOW               EFUSE_BLK0        108              1
    75      CHIP_CPU_FREQ_RATED             EFUSE_BLK0        109              1
    76      BLK3_PART_RESERVE               EFUSE_BLK0        110              1
    77      CHIP_VER_REV1                   EFUSE_BLK0        111              1
    78      CLK8M_FREQ                      EFUSE_BLK0        128              8
    79      ADC_VREF                        EFUSE_BLK0        136              5
    80      XPD_SDIO_REG                    EFUSE_BLK0        142              1
    81      XPD_SDIO_TIEH                   EFUSE_BLK0        143              1
    82      XPD_SDIO_FORCE                  EFUSE_BLK0        144              1
    83      SPI_PAD_CONFIG_CLK              EFUSE_BLK0        160              5
    84      SPI_PAD_CONFIG_Q                EFUSE_BLK0        165              5
    85      SPI_PAD_CONFIG_D                EFUSE_BLK0        170              5
    86      SPI_PAD_CONFIG_CS0              EFUSE_BLK0        175              5
    87      CHIP_VER_REV2                   EFUSE_BLK0        180              1
    88      VOL_LEVEL_HP_INV                EFUSE_BLK0        182              2
    89      WAFER_VERSION_MINOR             EFUSE_BLK0        184              2
    90      FLASH_CRYPT_CONFIG              EFUSE_BLK0        188              4
    91      CODING_SCHEME                   EFUSE_BLK0        192              2
    92      CONSOLE_DEBUG_DISABLE           EFUSE_BLK0        194              1
    93      DISABLE_SDIO_HOST               EFUSE_BLK0        195              1
    94      ABS_DONE_0                      EFUSE_BLK0        196              1
    95      ABS_DONE_1                      EFUSE_BLK0        197              1
    96      JTAG_DISABLE                    EFUSE_BLK0        198              1
    97      DISABLE_DL_ENCRYPT              EFUSE_BLK0        199              1
    98      DISABLE_DL_DECRYPT              EFUSE_BLK0        200              1
    99      DISABLE_DL_CACHE                EFUSE_BLK0        201              1
    100     KEY_STATUS                      EFUSE_BLK0        202              1
    101     BLOCK1                          EFUSE_BLK1         0              192
    102     BLOCK2                          EFUSE_BLK2         0              192
    103     CUSTOM_MAC_CRC                  EFUSE_BLK3         0               8
    104     MAC_CUSTOM                      EFUSE_BLK3         8               48
    105     ADC1_TP_LOW                     EFUSE_BLK3         96              7
    106     ADC1_TP_HIGH                    EFUSE_BLK3        103              9
    107     ADC2_TP_LOW                     EFUSE_BLK3        112              7
    108     ADC2_TP_HIGH                    EFUSE_BLK3        119              9
    109     SECURE_VERSION                  EFUSE_BLK3        128              32
    110     MAC_VERSION                     EFUSE_BLK3        184              8

    Used bits in efuse table:
    EFUSE_BLK0
    [0 15] [0 2] [2 3] ... [19 19] [19 27] [32 87] [96 111] [128 140] [142 144] [160 180] [182 185] [188 202]
    EFUSE_BLK1
    [0 191]
    EFUSE_BLK2
    [0 191]
    EFUSE_BLK3
    [0 55] [96 159] [184 191]
    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:

1. Add a record for each eFuse field in CSV file.

2. Run the `show_efuse_table` command to check eFuse table.

3. To generate source files run the `efuse_common_table` or `efuse_custom_table` commands.

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 the `espefuse summary --format json` command 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 CONFIG_EFUSE_VIRTUAL 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 CONFIG_EFUSE_VIRTUAL option, there is the CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH 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 CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH 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 CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH 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 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 efuse-summary

    Executing action: efuse-summary
    (...)

    EFUSE_NAME (Block) Description  = [Meaningful Value] [Readable/Writeable] (Hex Value)
    ----------------------------------------------------------------------------------------
    Calibration fuses:
    ADC_VREF (BLOCK0)                                  True ADC reference voltage                         = 1121 R/W (0b00011)

    Config fuses:
    WR_DIS (BLOCK0)                                    Efuse write disable mask                           = 0 R/W (0x0000)
    RD_DIS (BLOCK0)                                    Disable reading from BlOCK1-3                      = 0 R/W (0x0)
    DISABLE_APP_CPU (BLOCK0)                           Disables APP CPU                                   = False R/W (0b0)
    DISABLE_BT (BLOCK0)                                Disables Bluetooth                                 = False R/W (0b0)
    DIS_CACHE (BLOCK0)                                 Disables cache                                     = False R/W (0b0)
    CHIP_CPU_FREQ_LOW (BLOCK0)                         If set alongside EFUSE_RD_CHIP_CPU_FREQ_RATED; the = False R/W (0b0)
                                                        ESP32's max CPU frequency is rated for 160MHz. 24
                                                       0MHz otherwise
    CHIP_CPU_FREQ_RATED (BLOCK0)                       If set; the ESP32's maximum CPU frequency has been = True R/W (0b1)
                                                        rated
    BLK3_PART_RESERVE (BLOCK0)                         BLOCK3 partially served for ADC calibration data   = False R/W (0b0)
    CLK8M_FREQ (BLOCK0)                                8MHz clock freq override                           = 51 R/W (0x33)
    VOL_LEVEL_HP_INV (BLOCK0)                          This field stores the voltage level for CPU to run = 0 R/W (0b00)
                                                        at 240 MHz; or for flash/PSRAM to run at 80 MHz.0
                                                       x0: level 7; 0x1: level 6; 0x2: level 5; 0x3:i
                                                       level 4. (RO)
    CODING_SCHEME (BLOCK0)                             Efuse variable block length scheme
       = NONE (BLK1-3 len=256 bits) R/W (0b00)
    CONSOLE_DEBUG_DISABLE (BLOCK0)                     Disable ROM BASIC interpreter fallback             = True R/W (0b1)
    DISABLE_SDIO_HOST (BLOCK0)                                                                            = False R/W (0b0)
    DISABLE_DL_CACHE (BLOCK0)                          Disable flash cache in UART bootloader             = False R/W (0b0)

    Flash fuses:
    FLASH_CRYPT_CNT (BLOCK0)                           Flash encryption is enabled if this field has an o = 0 R/W (0b0000000)
                                                       dd number of bits set
    FLASH_CRYPT_CONFIG (BLOCK0)                        Flash encryption config (key tweak bits)           = 0 R/W (0x0)

    Identity fuses:
    CHIP_PACKAGE_4BIT (BLOCK0)                         Chip package identifier #4bit                      = False R/W (0b0)
    CHIP_PACKAGE (BLOCK0)                              Chip package identifier                            = 1 R/W (0b001)
    CHIP_VER_REV1 (BLOCK0)                             bit is set to 1 for rev1 silicon                   = True R/W (0b1)
    CHIP_VER_REV2 (BLOCK0)                                                                                = True R/W (0b1)
    WAFER_VERSION_MINOR (BLOCK0)                                                                          = 0 R/W (0b00)
    WAFER_VERSION_MAJOR (BLOCK0)                       calc WAFER VERSION MAJOR from CHIP_VER_REV1 and CH = 3 R/W (0b011)
                                                       IP_VER_REV2 and apb_ctl_date (read only)
    PKG_VERSION (BLOCK0)                               calc Chip package = CHIP_PACKAGE_4BIT << 3 + CHIP_ = 1 R/W (0x1)
                                                       PACKAGE (read only)

    Jtag fuses:
    JTAG_DISABLE (BLOCK0)                              Disable JTAG                                       = False R/W (0b0)

    Mac fuses:
    MAC (BLOCK0)                                       MAC address
       = 94:b9:7e:5a:6e:58 (CRC 0xe2 OK) R/W
    MAC_CRC (BLOCK0)                                   CRC8 for MAC address                               = 226 R/W (0xe2)
    MAC_VERSION (BLOCK3)                               Version of the MAC field                           = 0 R/W (0x00)

    Security fuses:
    UART_DOWNLOAD_DIS (BLOCK0)                         Disable UART download mode. Valid for ESP32 V3 and = False R/W (0b0)
                                                        newer; only
    ABS_DONE_0 (BLOCK0)                                Secure boot V1 is enabled for bootloader image     = False R/W (0b0)
    ABS_DONE_1 (BLOCK0)                                Secure boot V2 is enabled for bootloader image     = False R/W (0b0)
    DISABLE_DL_ENCRYPT (BLOCK0)                        Disable flash encryption in UART bootloader        = False R/W (0b0)
    DISABLE_DL_DECRYPT (BLOCK0)                        Disable flash decryption in UART bootloader        = False R/W (0b0)
    KEY_STATUS (BLOCK0)                                Usage of efuse block 3 (reserved)                  = False R/W (0b0)
    SECURE_VERSION (BLOCK3)                            Secure version for anti-rollback                   = 0 R/W (0x00000000)
    BLOCK1 (BLOCK1)                                    Flash encryption key
       = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
    BLOCK2 (BLOCK2)                                    Security boot key
       = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
    BLOCK3 (BLOCK3)                                    Variable Block 3
       = 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

    Spi Pad fuses:
    SPI_PAD_CONFIG_HD (BLOCK0)                         read for SPI_pad_config_hd                         = 0 R/W (0b00000)
    SPI_PAD_CONFIG_CLK (BLOCK0)                        Override SD_CLK pad (GPIO6/SPICLK)                 = 0 R/W (0b00000)
    SPI_PAD_CONFIG_Q (BLOCK0)                          Override SD_DATA_0 pad (GPIO7/SPIQ)                = 0 R/W (0b00000)
    SPI_PAD_CONFIG_D (BLOCK0)                          Override SD_DATA_1 pad (GPIO8/SPID)                = 0 R/W (0b00000)
    SPI_PAD_CONFIG_CS0 (BLOCK0)                        Override SD_CMD pad (GPIO11/SPICS0)                = 0 R/W (0b00000)

    Vdd fuses:
    XPD_SDIO_REG (BLOCK0)                              read for XPD_SDIO_REG                              = False R/W (0b0)
    XPD_SDIO_TIEH (BLOCK0)                             If XPD_SDIO_FORCE & XPD_SDIO_REG                   = 1.8V R/W (0b0)
    XPD_SDIO_FORCE (BLOCK0)                            Ignore MTDI pin (GPIO12) for VDD_SDIO on reset     = False R/W (0b0)

    Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V)

To get a dump for all eFuse registers.

    idf.py efuse-dump

    Executing action: efuse-dump
    Running espefuse in directory <project-directory>
    Executing "espefuse dump --chip esp32"...
    espefuse v5.0.2
    Connecting....

    === Run "dump" command ===
    BLOCK0          (                ) [0 ] read_regs: 00000000 7e5a6e58 00e294b9 0000a200 00000333 00100000 00000004
    BLOCK1          (flash_encryption) [1 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    BLOCK2          (secure_boot_v1 s) [2 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    BLOCK3          (                ) [3 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

    EFUSE_REG_DEC_STATUS        0x00000000

## 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 `EFSW` in firmware (or on the host) and apply it later using a controlled workflow.

### Supported Workflows

- On the device:

  > - `esp_efuse_token_dump()` — always supports `EFSR` tokens; `EFSW` and `EFSRW` require CONFIG_EFUSE_ENABLE_STAGED_TOKEN_API because they expose staged values that are not yet burned and not yet read-protected.

  > - `esp_efuse_token_burn()` — accepts an `EFSW` token 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 an `EFSR` token from a connected chip for sharing/backup.

  - `espefuse burn-efuse ... --show-token` — generates an `EFSW` token 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).

- `EFSW` tokens 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.

- `EFSRW` tokens 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 `EFSR` tokens for diagnostics and auditing; use `EFSW` tokens 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 of `EFSR`, `EFSW`, or `EFSRW`.

- `chip` — chip name (lowercase, without dashes), for example `esp32c3`.

- `ver` — chip revision as three decimal digits (leading zeros), for example `004`. Constructed from major and minor wafer version fields using the formula `ver = 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 with `EFSR`).

- `ESP_EFUSE_TOKEN_FROM_STAGED` — token of staged writes (starts with `EFSW`). It 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. Only this type can be burned back.

- `ESP_EFUSE_TOKEN_FROM_READ_STAGED` — combined token (starts with `EFSRW`). It includes the same staged portion and the same plaintext key-exposure risk. Requires CONFIG_EFUSE_ENABLE_STAGED_TOKEN_API.

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 --active`

- `IDF_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, 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

- components/efuse/esp32/include/esp_efuse_chip.h

- This header file can be included with:

  >     #include "esp_efuse_chip.h"

- This header file is a part of the API provided by the `efuse` component. To declare that your component depends on `efuse`, add the following to your CMakeLists.txt:

  >     REQUIRES efuse

  > or

  >     PRIV_REQUIRES efuse

### Enumerations

enum esp_efuse_block_t

  Type of eFuse blocks for ESP32.

  Values:

  enumerator EFUSE_BLK0

    Number of eFuse block. Reserved.

  enumerator EFUSE_BLK1

    Number of eFuse block. Used for Flash Encryption. If not using that Flash Encryption feature, they can be used for another purpose.

  enumerator EFUSE_BLK_KEY0

    Number of eFuse block. Used for Flash Encryption. If not using that Flash Encryption feature, they can be used for another purpose.

  enumerator EFUSE_BLK_ENCRYPT_FLASH

    Number of eFuse block. Used for Flash Encryption. If not using that Flash Encryption feature, they can be used for another purpose.

  enumerator EFUSE_BLK2

    Number of eFuse block. Used for Secure Boot. If not using that Secure Boot feature, they can be used for another purpose.

  enumerator EFUSE_BLK_KEY1

    Number of eFuse block. Used for Secure Boot. If not using that Secure Boot feature, they can be used for another purpose.

  enumerator EFUSE_BLK_SECURE_BOOT

    Number of eFuse block. Used for Secure Boot. If not using that Secure Boot feature, they can be used for another purpose.

  enumerator EFUSE_BLK3

    Number of eFuse block. Uses for the purpose of the user.

  enumerator EFUSE_BLK_KEY2

    Number of eFuse block. Uses for the purpose of the user.

  enumerator EFUSE_BLK_KEY_MAX
  enumerator EFUSE_BLK_MAX

enum esp_efuse_coding_scheme_t

  Type of coding scheme.

  Values:

  enumerator EFUSE_CODING_SCHEME_NONE

    None

  enumerator EFUSE_CODING_SCHEME_3_4

    3/4 coding

  enumerator EFUSE_CODING_SCHEME_REPEAT

    Repeat coding

enum esp_efuse_purpose_t

  Type of key purpose (virtual because ESP32 has only fixed purposes for blocks)

  Values:

  enumerator ESP_EFUSE_KEY_PURPOSE_USER

    BLOCK3

  enumerator ESP_EFUSE_KEY_PURPOSE_SYSTEM

    BLOCK0

  enumerator ESP_EFUSE_KEY_PURPOSE_FLASH_ENCRYPTION

    BLOCK1

  enumerator ESP_EFUSE_KEY_PURPOSE_SECURE_BOOT_V2

    BLOCK2

  enumerator ESP_EFUSE_KEY_PURPOSE_MAX

    MAX PURPOSE

### Header File

- components/efuse/include/esp_efuse.h

- This header file can be included with:

  >     #include "esp_efuse.h"

- This header file is a part of the API provided by the `efuse` component. To declare that your component depends on `efuse`, 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.

void esp_efuse_disable_basic_rom_console(void)

  Disable BASIC ROM Console via efuse.

  By default, if booting from flash fails the ESP32 will boot a BASIC console in ROM.

  Call this function (from bootloader or app) to permanently disable the console on this chip.

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.

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_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.

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 `buf` is 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_type` requests 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_type` is 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-token`

  - Device: `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..-]

### 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

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.

Was this page helpful?

- Thank you! We received your feedback.
- If you have any comments, fill in Espressif Documentation Feedback Form.

- We value your feedback.
- Let us know how we can improve this page by filling in Espressif Documentation Feedback Form.