ESP32 Forum

I've tried to read the parameters of my recently purchased ESP32 in two different ways in the Arduino IDE:

1. Using class ESP
2. Using the function esp_chip_info(esp_chip_info_t * out_info) [see below]

The following readout data was displayed from the Serial Monitor of the Arduino IDE (points in question are marked bold):

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13076
entry 0x40078a58

Register EFUSE_BLK0_RDATA3_REG: 0xA000 = 0b1010000000000000

Data determined by the ESP class
Chip Revision: 1
SDK Version: v3.1-dev-239-g1c3dd23f-dirty
CPU Freq (MHz): 240
Cycles since start: 15766351
Free Heap: 223356
Flash Chip Size: 4194304
Flash Chip Speed: 80000000
Flash Chip Mode: 2 = FM_DOUT

Data determined by the function esp_chip_info()
Chip Info Model: 0
Chip Info Features: 50
Chip Info Cores: 2
Chip Info Revision: 1

Used Constants
1 = Constant CHIP_ESP32
8000 = Constant EFUSE_RD_CHIP_VER_REV1_M
1 = Constant EFUSE_RD_CHIP_VER_DIS_APP_CPU_M
2 = Constant EFUSE_RD_CHIP_VER_DIS_BT_M
1 = Constant CHIP_FEATURE_EMB_FLASH
2 = Constant CHIP_FEATURE_WIFI_BGN
10 = Constant CHIP_FEATURE_BLE
20 = Constant CHIP_FEATURE_BT
E00 = Constant EFUSE_RD_CHIP_VER_PKG_M
9 = Constant EFUSE_RD_CHIP_VER_PKG_S
2 = Constant EFUSE_RD_CHIP_VER_PKG_ESP32D2WDQ5
4 = Constant EFUSE_RD_CHIP_VER_PKG_ESP32PICOD2

I came across some "weird" results:

1. After booting, the date Jun 8 2016 is displayed. If it is not the release date of the firmware, but the date of manufacture of the chip, that would be strange, because the below indicated Revision 1 of the ESP32 is delivered to my knowledge only since week 12 of 2017: How can in an ESP32, which has only been available since 12-2017, as date of production be stored Jun 8 2016 - or is the Revision 1 wrong and it is Revision 0 in reality?

2. In the boot log the mode:DIO is displayed in the 4th line, but with ESP.getFlashChipMode() the value 0x02 = FM_DOUT is read out as flash chip mode. What is true?

3. Why got the SDK version the extension dirty? This is usually an indication of a botched, sloppy version!

4. Why does Chip Info Model have the value 0? According to the function get_chip_info_esp32(esp_chip_info_t * out_info) shown below, out_info->model is assigned the constant CHIP_ESP32, which correctly has the value 1 (corresponding to the ESP32), as the list of the used constants in the output of the Serial Monitor shows.

5. The mask Chip Info Features is displayed as 0x50 = 0b01010000. In function get_chip_info_esp32(esp_chip_info_t * out_info), out_info->features is assigned in any case the value CHIP_FEATURE_WIFI_BGN (mask 0x02 = 0b00000010). The bit EFUSE_RD_CHIP_VER_DIS_BT_M (mask 0x02, ie bit 1) in register EFUSE_BLK0_RDATA3_REG has the content 0 (marked bold in the above output of the Serial Monitor), so out_info->features is locical OR-ed with the values CHIP_FEATURE_BT (mask 0x20, bit 5) and CHIP_FEATURE_BLE (mask 0x10, bit 4) ie new content = 0b00110010.
The bit field package with the mask EFUSE_RD_CHIP_VER_PKG_M in register EFUSE_BLK0_RDATA3_REG has the content 0b000 (marked bold in the above output of the Serial Monitor), so it is not equal to EFUSE_RD_CHIP_VER_PKG_ESP32D2WDQ5 (mask 0x02, bit 1) and EFUSE_RD_CHIP_VER_PKG_ESP32PICOD2 (mask 0x04, bit 2), so CHIP_FEATURE_EMB_FLASH probably will not be locical OR-ed to out_info->features. "Probably" because the constant EFUSE_RD_CHIP_VER_PKG_ESP32PICOD4 in the source code of the sketch caused a compilation error (why?) and therefore had to be commented out. The two other PKG-constants were known.
According to my findings out_info->features should therefore have the content 0x32 = 0b00110010, but returned is 0x50! How does this happen?

Functions esp_chip_info() and get_chip_info_esp32(), which I found in https://github.com/espressif/esp-idf/bl ... stem_api.c :

static void get_chip_info_esp32(esp_chip_info_t* out_info)
{
uint32_t reg = REG_READ(EFUSE_BLK0_RDATA3_REG);
memset(out_info, 0, sizeof(*out_info));
out_info->model = CHIP_ESP32;
if ((reg & EFUSE_RD_CHIP_VER_REV1_M) != 0) {
out_info->revision = 1;
}
if ((reg & EFUSE_RD_CHIP_VER_DIS_APP_CPU_M) == 0) {
out_info->cores = 2;
} else {
out_info->cores = 1;
}
out_info->features = CHIP_FEATURE_WIFI_BGN;
if ((reg & EFUSE_RD_CHIP_VER_DIS_BT_M) == 0) {
out_info->features |= CHIP_FEATURE_BT | CHIP_FEATURE_BLE;
}
int package = (reg & EFUSE_RD_CHIP_VER_PKG_M) >> EFUSE_RD_CHIP_VER_PKG_S;
if (package == EFUSE_RD_CHIP_VER_PKG_ESP32D2WDQ5 ||
package == EFUSE_RD_CHIP_VER_PKG_ESP32PICOD2 ||
package == EFUSE_RD_CHIP_VER_PKG_ESP32PICOD4) {
out_info->features |= CHIP_FEATURE_EMB_FLASH;
}
}

void esp_chip_info(esp_chip_info_t* out_info)
{
// Only ESP32 is supported now, in the future call one of the
// chip-specific functions based on sdkconfig choice
return get_chip_info_esp32(out_info);
}

1. It is rom code version date, not related to production date or silicon version
2. Both. Rom code access flash in dio mode then 2nd stage bootloader can change mode.
4. For me prints 1
5. 0x32 = 50

Thanks for the fast answer!
To point 5:
Just after sending my issue, I recognized my mistake: In my sketch, all values were output hexadecimal via the serial monitor, with the exception of chip info features, which was decimal and 0x32 = 50!
To point 4:
Here is the relevant code snippet:
Serial.println("\nData determined by the function esp_chip_info()");
esp_chip_info_t info;
esp_chip_info(&info);
Serial.print("Chip Info Model: ");
Serial.println(info.model, HEX);
Serial.print("Chip Info Features: ");
Serial.println(info.features);
Serial.print("Chip Info Cores: ");
Serial.println(info.cores, HEX);
Serial.print("Chip Info Revision: ");
Serial.println(info.revision, HEX);
Serial.println();

The Serial Monitor prints:
Data determined by the function esp_chip_info()
Chip Info Model: 0
Chip Info Features: 50
Chip Info Cores: 2
Chip Info Revision: 1

The master branch of ESP-IDF has a fix for chip model field, but if you are using Arduino, it probably is compiled with an older version of ESP-IDF, so doesn't have the fix.
https://github.com/espressif/esp-idf/co ... 5561bccf87