diff --git a/docs/en/api-reference/system/efuse.rst b/docs/en/api-reference/system/efuse.rst index fe3ad95633..6579a6d826 100644 --- a/docs/en/api-reference/system/efuse.rst +++ b/docs/en/api-reference/system/efuse.rst @@ -1,123 +1,126 @@ eFuse Manager ============= +:link_to_translation:`zh_CN:[中文]` + {IDF_TARGET_CODING_SCHEMES:default="Reed-Solomon", esp32="3/4 or Repeat"} Introduction ------------ -The eFuse Manager library is designed to structure access to eFuse bits and make using these easy. This library operates eFuse bits by a structure name which is assigned in eFuse table. This sections introduces some concepts used by eFuse Manager. +eFuse (Electronic Fuses) are microscopic one-time programmable fuses that can be "burned" (i.e., programmed) to store data into the {IDF_TARGET_NAME}. 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 {IDF_TARGET_NAME}) 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: -eFuse Manager vs idf.py ------------------------ +* 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. -idf.py provides a subset of the functionality of the eFuse Manager via the ``idf.py efuse-`` commands. In this documentation, mostly ``idf.py`` based commands will be used, although you can still see some ``espefuse.py`` based commands for advanced or rare cases. To see all available commands, run ``idf.py --help`` and search for those prefixed with ``efuse-``. +eFuse Manager vs ``idf.py`` +--------------------------- + +``idf.py`` provides a subset of the functionality of the eFuse Manager via the ``idf.py efuse-`` commands. In this documentation, mostly ``idf.py`` based commands will be used, although you can still see some ``espefuse.py`` 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 {IDF_TARGET_NAME} 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. -Some of system parameters are using these eFuse bits directly by hardware modules and have special place (for example EFUSE_BLK0). +The {IDF_TARGET_NAME} 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 **{IDF_TARGET_NAME} Technical Reference Manual** > **eFuse Controller (eFuse)** [`PDF <{IDF_TARGET_TRM_EN_URL}#efuse>`__]. Some eFuse bits are available for user applications. +For more details, see *{IDF_TARGET_NAME} Technical Reference Manual* > *eFuse Controller (eFuse)* [`PDF <{IDF_TARGET_TRM_EN_URL}#efuse>`__]. .. only:: esp32 - {IDF_TARGET_NAME} has 4 eFuse blocks each of the size of 256 bits (not all bits are available): + {IDF_TARGET_NAME} 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 encrypt key. If not using that Flash Encryption feature, they can be used for another purpose; - * EFUSE_BLK2 is used for security boot key. If not using that Secure Boot feature, they can be used for another purpose; - * EFUSE_BLK3 can be partially reserved for the custom MAC address, or used entirely for user application. Note that some bits are already used in ESP-IDF. + * 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. .. only:: not esp32 and not esp32c2 - .. list:: + {IDF_TARGET_NAME} has 11 eFuse blocks each containing 256 bits (not all bits can be used for user parameters): - {IDF_TARGET_NAME} has 11 eFuse blocks each of the size of 256 bits (not all bits are available): + .. list:: - * EFUSE_BLK0 is used entirely for system purposes; - * EFUSE_BLK1 is used entirely for system purposes; - * EFUSE_BLK2 is used entirely for system purposes; - * EFUSE_BLK3 (also named EFUSE_BLK_USER_DATA) can be used for user purposes; - * EFUSE_BLK4 (also named EFUSE_BLK_KEY0) can be used as key (for secure_boot or flash_encryption) or for user purposes; - * EFUSE_BLK5 (also named EFUSE_BLK_KEY1) can be used as key (for secure_boot or flash_encryption) or for user purposes; - * EFUSE_BLK6 (also named EFUSE_BLK_KEY2) can be used as key (for secure_boot or flash_encryption) or for user purposes; - * EFUSE_BLK7 (also named EFUSE_BLK_KEY3) can be used as key (for secure_boot or flash_encryption) or for user purposes; - * EFUSE_BLK8 (also named EFUSE_BLK_KEY4) can be used as key (for secure_boot or flash_encryption) or for user purposes; - :SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK and SOC_ECDSA_SUPPORTED: * EFUSE_BLK9 (also named EFUSE_BLK_KEY5) can be used for any purpose except for flash encryption or ECDSA (due to a HW bug); - :SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK and not SOC_ECDSA_SUPPORTED: * EFUSE_BLK9 (also named EFUSE_BLK_KEY5) can be used for any purpose except for flash encryption (due to a HW bug); - :not SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK: * EFUSE_BLK9 (also named EFUSE_BLK_KEY5) can be used as key (for secure_boot or flash_encryption) or for user purposes; - * EFUSE_BLK10 (also named EFUSE_BLK_SYS_DATA_PART2) is reserved for system purposes. + * EFUSE_BLK0 is used entirely for system parameters + * EFUSE_BLK1 is used entirely for system parameters + * EFUSE_BLK2 is used entirely for system parameters + * EFUSE_BLK3 (also named EFUSE_BLK_USER_DATA) can be used for user parameters + * EFUSE_BLK4 to EFUSE_BLK8 (also named EFUSE_BLK_KEY0 to EFUSE_BLK_KEY4) can be used to store keys for Secure Boot or Flash Encryption. If both features are unused, these blocks can be used for user parameters. + :SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK and SOC_ECDSA_SUPPORTED: * EFUSE_BLK9 (also named EFUSE_BLK_KEY5) can be used for any purpose except for Flash Encryption or ECDSA (due to a HW errata); + :SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK and not SOC_ECDSA_SUPPORTED: * EFUSE_BLK9 (also named EFUSE_BLK_KEY5) can be used for any purpose except for Flash Encryption (due to a HW errata); + :not SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK: * EFUSE_BLK9 (also named EFUSE_BLK_KEY5) can be used to store keys for Secure Boot or Flash Encryption. If both features are unused, these blocks can be used for user parameters. + * EFUSE_BLK10 (also named EFUSE_BLK_SYS_DATA_PART2) is reserved for system parameters. .. only:: esp32c2 - {IDF_TARGET_NAME} has 4 eFuse blocks each of the size of 256 bits (not all bits are available): + {IDF_TARGET_NAME} 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 entirely for system purposes; - * EFUSE_BLK2 is used entirely for system purposes; - * EFUSE_BLK3 (also named EFUSE_BLK_KEY0) can be used as key (for secure_boot or flash_encryption) or for user purposes; + * EFUSE_BLK0 is used entirely for system parameters + * EFUSE_BLK1 is used entirely for system parameters + * EFUSE_BLK2 is used entirely for system parameters + * EFUSE_BLK3 (also named EFUSE_BLK_KEY0) can be used to store keys for Secure Boot or Flash Encryption. If both features are unused, these blocks can be used for user parameters. -Each block is divided into 8 32-bits registers. +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. -eFuse Manager Component ------------------------ +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. -The component has API functions for reading and writing fields. Access to the fields is carried out through the structures that describe the location of the eFuse bits in the blocks. The component provides the ability to form fields of any length and from any number of individual bits. The description of the fields is made in a CSV file in a table form. To generate from a tabular form (CSV file) in the C-source uses the tool ``efuse_table_gen.py``. The tool checks the CSV file for uniqueness of field names and bit intersection, in case of using a `custom` file from the user's project directory, the utility checks with the `common` CSV file. +Record Format +^^^^^^^^^^^^^ -CSV files: - -* common (`esp_efuse_table.csv`) - contains eFuse fields which are used inside the ESP-IDF. C-source generation should be done manually when changing this file (run command ``idf.py efuse-common-table``). Note that changes in this file can lead to incorrect operation. -* custom - (optional and can be enabled by :ref:`CONFIG_EFUSE_CUSTOM_TABLE`) contains eFuse fields that are used by the user in their application. C-source generation should be done manually when changing this file and running ``idf.py efuse-custom-table``. - - -Description CSV File --------------------- - -The CSV file contains a description of the eFuse fields. In the simple case, one field has one line of description. -Table header: +In simple cases, each record occupies a single row in the table. Each record contains the following values (i.e., columns): {IDF_TARGET_MAX_EFUSE_BLK:default = "EFUSE_BLK10", esp32 = "EFUSE_BLK3", esp32c2 = "EFUSE_BLK3"} .. code-block:: none - # field_name, efuse_block(EFUSE_BLK0..{IDF_TARGET_MAX_EFUSE_BLK}), bit_start(0..255), bit_count(1..256), comment + # field_name, efuse_block(EFUSE_BLK0..{IDF_TARGET_MAX_EFUSE_BLK}), bit_start(0..255), bit_count(1..256), comment -Individual params in CSV file the following meanings: +- ``field_name`` -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 :ref:`structured-efuse-fields` for more details. - Name of field. The prefix `ESP_EFUSE_` is added to the name, and this field name is available in the code. This name is used to access the fields. The name must be unique for all fields. If the line has an empty name, then this line is combined with the previous field. This allows you to set an arbitrary order of bits in the field, and expand the field as well (see ``MAC_FACTORY`` field in the common table). The field_name supports structured format using `.` to show that the field belongs to another field (see ``WR_DIS`` and ``RD_DIS`` in the common table). +- ``efuse_block`` -efuse_block + - The eFuse field's block number. E.g., EFUSE_BLK0 to {IDF_TARGET_MAX_EFUSE_BLK}. + - This determines which block the eFuse field is placed. - Block number. It determines where the eFuse bits are placed for this field. Available EFUSE_BLK0..{IDF_TARGET_MAX_EFUSE_BLK}. +- ``bit_start`` -bit_start + - Bit offset (0 to 255) of the eFuse within the block. + - ``bit_start`` is optional and can be omitted. - Start bit number (0..255). The bit_start field can be omitted. In this case, it is set to bit_start + bit_count from the previous record, if it has the same efuse_block. Otherwise (if efuse_block is different, or this is the first entry), an error will be generated. + - 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. -.. only:: esp32 +- ``bit_count`` - 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. - The number of bits to use in this field (1..-). This parameter cannot be omitted. This field also may be ``MAX_BLK_LEN`` in this case, the field length has the maximum block length, taking into account the coding scheme (applicable for ``ESP_EFUSE_SECURE_BOOT_KEY`` and ``ESP_EFUSE_ENCRYPT_FLASH_KEY`` fields). The value ``MAX_BLK_LEN`` depends on :ref:`CONFIG_EFUSE_CODE_SCHEME_SELECTOR`, which will be replaced with "None" - 256, "3/4" - 192, "REPEAT" - 128. + .. only:: esp32 -.. only:: not esp32 + - ``MAX_BLK_LEN`` takes into account the coding scheme of eFuse. + - Depending on the coding scheme selected via :ref:`CONFIG_EFUSE_CODE_SCHEME_SELECTOR`, ``MAX_BLK_LEN`` could be 256 ("None"), 192 ("3/4"), or 128 ("REPEAT"). - bit_count +- ``comment`` - The number of bits to use in this field (1..-). This parameter cannot be omitted. This field also may be ``MAX_BLK_LEN`` in this case, the field length has the maximum block length. + - Comment describing the eFuse field. + - The comment is copied verbatim into the C header file. -comment +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. - This param is using for comment field, it also move to C-header file. The comment field can be omitted. - -If a non-sequential bit order is required to describe a field, then the field description in the following lines should be continued without specifying a name, indicating that it belongs to one field. For example two fields ``MAC_FACTORY`` and ``MAC_FACTORY_CRC``: +The following example demonstrates the records to specify the non-sequential eFuse field ``MAC_FACTORY`` followed by a regular eFuse field ``MAC_FACTORY_CRC``: .. code-block:: none @@ -131,13 +134,19 @@ If a non-sequential bit order is required to describe a field, then the field de , EFUSE_BLK0, 32, 8, Factory MAC addr [5] MAC_FACTORY_CRC, EFUSE_BLK0, 80, 8, CRC8 for factory MAC address -This field is available in code as ``ESP_EFUSE_MAC_FACTORY`` and ``ESP_EFUSE_MAC_FACTORY_CRC``. +This eFuse fields will be made available in C code as ``ESP_EFUSE_MAC_FACTORY`` and ``ESP_EFUSE_MAC_FACTORY_CRC``. .. _structured-efuse-fields: 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: + .. code-block:: none WR_DIS, EFUSE_BLK0, 0, 32, Write protection @@ -150,56 +159,65 @@ Structured eFuse Fields 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 -The structured eFuse field looks like ``WR_DIS.RD_DIS`` where the dot points that this field belongs to the parent field - ``WR_DIS`` and cannot be out of the parent's range. +Some things to note regarding the example above: -It is possible to use some levels of structured fields as WR_DIS.FIELD_2.B1 and B2. These fields should not be crossed each other and should be in the range of two fields: ``WR_DIS`` and ``WR_DIS.FIELD_2``. +* 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: -It is possible to create aliases for fields with the same range, see ``WR_DIS.FIELD_3`` and ``WR_DIS.FIELD_3.ALIAS``. + * 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). -The ESP-IDF names for structured eFuse fields should be unique. The ``efuse_table_gen`` tool generates the final names where the dot is replaced by ``_``. The names for using in ESP-IDF are ESP_EFUSE_WR_DIS, ESP_EFUSE_WR_DIS_RD_DIS, ESP_EFUSE_WR_DIS_FIELD_2_B1, etc. +* 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. -The ``efuse_table_gen`` tool checks that the fields do not overlap each other and must be within the range of a field if there is a violation, then throws the following error: +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: .. code-block:: none - Field at USER_DATA, EFUSE_BLK3, 0, 256 intersected with SERIAL_NUMBER, EFUSE_BLK3, 0, 32 + Field at USER_DATA, EFUSE_BLK3, 0, 256 intersected with SERIAL_NUMBER, EFUSE_BLK3, 0, 32 -Solution: Describe ``SERIAL_NUMBER`` to be included in ``USER_DATA``. (``USER_DATA.SERIAL_NUMBER``). +In this case, the error can be resolved by making ``SERIAL_NUMBER`` a child field of ``USER_DATA`` via ``USER_DATA.SERIAL_NUMBER``. .. code-block:: none - Field at FIELD, EFUSE_BLK3, 0, 50 out of range FIELD.MAJOR_NUMBER, EFUSE_BLK3, 60, 32 + Field at FIELD, EFUSE_BLK3, 0, 50 out of range FIELD.MAJOR_NUMBER, EFUSE_BLK3, 60, 32 -Solution: Change ``bit_start`` for ``FIELD.MAJOR_NUMBER`` from 60 to 0, so ``MAJOR_NUMBER`` is in the ``FIELD`` range. +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 tool is designed to generate C-source files from CSV file and validate fields. First of all, the check is carried out on the uniqueness of the names and overlaps of the field bits. If an additional `custom` file is used, it will be checked with the existing `common` file (esp_efuse_table.csv). In case of errors, a message will be displayed and the string that caused the error. C-source files contain structures of type `esp_efuse_desc_t`. +The ``efuse_table_gen.py`` tool is designed to generate C source files containing C structures (of type :cpp: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: -To generate a `common` files, use the following command ``idf.py efuse-common-table`` or: +- 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 {IDF_TARGET_NAME}, 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: .. code-block:: bash cd $IDF_PATH/components/efuse/ ./efuse_table_gen.py --idf_target {IDF_TARGET_PATH_NAME} {IDF_TARGET_PATH_NAME}/esp_efuse_table.csv -After generation in the folder $IDF_PATH/components/efuse/`{IDF_TARGET_PATH_NAME}` create: +The following C source/header files will be generated by the tool in ``$IDF_PATH/components/efuse/{IDF_TARGET_PATH_NAME}``: -* `esp_efuse_table.c` file. -* In `include` folder `esp_efuse_table.c` file. +* ``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 a `custom` files, use the following command ``idf.py efuse-custom-table`` or: +To generate C source files using a **custom** CSV file, use the command ``idf.py efuse-custom-table`` or the following: .. code-block:: bash cd $IDF_PATH/components/efuse/ ./efuse_table_gen.py --idf_target {IDF_TARGET_PATH_NAME} {IDF_TARGET_PATH_NAME}/esp_efuse_table.csv PROJECT_PATH/main/esp_efuse_custom_table.csv -After generation in the folder PROJECT_PATH/main create: +The following C source/header files will be generated by the tool in ``PROJECT_PATH/main``: -* `esp_efuse_custom_table.c` file. -* In `include` folder `esp_efuse_custom_table.c` file. +* ``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: @@ -209,56 +227,101 @@ To use the generated fields, you need to include two files: #include "esp_efuse_table.h" // or "esp_efuse_custom_table.h" -Supported Coding Scheme ------------------------ +Supported Coding Schemes +------------------------ + +Various coding schemes are supported by eFuses which can protect eFuses against data corruption by detecting and/or correcting for errors. .. only:: esp32 - eFuse have three coding schemes: + {IDF_TARGET_NAME} supports the following eFuse coding schemes: - * ``None`` (value 0). + * ``None`` (value 0), meaning no coding scheme is applied. * ``3/4`` (value 1). - * ``Repeat`` (value 2). + * ``Repeat`` (value 2). It is not entirely supported by IDF, not recommended for use. - The coding scheme affects only EFUSE_BLK1, EFUSE_BLK2 and EFUSE_BLK3 blocks. EUSE_BLK0 block always has a coding scheme ``None``. - Coding changes the number of bits that can be written into a block, the block length is constant 256, some of these bits are used for encoding and not available for the user. + 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. - When using a coding scheme, the length of the payload that can be written is limited (for more details ``20.3.1.3 System Parameter 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 bits. - * 3/4 192 bits. - * Repeat 128 bits. + * ``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 *{IDF_TARGET_NAME} Technical Reference Manual* > *Chapter 20 eFuse Controller* [`PDF <{IDF_TARGET_TRM_EN_URL}#efuse>`__] > *Section 20.3.1.3 System Parameter coding_scheme*. You can find out the coding scheme of your chip: - * run a ``idf.py efuse-summary`` command. + * run the ``idf.py efuse-summary`` command. * from ``esptool`` utility logs (during flashing). - * calling the function in the code :cpp:func:`esp_efuse_get_coding_scheme` for the EFUSE_BLK3 block. + * calling the function :cpp:func:`esp_efuse_get_coding_scheme` in the application for the EFUSE_BLK3 block. - eFuse tables must always comply with the coding scheme in the chip. There is an :ref:`CONFIG_EFUSE_CODE_SCHEME_SELECTOR` option to select the coding type for tables in a Kconfig. When generating source files, if your tables do not follow the coding scheme, an error message will be displayed. Adjust the length or offset fields. - If your program was compiled with ``None`` encoding and ``3/4`` is used in 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. + The eFuse fields specified in the CSV files must always comply with the eFuse coding scheme used by the chip. The :ref:`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. - Also, 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, and 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. + .. note:: - It turns out that only one field can be written into one coding unit. Repeated rewriting in one coding unit is prohibited. But if the record was made in advance or through a :cpp:func:`esp_efuse_write_block` function, then reading the fields belonging to one coding unit is possible. + After changing the coding scheme, run ``efuse_common_table`` and ``efuse_custom_table`` commands to check the tables of the new coding scheme. - In case ``3/4`` coding scheme, the writing process is divided into the coding units and we cannot use the usual mode of writing some fields. We can prepare all the data for writing and burn it in one time. You can also use this mode for ``None`` coding scheme but it is not necessary. It is important for ``3/4`` coding scheme. - ``The batch writing mode`` blocks ``esp_efuse_read_...`` operations. + 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. - After changing the coding scheme, run ``efuse_common_table`` and ``efuse_custom_table`` commands to check the tables of the new coding scheme. + ``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 :cpp:func:`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. .. only:: not esp32 - Coding schemes are used to protect against data corruption. {IDF_TARGET_NAME} supports two coding schemes: + {IDF_TARGET_NAME} does not support selection of coding schemes. The following coding schemes are automatically applied to various eFuse blocks: - * ``None``. EFUSE_BLK0 is stored with four backups, meaning each bit is stored four times. This backup scheme is automatically applied by the hardware and is not visible to software. EFUSE_BLK0 can be written many times. - * ``RS``. EFUSE_BLK1 - {IDF_TARGET_MAX_EFUSE_BLK} use Reed-Solomon coding scheme that supports up to 5 bytes of automatic error correction. Software encodes the 32-byte EFUSE_BLKx using RS (44, 32) to generate a 12-byte check code, and then burn the EFUSE_BLKx and the check code into eFuse at the same time. The eFuse Controller automatically decodes the RS encoding and applies error correction when reading back the eFuse block. Because the RS check codes are generated across the entire 256-bit eFuse block, each block can only be written to one time. + * ``None``: Applied to EFUSE_BLK0 + * ``RS``: Applied to EFUSE_BLK1 - {IDF_TARGET_MAX_EFUSE_BLK} -To write some fields into one block, or different blocks in one time, you need to use ``the batch writing mode``. Firstly set this mode through :cpp:func:`esp_efuse_batch_write_begin` function then write some fields as usual using the ``esp_efuse_write_...`` functions. At the end to burn them, call the :cpp:func:`esp_efuse_batch_write_commit` function. It burns prepared data to the eFuse blocks and disables the ``batch recording mode``. + ``None`` Coding Scheme + ^^^^^^^^^^^^^^^^^^^^^^ -.. note:: + The ``None`` coding scheme is automatically applied to EFUSE_BLK0. This scheme does not involve any encoding, but simply maintains four backups of EFUSE_BLK0 in hardware, meaning each bit is stored four times. As a result, EFUSE_BLK0 can be written many times. - If there is already pre-written data in the eFuse block using the ``{IDF_TARGET_CODING_SCHEMES}`` encoding scheme, then it is not possible to write anything extra (even if the required bits are empty) without breaking the previous encoding data. This encoding data will be overwritten with new encoding data and completely destroyed (however, the payload eFuses are not damaged). It can be related to: CUSTOM_MAC, SPI_PAD_CONFIG_HD, SPI_PAD_CONFIG_CS, etc. Please contact Espressif to order the required pre-burnt eFuses. + This scheme is automatically applied by the hardware and is not visible to software. + + ``RS`` Coding Scheme + ^^^^^^^^^^^^^^^^^^^^^^ + + The ``RS`` coding scheme uses Reed-Solomon encoding and is automatically applied to EFUSE_BLK1 to {IDF_TARGET_MAX_EFUSE_BLK}. The coding scheme supports up to 6 bytes of automatic error correction. + + Software encodes the 32-byte EFUSE_BLKx using ``RS(44, 32)`` to generate a 12-byte check-symbols, and then burn the EFUSE_BLKx and the check-symbols into eFuse at the same time. + + The eFuse Controller automatically decodes the ``RS`` encoding and applies error correction when reading back the eFuse block. Because the ``RS`` check-symbols are generated across the entire 256-bit eFuse block, each block can only be written to one time. As a result of the check-symbols, Batch Writing Mode must be used. + +Batch Writing Mode +^^^^^^^^^^^^^^^^^^ + +When writing to eFuse fields at run time, it may be necessary to use the Batch Writing Mode depending on the coding scheme used for eFuse block. Batch writing mode can be used as follows: + +#. Enable batch writing mode by calling :cpp:func:`esp_efuse_batch_write_begin` +#. Write to the eFuse fields as usual using various ``esp_efuse_write_...`` functions. +#. Once all writes are complete, call :cpp:func:`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 ``{IDF_TARGET_CODING_SCHEMES}`` 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. @@ -277,8 +340,8 @@ Access to the fields is via a pointer to the description structure. API function * :cpp:func:`esp_efuse_read_reg` - returns value of eFuse register. * :cpp:func:`esp_efuse_write_reg` - writes value to eFuse register. * :cpp:func:`esp_efuse_get_coding_scheme` - returns eFuse coding scheme for blocks. -* :cpp:func:`esp_efuse_read_block` - reads key to eFuse block starting at the offset and the required size. -* :cpp:func:`esp_efuse_write_block` - writes key to eFuse block starting at the offset and the required size. +* :cpp:func:`esp_efuse_read_block` - reads a key from an eFuse block starting at the offset with required size. +* :cpp:func:`esp_efuse_write_block` - writes a key to an eFuse block starting at the offset with required size. * :cpp:func:`esp_efuse_batch_write_begin` - set the batch mode of writing fields. * :cpp:func:`esp_efuse_batch_write_commit` - writes all prepared data for batch writing mode and reset the batch writing mode. * :cpp:func:`esp_efuse_batch_write_cancel` - reset the batch writing mode and prepared data. @@ -287,12 +350,12 @@ Access to the fields is via a pointer to the description structure. API function * :cpp:func:`esp_efuse_get_key_dis_write` - Returns a write protection for the key block. * :cpp:func:`esp_efuse_set_key_dis_write` - Sets a write protection for the key block. * :cpp:func:`esp_efuse_get_key_purpose` - Returns the current purpose set for an eFuse key block. -* :cpp:func:`esp_efuse_write_key` - Programs a block of key data to an eFuse block -* :cpp:func:`esp_efuse_write_keys` - Programs keys to unused eFuse blocks +* :cpp:func:`esp_efuse_write_key` - Programs a block of key data to an eFuse block. +* :cpp:func:`esp_efuse_write_keys` - Programs keys to unused eFuse blocks. * :cpp:func:`esp_efuse_find_purpose` - Finds a key block with the particular purpose set. * :cpp:func:`esp_efuse_get_keypurpose_dis_write` - Returns a write protection of the key purpose field for an eFuse key block (for esp32 always true). * :cpp:func:`esp_efuse_key_block_unused` - Returns true if the key block is unused, false otherwise. -* :cpp:func:`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. +* :cpp:func:`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. For frequently used fields, special functions are made, like this :cpp:func:`esp_efuse_get_pkg_ver`. @@ -309,14 +372,14 @@ For frequently used fields, special functions are made, like this :cpp:func:`esp The purposes like ``ESP_EFUSE_KEY_PURPOSE_SECURE_BOOT_DIGEST...`` are used for secure boot. - There are some eFuse APIs useful to work with states of keys. + There are some eFuse APIs useful to work with states of keys: * :cpp:func:`esp_efuse_get_purpose_field` - Returns a pointer to a key purpose for an eFuse key block. * :cpp:func:`esp_efuse_get_key` - Returns a pointer to a key block. * :cpp:func:`esp_efuse_set_key_purpose` - Sets a key purpose for an eFuse key block. * :cpp:func:`esp_efuse_set_keypurpose_dis_write` - Sets a write protection of the key purpose field for an eFuse key block. * :cpp:func:`esp_efuse_find_unused_key_block` - Search for an unused key block and return the first one found. - * :cpp:func:`esp_efuse_count_unused_key_blocks` - Returns the number of unused eFuse key blocks in the range EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX + * :cpp:func:`esp_efuse_count_unused_key_blocks` - Returns the number of unused eFuse key blocks in the range EFUSE_BLK_KEY0 to EFUSE_BLK_KEY_MAX .. only:: SOC_SUPPORT_SECURE_BOOT_REVOKE_KEY @@ -329,13 +392,13 @@ For frequently used fields, special functions are made, like this :cpp:func:`esp How to Add a New Field ---------------------- -1. Find a free bits for field. Show `esp_efuse_table.csv` file or run ``idf.py show-efuse-table`` or the next command: +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: .. include:: inc/show-efuse-table_{IDF_TARGET_NAME}.rst -The number of bits not included in square brackets is free (some bits are reserved for Espressif). All fields are checked for overlapping. +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 fields to an existing field, use the :ref:`Structured efuse fields ` technique. For example, adding the fields: SERIAL_NUMBER, MODEL_NUMBER and HARDWARE REV to an existing ``USER_DATA`` field. Use ``.`` (dot) to show an attachment in a field. +To add child fields to an existing field, :ref:`structured-efuse-fields` can be used. The following example demonstrates adding of the the fields ``SERIAL_NUMBER``, ``MODEL_NUMBER`` and ``HARDWARE_REV`` to an existing ``USER_DATA`` field by using the ``.`` operator: .. code-block:: none @@ -343,16 +406,18 @@ To add fields to an existing field, use the :ref:`Structured efuse fields ` article. +You may get errors such as ``intersects with`` or ``out of range``. Please see how to solve them in the :ref:`structured-efuse-fields` article. Bit Order --------- -The eFuses bit order is little endian (see the example below), it means that eFuse bits are read and written from LSB to MSB: +The eFuses bit order is little endian (see the example below), meaning that eFuse bits are read and written from LSB to MSB: .. code-block:: none @@ -376,7 +441,7 @@ The eFuses bit order is little endian (see the example below), it means that eFu 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). +For example, CSV file describes the ``USER_DATA`` field, which occupies all 256 bits (a whole block). .. code-block:: none @@ -406,7 +471,7 @@ Thus, reading the eFuse ``USER_DATA`` block written as above gives the following 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. + // 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 @@ -417,15 +482,16 @@ Thus, reading the eFuse ``USER_DATA`` block written as above gives the following // 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: +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.py 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. +* ``espefuse_get_json_summary()`` - It calls the ``espefuse.py 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: +The JSON string has the following properties: .. code-block:: json @@ -472,25 +538,33 @@ Debug eFuse & Unit Tests Virtual eFuses ^^^^^^^^^^^^^^ -The Kconfig option :ref:`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 app and unit tests. +The Kconfig option :ref:`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 :ref:`CONFIG_EFUSE_VIRTUAL` option there is :ref:`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 the `efuse` partition. partition.csv: ``"efuse_em, data, efuse, , 0x2000,"``. -During startup, the eFuses are copied from flash or, in case if flash is empty, from real eFuse to RAM and then update flash. This option allows keeping eFuses after reboots (possible to test secure_boot and flash_encryption features with this option). +In addition to the :ref:`CONFIG_EFUSE_VIRTUAL` option, there is the :ref:`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``: + +.. code-block:: none + + 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 (FE) is a hardware feature that requires the physical burning of eFuses: key and FLASH_CRYPT_CNT. If FE is not actually enabled then enabling the :ref:`CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH` option just gives testing possibilities and does not encrypt anything in the flash, even though the logs say encryption happens. The :cpp:func:`bootloader_flash_write` is adapted for this purpose. But if FE is already enabled on the chip and you run an application or bootloader created with the :ref:`CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH` option then the flash encryption/decryption operations will work properly (data are encrypted as it is written into an encrypted flash partition and decrypted when they are read from an encrypted partition). +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 :ref:`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 :cpp:func:`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 :ref:`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.py`` ^^^^^^^^^^^^^^^ esptool includes a useful tool for reading/writing {IDF_TARGET_NAME} eFuse bits - `espefuse.py `_. + 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.py summary``. .. include:: inc/espefuse_summary_{IDF_TARGET_NAME}.rst - .. include-build-file:: inc/esp_efuse_chip.inc .. include-build-file:: inc/esp_efuse.inc diff --git a/docs/zh_CN/api-reference/system/efuse.rst b/docs/zh_CN/api-reference/system/efuse.rst index eacf036995..7beb1e600f 100644 --- a/docs/zh_CN/api-reference/system/efuse.rst +++ b/docs/zh_CN/api-reference/system/efuse.rst @@ -1 +1,570 @@ -.. include:: ../../../en/api-reference/system/efuse.rst +eFuse 管理器 +============= + +:link_to_translation:`en:[English]` + +{IDF_TARGET_CODING_SCHEMES:default="Reed-Solomon", esp32="3/4 或 Repeat"} + + +简介 +------------ + +eFuse 是一种微型的一次性可编程保险丝，可以通过“烧录”（即编程）将数据存储到 {IDF_TARGET_NAME} 中。eFuse 位组成不同的数据字段，用于系统参数（即 {IDF_TARGET_NAME} 的 ESP-IDF 使用的数据参数）或用户自定义参数。 + +eFuse 管理器组件中集合了多种工具和 API，可帮助定义、烧录和访问 eFuse 参数。常用的工具和 API 包括： + +* 表格格式，用于在 CSV 文件中定义 eFuse 数据字段 +* ``efuse_table_gen.py`` 工具，用于生成 CSV 文件指定的 eFuse 数据字段对应的 C 结构体 +* 用于读/写 eFuse 数据字段的 C API 集合 + +eFuse Manager 与 ``idf.py`` +--------------------------- + +``idf.py`` 通过 ``idf.py efuse-`` 命令为 eFuse 管理器提供了部分功能。本文档主要使用基于 ``idf.py`` 的命令，只有在涉及高级功能或罕见情况时，会使用基于 ``espefuse.py`` 的命令。要查看所有可用的命令，请运行 ``idf.py --help`` 并搜索以 ``efuse-`` 为前缀的命令。 + +硬件描述 +-------------------- + +{IDF_TARGET_NAME} 有多个 eFuse，可用于存储系统参数和用户参数。每个 eFuse 都是一个一位字段，可以烧写为 1，之后就不能再恢复为 0。eFuse 位被分成了多个 256 位的块，每个块又被分成 8 个 32 位寄存器。部分块保留用于系统参数，其它块可用于用户参数。 + +如需了解更多内容，请参阅 *{IDF_TARGET_NAME} 技术参考手册* > *eFuse 控制器 (eFuse)* [`PDF <{IDF_TARGET_TRM_CN_URL}#efuse>`__]。 + +.. only:: esp32 + + {IDF_TARGET_NAME} 有 4 个 eFuse 块，每个块的大小为 256 位（并非所有位都可用于用户参数）： + + * EFUSE_BLK0 完全用于系统用途； + * EFUSE_BLK1 用于 flash 加密密钥。如果不使用 flash 加密功能，此块也可以用于用户参数； + * EFUSE_BLK2 用于安全启动密钥。如果不使用安全启动功能，此块也可以用于用户参数； + * EFUSE_BLK3 可以部分保留，以存储自定义 MAC 地址，或者完全用于用户参数。请注意，一些位已经用于 ESP-IDF。 + +.. only:: not esp32 and not esp32c2 + + {IDF_TARGET_NAME} 有 11 个 eFuse 块，每个块的大小为 256 位（并非所有位都可用于用户参数）： + + .. list:: + + * EFUSE_BLK0 完全用于系统参数； + * EFUSE_BLK1 完全用于系统参数； + * EFUSE_BLK2 完全用于系统参数； + * EFUSE_BLK3（也称为 EFUSE_BLK_USER_DATA）可用于用户参数； + * EFUSE_BLK4 至 EFUSE_BLK8（即 EFUSE_BLK_KEY0 至 EFUSE_BLK_KEY4）可以存储安全启动或 flash 加密的密钥。不使用这两个功能时，可以用于用户参数。 + :SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK and SOC_ECDSA_SUPPORTED: * EFUSE_BLK9（即 EFUSE_BLK_KEY5）可用于任何用途，但由于硬件问题，不能用于 flash 加密或 ECDSA； + :SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK and not SOC_ECDSA_SUPPORTED: * EFUSE_BLK9（即 EFUSE_BLK_KEY5）可用于任何用途，但由于硬件问题，不能用于 flash 加密； + :not SOC_EFUSE_BLOCK9_KEY_PURPOSE_QUIRK: * EFUSE_BLK9（即 EFUSE_BLK_KEY5）可用于存储安全启动或 flash 加密的密钥。不使用这两个功能时，可用于用户参数。 + * EFUSE_BLK10（即 EFUSE_BLK_SYS_DATA_PART2）保留用于系统参数。 + +.. only:: esp32c2 + + {IDF_TARGET_NAME} 有 4 个 eFuse 块，每个块的大小为 256 位（并非所有位都可用于用户参数）： + + * EFUSE_BLK0 完全用于系统参数 + * EFUSE_BLK1 完全用于系统参数 + * EFUSE_BLK2 完全用于系统参数 + * EFUSE_BLK3（即 EFUSE_BLK_KEY0）可用于存储安全启动或 flash 加密的密钥。不使用这两个功能时，可用于用户参数。 + +定义 eFuse 字段 +----------------------- + +eFuse 字段通过 CSV 文件中特定格式的表格进行定义。通过这种格式，可定义任意长度和任意位数的 eFuse 字段。 + +另外，通过这种格式，可以结构化地定义由子字段组成的 eFuse 字段，这意味着一个父 eFuse 字段可能由占用相同 eFuse 位的多个子 eFuse 字段组成。 + +定义格式 +^^^^^^^^^^^^^^^^^^ + +一般情况下，每个记录在定义表格中占据一行，每行包含以下值（也就是列）： + +{IDF_TARGET_MAX_EFUSE_BLK:default = "EFUSE_BLK10", esp32 = "EFUSE_BLK3", esp32c2 = "EFUSE_BLK3"} + +.. code-block:: none + + # field_name, efuse_block(EFUSE_BLK0..{IDF_TARGET_MAX_EFUSE_BLK}), bit_start(0..255), bit_count(1..256), comment + +- ``field_name`` + + - eFuse 字段的名称。 + - 字段名称前会自动添加 ``ESP_EFUSE_`` 前缀，在 C 代码中，可通过此名称来访问 eFuse 字段。 + - 对于每个 eFuse 字段，``field_name`` 必须唯一。 + - 如果此值为空，说明该行与前一行合并。这样就可以定义任意位排序的 eFuse 字段（例如通用表中的 ``MAC_FACTORY`` 字段）。 + - 使用 ``.`` 来定义一个子 eFuse 字段。详情请参考 :ref:`structured-efuse-fields`。 + +- ``efuse_block`` + + - eFuse 字段的块号。例如 EFUSE_BLK0 到 {IDF_TARGET_MAX_EFUSE_BLK}。 + - 这一字段决定了 eFuse 字段在哪个块中。 + +- ``bit_start`` + + - eFuse 字段在块内的位置偏移（0 至 255 位）。 + - ``bit_start`` 是可选项，可省略。 + + - 当省略时，如果上一条记录位于同一个 eFuse 块中，``bit_start`` 会被设置为上一条记录的 ``bit_start + bit_count``。 + - 如果上一条记录位于不同的 eFuse 块中，则会报错。 + +- ``bit_count`` + + - eFuse 字段的大小，以位为单位（1 至 N）。 + - ``bit_count`` 不能省略 + - 如将其设置为 ``MAX_BLK_LEN``，则此 eFuse 字段为块中允许的最大 eFuse 字段大小。 + + .. only:: esp32 + + - ``MAX_BLK_LEN`` 考虑了 eFuse 的编码方案。 + - 根据 :ref:`CONFIG_EFUSE_CODE_SCHEME_SELECTOR` 选择的编码方案，``MAX_BLK_LEN`` 可能是 256("None")、192 ("3/4") 或 128 ("REPEAT") 位。 + +- ``comment`` + + - 描述 eFuse 字段的注释。 + - 此注释会逐字复制到 C 头文件中。 + +如果一个 eFuse 字段需要非顺序位序，那么该 eFuse 字段将占用多行。应在第一行的 ``field_name`` 处定该 eFuse 字段的名称，并且将其他行的 ``field_name`` 留空。这样就表明这些行属于同一个 eFuse 字段。 + +以下示例中定义了两个 eFuse 字段。首先定义非连续的 eFuse 字段 ``MAC_FACTORY``，然后定义了常规 eFuse 字段 ``MAC_FACTORY_CRC``： + +.. code-block:: none + + # 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 + +在 C 代码中，可以通过 ``ESP_EFUSE_MAC_FACTORY`` 和 ``ESP_EFUSE_MAC_FACTORY_CRC`` 使用这两个字段。 + +.. _structured-efuse-fields: + +结构化 eFuse 字段 +----------------------- + +通常情况下，一个 eFuse 字段代表一个特定的参数。不过，在某些情况下，一个 eFuse 字段可能由多个子字段组成，因此有必要隔离访问这些子字段。例如，如果一个 eFuse 字段包含一个浮点参数，则可以将浮点的符号、指数和尾数字段作为单独的 eFuse 字段进行访问。 + +因此，可以在 ``field_name`` 中使用 ``.`` 操作符，以结构化的方式定义 eFuse 字段。例如，``XX.YY.ZZ`` 定义了一个 eFuse 字段 ``ZZ``，它是 eFuse 字段 ``YY`` 的子字段，而 ``YY`` 又是 eFuse 字段 ``XX`` 的子字段。 + +以下示例展示了如何以定义结构化 eFuse 字段： + +.. code-block:: none + + 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 + +在上例中可以看出： + +* ``WR_DIS`` 为父 eFuse 字段。其他所有行的 ``field_name`` 都具有 ``WR_DIS.`` 前缀，因此都是 ``WR_DIS`` 的子字段。 +* 子字段必须与父字段使用相同的位。注意子字段和父字段的 ``bit_start`` 和 ``bit_count``： + + * 子字段的位总是在其父字段范围内。例如，``WR_DIS.RD_DIS`` 和 ``WR_DIS.RD_DIS`` 占用了 ``WR_DIS`` 的第一位和第二位。 + * 子字段使用的位不能重叠（子字段有别名时除外）。 + +* 可以将别名创建为子字段。例如，``WR_DIS.FIELD_3.ALIAS`` 既是 ``WR_DIS.FIELD_3`` 的子字段，又是别名，因为它们占用的位相同。 + +所有 eFuse 字段最终都会通过 ``efuse_table_gen.py`` 工具转换为 C 结构体。每个 C 结构体从 eFuse 字段的 ``field_name`` 中衍生出标识符，并用 ``_`` 替换所有的 ``.`` 符号。以 ``WR_DIS.RD_DIS`` 和 ``WR_DIS.FIELD_2.B1`` 为例，这两个 eFuse 字段用 C 语言分别表示为 ``ESP_EFUSE_WR_DIS_RD_DIS`` 和 ``ESP_EFUSE_WR_DIS_FIELD_2_B1``。 + +``efuse_table_gen.py`` 工具还会检查字段是否相互重叠并在字段范围内。如有违反，会生成以下错误： + +.. code-block:: none + + Field at USER_DATA, EFUSE_BLK3, 0, 256 intersected with SERIAL_NUMBER, EFUSE_BLK3, 0, 32 + +要解决此问题，可使用 ``USER_DATA.SERIAL_NUMBER``，让 ``SERIAL_NUMBER`` 成为 ``USER_DATA`` 的子字段。 + +.. code-block:: none + + Field at FIELD, EFUSE_BLK3, 0, 50 out of range FIELD.MAJOR_NUMBER, EFUSE_BLK3, 60, 32 + +要解决此问题，可将 ``FIELD.MAJOR_NUMBER`` 的 ``bit_start`` 从 ``60`` 改为 ``0``，使 ``MAJOR_NUMBER`` 与 ``FIELD`` 重叠。 + +``efuse_table_gen.py`` 工具 +--------------------------- + +``efuse_table_gen.py`` 工具能够从 CSV 文件生成 C 源文件，其中包含 CSV 文件中定义的 eFuse 字段的对应 C 结构体（类型为 :cpp:type:`esp_efuse_desc_t`）。此外，该工具还会在生成 C 源文件前对 CSV 文件进行检查，以确保： + +- eFuse 字段的名称唯一 +- eFuse 字段使用的位不重叠 + +如前所述，eFuse 字段可用于存储系统参数或用户参数。由于系统参数 eFuse 字段是 ESP-IDF 和 {IDF_TARGET_NAME} 的内在要求，这些 eFuse 字段被定义在 **通用** CSV 文件中，即 ``esp_efuse_table.csv`` 中，是 ESP-IDF 的一部分。对于用户参数 eFuse 字段，用户应在 **自定义** CSV 文件（如 ``esp_efuse_custom_table.csv``）中进行定义。 + +要从 **通用** CSV 文件生成 C 源文件，运行 ``idf.py efuse-common-table`` 或以下命令： + +.. code-block:: bash + + cd $IDF_PATH/components/efuse/ + ./efuse_table_gen.py --idf_target {IDF_TARGET_PATH_NAME} {IDF_TARGET_PATH_NAME}/esp_efuse_table.csv + +然后，就会在路径 ``$IDF_PATH/components/efuse/{IDF_TARGET_PATH_NAME}`` 中生成以下 C 源文件/头文件： + +* ``esp_efuse_table.c`` 文件，包含系统参数 eFuse 字段的 C 结构体。 +* ``esp_efuse_table.h`` 文件，位于 ``include`` 文件夹。应用程序可包含该头文件，以使用上述 C 结构体。 + +要使用 **自定义** CSV 文件生成 C 源文件，请运行 ``idf.py efuse-custom-table`` 或以下命令： + +.. code-block:: bash + + cd $IDF_PATH/components/efuse/ + ./efuse_table_gen.py --idf_target {IDF_TARGET_PATH_NAME} {IDF_TARGET_PATH_NAME}/esp_efuse_table.csv PROJECT_PATH/main/esp_efuse_custom_table.csv + +然后在 ``PROJECT_PATH/main`` 路径下生成 C 源/头文件： + +* ``esp_efuse_custom_table.c`` 文件，包含用户参数 eFuse 字段的 C 结构体。 +* ``esp_efuse_custom_table.h`` 文件，位于 ``include`` 文件夹。应用程序可包含该头文件，以使用上述 C 结构体。 + +要使用生成的字段，需添加以下头文件： + +.. code-block:: c + + #include "esp_efuse.h" + #include "esp_efuse_table.h" // 或 "esp_efuse_custom_table.h" + + +支持的编码方式 +----------------------- + +eFuse 支持各种编码方式，能够检测或纠正错误，保护 eFuse 数据不受损坏。 + +.. only:: esp32 + + {IDF_TARGET_NAME} 支持以下 eFuse 编码方式： + + * ``非编码`` 方式（值为 0），即不采用编码方式。 + * ``3/4 编码`` 方式（值为 1）。 + * ``重复编码`` 方式（值为 2）。不完全受到 IDF 支持，不推荐使用。 + + 以上编码方案对每个 eFuse 块进行单独编码。此外，只有 EFUSE_BLK1、EFUSE_BLK2 和 EFUSE_BLK3 将被编码，这意味着 EUSE_BLK0 始终采用 ``非编码`` 方式。 + + 编码方案要求将 eFuse 块中的某些位用作开销。因此，采用编码方案后，每个 eFuse 块的 256 位中只有一部分可用于 eFuse 字段。 + + * ``非编码``：256 位 + * ``3/4 编码``：192 位 + * ``重复编码``：128 位 + + 当使用一种编码方式时，可以写入的有效载荷长度是有限的。如需了解更多内容，请参考 *{IDF_TARGET_NAME} 技术参考手册* > *章节 20 eFuse 控制器 (eFuse)* [`PDF <{IDF_TARGET_TRM_CN_URL}#efuse>`__] > *章节 20.3.1.3 系统参数 coding_scheme*。 + + 通过以下步骤查看芯片的编码方式： + + * 运行 ``idf.py efuse-summary`` 命令。 + * 在烧录期间从 ``esptool`` 应用程序日志中查看。 + * 在应用程序中调用 :cpp:func:`esp_efuse_get_coding_scheme` 函数查看 EFUSE_BLK3 块的编码方式。 + + CSV 文件中指定的 eFuse 字段必须始终符合芯片使用的 eFuse 编码方案。可以通过 :ref:`CONFIG_EFUSE_CODE_SCHEME_SELECTOR` 选择 CSV 文件使用的编码方案。生成源文件时，如果 CSV 文件中的内容不符合编码方案，则会显示错误信息。在这种情况下，必须调整错误行的 ``bit_start`` 和 ``bit_count``，以满足所选编码方案的限制。 + + .. note:: + + 更改编码方式后，运行 ``efuse_common_table`` 和 ``efuse_custom_table`` 命令以查看采用新编码方式的 CSV 表格。 + + 如果程序是用 ``非编码`` 方式编译的，而芯片中使用的是 ``3/4 编码`` 方式，那么调用 eFuse API 时可能会出现 ``ESP_ERR_CODING`` 错误（字段超出块边界）。如果字段符合新的块边界，则 API 会正常运行。 + + ``非编码`` 方式 + ^^^^^^^^^^^^^^^^^ + + ``非编码`` 方式表示不使用编码方案，因此 eFuse 数据块的 256 位都可以使用。不过，这中方式无法防止 eFuse 位的数据损坏。 + + ``3/4 编码`` 方式 + ^^^^^^^^^^^^^^^^^^^^^ + + ``3/4 编码`` 方式会限制写入一个编码单元的位数。长度为 256 位的块被划分为 4 个编码单元，每个编码单元包含 6 字节的有用数据和 2 字节的服务数据。这 2 字节的服务数据中存储了前 6 个数据字节的校验和。 + + 由于要计算每个编码单元的校验和，写入过程必须根据不同的编码单元进行划分。在这种情况下，通过多个写入操作分别烧录各 eFuse 位（ ``非编码`` 方式的烧录方法）的常规做法将不再适用，必须一次性同时烧写该编码单元的 eFuse 字段数据和校验和。这就是所谓的批量写入模式。 + + 由于采用批量写入模式，一个编码单元只能写入一次，禁止在同一编码单元重复写入。这意味着，在运行时写入的编码单元中只能包含一个 eFuse 字段。但是，如果事先通过 CSV 文件指定了编码单元的 eFuse 字段，或通过 :cpp:func:`esp_efuse_write_block` 写入编码单元的 eFuse 字段，那么一个编码单元中仍可包含多个 eFuse 字段。 + + + ``重复编码`` 方式 + ^^^^^^^^^^^^^^^^^^^^^^^^ + ``重复编码`` 方式只是简单重复每个 eFuse 位，不会像 ``3/4 编码`` 方式那样受到批量写入模式的限制。不过，这样做会产生很大的开销，每个 eFuse 块中只有 128 个位可用。 + +.. only:: not esp32 + + {IDF_TARGET_NAME} 不支持选择编码方式，会自动将以下编码方案应用于各 eFuse 块： + + * ``非编码`` 方式，应用于 EFUSE_BLK0。 + * ``RS 编码`` 方式。应用于 EFUSE_BLK1 - {IDF_TARGET_MAX_EFUSE_BLK}。 + + ``非编码`` 方式 + ^^^^^^^^^^^^^^^^^^^^^^ + + ``非编码`` 方式会自动应用于 EFUSE_BLK0。此方式不涉及任何编码，只是在硬件中维护 EFUSE_BLK0 的四个备份，因此，每个位实际存储四次，EFUSE_BLK0 也可以多次写入。 + + 该方案由硬件自动应用，软件中不可见。 + + ``RS 编码`` 方式 + ^^^^^^^^^^^^^^^^^^^^^^ + + * ``RS 编码`` 方式，即 Reed-Solomon 编码方式，会自动应用于 EFUSE_BLK1 至 {IDF_TARGET_MAX_EFUSE_BLK}。该编码方式支持至多 6 个字节的自动纠错。 + + 软件使用 ``RS(44, 32)`` 对 32 字节的 EFUSE_BLKx 进行编码，生成一个 12 字节的校验码，然后将 EFUSE_BLKx 和校验码同时烧录到 eFuse 中。 + + 在回读 eFuse 块时，eFuse 控制器会对 ``RS 编码`` 进行自动解码和纠错。因为 ``RS`` 校验码是根据整个 256 位 eFuse 块生成的，所以每个块只能写入一次，且必须采用批量写入模式。 + +批量写入模式 +^^^^^^^^^^^^ + +如需在运行时写入 eFuse 字段，可能要采用批量写入模式，具体取决于 eFuse 块使用的编码方案。批量写入模式的使用步骤如下： + +#. 调用 :cpp:func:`esp_efuse_batch_write_begin` 启用批量写入模式。 +#. 使用各 ``esp_efuse_write_...`` 函数，按照常规方法写入 eFuse 字段。 +#. 完成所有写入后，调用 :cpp:func:`esp_efuse_batch_write_commit` 将准备好的数据烧录到 eFuse 块中。 + +.. warning:: + + 如果 eFuse 块中已经存在通过 ``{IDF_TARGET_CODING_SCHEMES}`` 编码方案预先写入的数据，则无法在不破坏先前数据校验和/校验符号的情况下，写入额外的内容（即使需要写入的位为空）。 + + 先前的校验和/校验符号会被新的校验和/校验符号覆盖，并完全销毁。（但不会损坏有效负载 eFuse）。 + + 如发现在 CUSTOM_MAC、SPI_PAD_CONFIG_HD、SPI_PAD_CONFIG_CS 等块中存在预写入数据，请联系乐鑫获取所需的预烧录 eFuse。 + + 仅供测试（不推荐）：可以忽略或抑制违反编码方式数据的错误，从而在 eFuse 块中烧录必要的位。 + +.. _efuse_API: + +eFuse API +--------- + +可以通过指向描述结构的指针来访问 eFuse 字段。API 函数可以实现一些基本操作： + +* :cpp:func:`esp_efuse_read_field_blob` - 返回读取的 eFuse 位的数组。 +* :cpp:func:`esp_efuse_read_field_cnt` - 返回烧写为 “1” 的位的数量。 +* :cpp:func:`esp_efuse_write_field_blob` - 写入一个数组。 +* :cpp:func:`esp_efuse_write_field_cnt` - 将所需数量的位写为 “1”。 +* :cpp:func:`esp_efuse_get_field_size` - 返回字段的位数。 +* :cpp:func:`esp_efuse_read_reg` - 返回 eFuse 寄存器的值。 +* :cpp:func:`esp_efuse_write_reg` - 将值写入 eFuse 寄存器。 +* :cpp:func:`esp_efuse_get_coding_scheme` - 返回块的 eFuse 编码方式。 +* :cpp:func:`esp_efuse_read_block` - 从指定偏移位置开始读取指定大小的 eFuse 块中的密钥。 +* :cpp:func:`esp_efuse_write_block` - 从指定偏移位置开始将密钥写入指定大小的 eFuse 块中。 +* :cpp:func:`esp_efuse_batch_write_begin` - 设置字段写入的批处理模式。 +* :cpp:func:`esp_efuse_batch_write_commit` - 写入所有为批处理写入模式准备的数据，并重置批处理写入模式。 +* :cpp:func:`esp_efuse_batch_write_cancel` - 重置批处理写入模式和准备的数据。 +* :cpp:func:`esp_efuse_get_key_dis_read` - 返回密钥块的读保护状态。 +* :cpp:func:`esp_efuse_set_key_dis_read` - 设置密钥块的读保护状态。 +* :cpp:func:`esp_efuse_get_key_dis_write` - 返回密钥块的写保护状态。 +* :cpp:func:`esp_efuse_set_key_dis_write` - 设置密钥块的写保护状态。 +* :cpp:func:`esp_efuse_get_key_purpose` - 返回 eFuse 密钥块当前设置的用途。 +* :cpp:func:`esp_efuse_write_key` - 将一块密钥数据烧写到一个 eFuse 块。 +* :cpp:func:`esp_efuse_write_keys` - 将密钥烧写到未使用的 eFuse 块。 +* :cpp:func:`esp_efuse_find_purpose` - 查找设置为特定用途的密钥块。 +* :cpp:func:`esp_efuse_get_keypurpose_dis_write` - 返回 eFuse 密钥块的密钥用途字段的写保护状态（对于 esp32 始终为 true）。 +* :cpp:func:`esp_efuse_key_block_unused` - 如果密钥块未使用，则返回 true，否则返回 false。 +* :cpp:func:`esp_efuse_destroy_block` - 销毁此 eFuse 块中的数据。该函数有两个作用：(1) 如果未开启写保护，则将不为 1 的位都烧写为 1；(2) 如果未开启读保护，则开启读保护。 + +经常使用的字段有专门的函数可供使用，例如 :cpp:func:`esp_efuse_get_pkg_ver`。 + +.. only:: SOC_EFUSE_KEY_PURPOSE_FIELD or SOC_SUPPORT_SECURE_BOOT_REVOKE_KEY + + eFuse 密钥 API + ------------------ + + .. only:: SOC_EFUSE_KEY_PURPOSE_FIELD + + EFUSE_BLK_KEY0 - EFUSE_BLK_KEY5 可以保存 6 个长度为 256 位的密钥。每个密钥都有一个 ``ESP_EFUSE_KEY_PURPOSE_x`` 字段说明密钥用途。用途字段描述见 :cpp:type:`esp_efuse_purpose_t`。 + + 类似 ``ESP_EFUSE_KEY_PURPOSE_XTS_AES_...`` 的用途用于 flash 加密。 + + 类似 ``ESP_EFUSE_KEY_PURPOSE_SECURE_BOOT_DIGEST...`` 的用途用于安全启动。 + + 一些 eFuse API 可用于处理密钥状态： + + * :cpp:func:`esp_efuse_get_purpose_field` - 返回一个指向 eFuse 密钥块的密钥用途的指针。 + * :cpp:func:`esp_efuse_get_key` - 返回一个指向密钥块的指针。 + * :cpp:func:`esp_efuse_set_key_purpose` - 为一个 eFuse 密钥块设置密钥用途。 + * :cpp:func:`esp_efuse_set_keypurpose_dis_write` - 为 eFuse 密钥块的密钥用途字段设置写保护。 + * :cpp:func:`esp_efuse_find_unused_key_block` - 搜索未使用的密钥块并返回找到的第一个结果。 + * :cpp:func:`esp_efuse_count_unused_key_blocks` - 返回 EFUSE_BLK_KEY0..EFUSE_BLK_KEY_MAX 范围中未使用的 eFuse 密钥块数量。 + + .. only:: SOC_SUPPORT_SECURE_BOOT_REVOKE_KEY + + * :cpp:func:`esp_efuse_get_digest_revoke` - 返回安全启动公钥摘要撤销位的状态。 + * :cpp:func:`esp_efuse_set_digest_revoke` - 设置安全启动公钥摘要撤销位。 + * :cpp:func:`esp_efuse_get_write_protect_of_digest_revoke` - 返回安全启动公钥摘要撤销位的写保护。 + * :cpp:func:`esp_efuse_set_write_protect_of_digest_revoke` - 设置安全启动公钥摘要撤销位的写保护。 + + +如何添加新字段 +---------------------- + +1. 为新字段查找空闲位。运行 ``idf.py show-efuse-table`` 查看 ``esp_efuse_table.csv`` 文件，或运行以下命令： + +.. include:: inc/show-efuse-table_{IDF_TARGET_NAME}.rst + +不包含在方括号中的位是空闲的（一些位是乐鑫的保留位）。已检查所有字段的位重叠情况。 + +要在现有字段中添加子字段，请参考 :ref:`structured-efuse-fields`。例如，可使用 ``.`` 操作符将字段 ``SERIAL_NUMBER``、``MODEL_NUMBER`` 和 ``HARDWARE_REV`` 添加到现有的 ``USER_DATA`` 字段中，如下所示： + +.. code-block:: none + + USER_DATA.SERIAL_NUMBER, EFUSE_BLK3, 0, 32, + USER_DATA.MODEL_NUMBER, EFUSE_BLK3, 32, 10, + USER_DATA.HARDWARE_REV, EFUSE_BLK3, 42, 10, + +通常按照如下步骤添加新的 eFuse 字段： + +#. 在 CSV 文件中为每个 eFuse 字段添加一行记录。 +#. 运行 ``show_efuse_table`` 命令检查 eFuse 表。 +#. 如要生成源文件，运行 ``efuse_common_table`` 或 ``efuse_custom_table`` 命令。 + +如果遇到 ``intersects with`` 或 ``out of range`` 等错误，请参阅 :ref:`structured-efuse-fields` 中的解决办法。 + +位序 +---- + +eFuse 位序采取小字节序（参见下方示例），这说明 eFuse 位按照从 LSB 到 MSB 的顺序进行读写： + +.. code-block:: none + + $ espefuse.py 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 + +例如，CSV 文件描述了 ``USER_DATA`` 字段，该字段占用 256 位，即一个完整的块。 + +.. code-block:: none + + 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] + +因此，读取如上 eFuse ``USER_DATA`` 块会得到以下结果： + +.. code-block:: c + + 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; // 可以用于这种情况，因为它只包含一个条目 + 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); // 只读取前两位 + // field1 = 0x0002 + + uint8_t id = 0; + size_t id_size = esp_efuse_get_field_size(ESP_EFUSE_ID); // 返回 6 + // size_t id_size = ESP_EFUSE_USER_DATA[0]->bit_count; // 不能用于这种情况，因为其中包含 3 个条目，会返回 3 而不是 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 + + +在构建阶段获取 eFuse 状态 +------------------------- + +要在项目的构建阶段获取 eFuse 状态，可以使用以下两个 CMake 函数： + +* ``espefuse_get_json_summary()`` - 调用 ``espefuse.py summary --format json`` 命令并返回一个 JSON 字符串（该字符串不存储在文件中）。 +* ``espefuse_get_efuse()`` - 在此 JSON 字符串中找到给定的 eFuse 名称并返回其属性。 + +该 JSON 字符串具有以下属性： + +.. code-block:: json + + { + "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 + }, + } + +可以通过项目顶层目录下的 ``CMakeLists.txt`` (:example_file:`get-started/hello_world/CMakeLists.txt`) 来使用这些函数： + +.. code-block:: cmake + + # ... + project(hello_world) + + espefuse_get_json_summary(efuse_json) + espefuse_get_efuse(ret_data ${efuse_json} "MAC" "value") + message("MAC:" ${ret_data}) + +``value`` 属性的格式与 ``espefuse.py summary`` 中显示的格式相同。 + +.. code-block:: none + + MAC:94:b9:7e:5a:6e:58 (CRC 0xe2 OK) + +在示例测试 :example_file:`system/efuse/CMakeLists.txt` 中，添加了一个自定义目标 ``efuse-summary``。这样，不仅在项目构建阶段，而在任何时候都可以运行 ``idf.py efuse-summary`` 命令读取所需的 eFuse（在 ``efuse_names`` 列表中指定）。 + +调试 eFuse & 单元测试 +------------------------ + +.. _virtual-efuses: + +虚拟 eFuse +^^^^^^^^^^^^^^ + +Kconfig 选项 :ref:`CONFIG_EFUSE_VIRTUAL` 在 eFuse 管理器中虚拟了 eFuse 值，因此写入操作是仿真操作，不会永久更改 eFuse 值。这对于应用程序调试和单元测试很有用处。 + +在启动时，eFuses 被复制到 RAM 中。此时，所有的 eFuse 操作（读和写）都是通过 RAM 执行，而不是通过实际的 eFuse 寄存器执行的。 + +除了 :ref:`CONFIG_EFUSE_VIRTUAL` 选项外，还有 :ref:`CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH` 选项，该选项可将 eFuse 保留在 flash 内存中。要使用此模式，partition_table 在 ``partition.csv`` 中包含名为 ``efuse`` 的分区： + +.. code-block:: none + + efuse_em, data, efuse, , 0x2000, + +在启动阶段，eFuse 会从 flash 中复制到 RAM 中，在 flash 为空的情况下，则从实际的 eFuse 复制到 RAM 中，然后更新 flash。此选项能够在重启后仍然保留 eFuse，用于测试安全启动和 flash 加密功能。 + +flash 加密测试 +"""""""""""""" + +flash 加密是一项硬件功能，需要物理烧录 eFuse ``key`` 和 ``FLASH_CRYPT_CNT``。如果 flash 加密实际未启用，那么启用 :ref:`CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH` 选项只是提供了测试的可能性，而不会加密 flash 中的任何内容，即使日志中显示了加密操作。 + +为此，可使用 :cpp:func:`bootloader_flash_write` 函数。但是，如果运行应用程序时芯片已启用 flash 加密，或者以 :ref:`CONFIG_EFUSE_VIRTUAL_KEEP_IN_FLASH` 选项创建了启动加载程序，则 flash 加密/解密操作会正常进行。这意味着数据写入加密 flash 分区时被加密，从加密分区读取时被解密。 + +``espefuse.py`` +^^^^^^^^^^^^^^^ + +esptool 中包含一个用于读取/写入 {IDF_TARGET_NAME} eFuse 位的有用工具： `espefuse.py `_。 + +``idf.py`` 命令也可以直接提供上述工具的部分功能。例如，运行 ``idf.py efuse-summary`` 命令，效果等同于 ``espefuse.py summary``。 + +.. include:: inc/espefuse_summary_{IDF_TARGET_NAME}.rst + +.. include-build-file:: inc/esp_efuse_chip.inc +.. include-build-file:: inc/esp_efuse.inc