esp_ota_begin triggers WDT if partition is too big (IDFGH-2859)

[mzimmers]

Environment

• Development Kit: [none]
• Kit version (for WroverKit/PicoKit/DevKitC): [v1|v2|v3|v4]
• Module or chip used: [ESP32-WROVER]
• IDF version (run git describe --tags to find it):
  // v4.0-199-ge6a59ac03
• Build System: [idf.py]
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  // (crosstool-NG esp-2019r2) 8.2.0
• Operating System: [Windows]
• (Windows only) environment type: [ESP Command Prompt].
• Using an IDE?: [No]
• Power Supply: [USB]

Problem Description

esp_ota_begin erase can trigger WDT
//Detailed problem description goes here.
If the partition being erased is too large, the call to esp_ota_begin will cause the WDT to go off. This problem is well documented (and solved) here:

Debug Logs

E (49923) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (50063) task_wdt:  - IDLE0 (CPU 0)
E (50063) task_wdt: Tasks currently running:
E (50063) task_wdt: CPU 0: ipc0
E (50063) task_wdt: CPU 1: IDLE1

[chegewara]

What means too large?

[mzimmers]

In my case, the partitions are about 1.8MB:
(71) boot: ## Label Usage Type ST Offset Length I (79) boot: 0 otadata OTA data 01 00 00009000 00002000 I (86) boot: 1 phy_init RF data 01 01 0000b000 00001000 I (94) boot: 2 nvs WiFi data 01 02 0000c000 00004000 I (101) boot: 3 nvs_config WiFi data 01 02 00010000 00004000 I (109) boot: 4 nvs_syslog WiFi data 01 02 00014000 0006c000 I (116) boot: 5 ota_0 OTA app 00 10 00080000 001c0000 I (124) boot: 6 ota_1 OTA app 00 11 00240000 001c0000

It worked OK when my partitions were a little smaller (closer to 1.5MB).

[boarchuz]

I just noticed there are config options for managing this.

See:
CONFIG_SPI_FLASH_YIELD_DURING_ERASE
CONFIG_SPI_FLASH_ERASE_YIELD_DURATION_MS
CONFIG_SPI_FLASH_ERASE_YIELD_TICKS

https://docs.espressif.com/projects/esp-idf/en/v3.3.1/api-reference/kconfig.html#config-spi-flash-yield-during-erase

Yet they seem to have been removed for IDF v4...?

[projectgus]

Hi @boarchuz,

This is a mistake in our internal development process, thanks for highlighting it. The new SPI Flash API for v4.0 was being developed around the same time this fix was being applied, and the fix was backported to v3.3.x without the same fix being merged for v4.0.

Will fix ASAP, and this issue will be updated when the fix is merged.

[AxelLin]

Hi @projectgus

The fix is not yet available in current master tree.
It should not take such long time to fix "a mistake in internal development process".
So i'm wondering if something wrong?

[projectgus]

Hi @AxelLin ,

Thanks for being patient while we merge this. Because v4.0 has an entirely new SPI flash implementation, we have to implement this on both implementations (legacy & new) for v4.x and then test thoroughly. So quite a bit of new code has to be written, tested, and reviewed compared to the v3.x change.

The change is in the final stages of testing now, will be merged ASAP.