Chapter 4. Software framework
• The current error may be related to the chip version on the development board or to the fact that
the software version of the esp-idf SDK is not the ocial production version. The chip (ROM)
bootloader expects the chip ID is 9, which is the production version of the chip (not a test version).
However, in the secondary bootloader header, it sees the chip ID is 4, which is the beta version of
the chip. Please refer to the description in esp-idf/issues/7960 .
• The actual version of the chip can be obtained by the command esptool.py chip_id. If the
chip version is the production version, this error is related to the version of the used esp-idf SDK.
For ESP32-S3 series products, esp-idf release/v4.4 and later are necessary.
4.9.38 What is the accuracy of the internal 150 kHz RTC of ESP32 series chips?
• The accuracy of the internal 150 kHz RTC of ESP32 series chips is ±5%.
4.9.39 What versions of esp-idf SDK are supported by ESP32-D0WDR2-V3 chip?
• Supported IDF versions are: v4.4.1, v4.3.3, v4.2.3, and v4.1.3.
4.9.40 When I test OTA applications based on the ESP32 chip, can I delete the default
factory partition in the partition table and set the address of the OTA_0 partition
to 0x10000?
• Yes. Please note that the osets of partitions of any app type have to be aligned to 0x10000 (64K).
4.9.41 Why can I not burn data to BLOCK3 of ESP32-C3 eFuse with espefuse.py
burn_key?
• espefuse.py burn_key can only burn data to eFuse blocks of the KEY_DATA type. However,
BLOCK3 of ESP32-C3 is of the USR_DATA type by default.
• You can burn data to eFuse blocks of the USR_DATA type with espefuse.py burn_block_data.
4.9.42 Why do dierent ESP32 modules have dierent ash erase time?
• This is caused by dierent type of ash models. Some module of ash don’t have a mechanism for passing
empty blocks when erasing, so it takes longer time.
4.9.43 Why I encountered the following error after I run the rmware based on the esp-
idf SDK?
***ERROR*** A stack overflow in task sys_evt has been detected.
• The error is caused by insucient system_event task stack. You can try to resolve it by increasing
Component config > ESP System Setting > Event loop task stack size.
However, the overow occurs because too much logic is being processed within system_event. It is
not recommended as it might lead to delayed handling of subsequent events. We suggest forwarding
this event to other tasks for processing, either through a queue or other operations.
Espressif Systems 124
Submit Document Feedback
Release master
To Next Page
Loading...