- Home
- Hardware
- SDKs
- Cloud
- Solutions
- Support
- Ecosystem
- Company
- Contact
news
Variations in Some ESP32-WROVER modules
Shanghai, China
Oct 29, 2018
Between February and July 2018, certain modules in the ESP32-WROVER series were produced with a variation to their internal eFuse one-time-programmable storage.
Between February 2018 and July 2018, some ESP32-WROVER, ESP32-WROVER-I, ESP32-WROVER-B and ESP32-WROVER-IB modules were produced with a variation to their internal eFuse one-time-programmable storage. In these modules, the System Parameter "Coding Scheme" was set to the 3/4 Coding Scheme, and some additional ADC calibration data was written into part of the eFuse BLOCK3. Since July 2018, this change has been removed, and all ESP32-based modules are currently being produced with the default "Coding Scheme" (None) and an empty eFuse BLOCK3.
Only applications which write data to eFuse BLOCK1, BLOCK2, or BLOCK3 are affected by this variation. This includes the ESP-IDF Flash Encryption and Secure Boot features.
Only some ESP32-WROVER, ESP32-WROVER-I, ESP32-WROVER-B and ESP32-WROVER-IB modules have this variation. However, the majority of the ESP32-WROOM modules and other Espressif chips and modules do not have this.
To determine if a batch of modules has this variation, check the value of the CODING_SCHEME eFuse bits, using the "espefuse.py summary" command line tool. Value "0" indicates "None" Coding Scheme, and value "1" indicates the 3/4 Coding Scheme and the relevant variation. Alternatively, contact Espressif Sales or local distributors for information about a particular batch.
Limitations
For modules using the 3/4 Coding Scheme, Secure Boot and Flash Encryption in ESP-IDF 3.1.0 and earlier versions are not recommended. There is also no support for writing custom data to eFuse BLOCK1, BLOCK2, or BLOCK3 for these modules. Attempts to write custom data in these blocks may lead to unexpected eFuse reading, which means the custom data read from eFuse may not be the same as what users have originally written.
For these affected modules, using Flash Encryption or Secure Boot in ESP-IDF 3.1.0 and earlier versions results in random 192-bit keys being generated by the device on first boot. However, random data is also written to the 64-bit error correction fields in the eFuse block. This causes hardware error correction to dilute the effective key entropy to a minimum of 176 bits. Using a module with the 3/4 Coding Scheme in this way does not compromise the overall security of the device, but upgrading to a supported release is still strongly recommended.
Support for the 3/4 Coding Scheme is currently present in ESP-IDF development master branch (since commit 66a54c7). This support will also be released in ESP-IDF version 3.1.1, which is due shortly.
Modules with this variation also have 48 bits of factory ADC calibration data readable in eFuse BLOCK3. Presence of this data is indicated by the BLK3_part_reserve eFuse flag. Consult the ESP32 Technical Reference Manual, section: 20.3.1.4 “BLK3_part_reserve", for more information. ESP-IDF v3.0 and newer will automatically make use of this additional data when using the ESP-IDF ADC calibration feature. In other ESP32 devices, ADC calibration is provided by VRef calibration data stored in eFuse BLOCK0.
Further Information
For more information about the eFuse Coding Schemes, consult the ESP32 Technical Reference Manual, section 20.3.1.3: “System Parameter coding_scheme”.