Issue with updating an old device OTA

Posts: 40
Joined: Mon Aug 07, 2017 7:53 am

Issue with updating an old device OTA

Postby mpulis » Thu Jul 30, 2020 8:43 am


I need to remotely update a device which is currently running firmware developed using IDF 2.0 to a newer firmware developed in IDF 3.3.

I'm trying out the OTA update locally to test it out but although the new firmware does boot up after the update, it seems to be crashing nearly immediately. The print out of the crash is shown in the image below.

For reference, the bootloader of the out-dated firmware is ESP-IDF v2.0-rc1-860-g2427809c-dirty 2nd stage bootloader. I've enabled the 'App compatible with bootloaders before IDF 2.1' option in sdkconfig for the updated firmware, to no effect.

Is this process possible? I shouldn't be saving any PHY configurations to the phy_init partition, so it is my understanding that just updating the app in the firmware partition shouldn't result in any issues.

Code: Select all

I (45) boot: ESP-IDF v2.0-rc1-860-g2427809c-dirty 2nd stage bootloader
I (45) boot: compile time 18:55:24
I (49) boot: Enabling RNG early entropy source...
I (66) boot: SPI Speed      : 40MHz
I (78) boot: SPI Mode       : DIO
I (91) boot: SPI Flash Size : 4MB
I (103) boot: Partition Table:
I (114) boot: ## Label            Usage          Type ST Offset   Length
I (137) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (160) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (184) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (207) boot:  3 factory          factory app      00 00 00010000 00100000
I (230) boot:  4 ota_0            OTA app          00 10 00110000 00100000
I (253) boot:  5 ota_1            OTA app          00 11 00210000 00100000
I (277) boot:  6 website          WiFi data        01 02 00310000 000e0000
I (300) boot: End of partition table
I (313) boot: Disabling RNG early entropy source...
I (330) boot: Loading app partition at offset 00110000
I (1658) boot: segment 0: paddr=0x00110018 vaddr=0x3f400020 size=0x3bb74 (244596) map
I (1658) boot: segment 1: paddr=0x0014bb94 vaddr=0x3ffbdb60 size=0x0343c ( 13372) load
I (1682) boot: segment 2: paddr=0x0014efd8 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _iram_start at ??:?

I (1703) boot: segment 3: paddr=0x0014f3e0 vaddr=0x40080400 size=0x00c28 (  3112) load
I (1731) boot: segment 4: paddr=0x00150010 vaddr=0x400d0018 size=0x8f42c (586796) map
0x400d0018: _stext at ??:?

I (1755) boot: segment 5: paddr=0x001df444 vaddr=0x40081028 size=0x15d2c ( 89388) load
0x40081028: call_start_cpu0 at C:/Users/mpulis/Desktop/Projects/ESP32/msys32/home/esp-idf/components/esp32/cpu_start.c:123 (discriminator 1)

E (594) spiram: SPI RAM enabled but initialization failed. Bailing out.
I (594) cpu_start: Failed to init external RAM; continuing without it.
I (597) cpu_start: Pro cpu up.
I (601) cpu_start: Application information:
I (606) cpu_start: Project name:     ASM160SE
I (611) cpu_start: App version:      1
I (615) cpu_start: Compile time:     Jul 30 2020 10:19:27
I (622) cpu_start: ELF file SHA256:  091cec3fad8c34f4...
I (628) cpu_start: ESP-IDF:          v3.3-beta2-152-geed94b87e-dirty
I (635) cpu_start: Starting app cpu, entry point is 0x4008151c
0x4008151c: xPortGetCoreID at C:/Users/mpulis/Desktop/Projects/ESP32/msys32/home/esp-idf/components/esp32/intr_alloc.c:621
 (inlined by) esp_intr_noniram_disable at C:/Users/mpulis/Desktop/Projects/ESP32/msys32/home/esp-idf/components/esp32/intr_alloc.c:692

I (641) cpu_start: App cpu up.
I (645) heap_init: Initializing. RAM available for dynamic allocation:
I (652) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (658) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (664) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (670) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (676) heap_init: At 3FFCC338 len 00013CC8 (79 KiB): DRAM
I (683) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (689) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (695) heap_init: At 40096D54 len 000092AC (36 KiB): IRAM
I (702) cpu_start: Pro cpu start user code
I (49) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (50) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (50) main: app_main: Initiated project
This is ESP32 chip with 2 CPU cores, WiFi/BT/BLE, silicon revision 1, 4MB external flash
ESP-IDF Version: v3.3-beta2-152-geed94b87e-dirty
I (70) systimer: systimerInit: Initializing system timer
I (80) main: app_main: Initialized systimer
I (80) main: app_main: Initialized watch dog timer
ESP_ERROR_CHECK failed: esp_err_t 0x105 (ESP_ERR_NOT_FOUND) at 0x4008b4cc
0x4008b4cc: chip_sleep_prot_en at ??:?

file: "C:/Users/mpulis/Desktop/Projects/ESP32/IDF3/msys32/home/ASM16xSEv4/main/main.c" line 113
func: app_main
expression: ret

ELF file SHA256: 091cec3fad8c34f4c13e51d352e07e8fad2f9002a042a00cba7dbf38cf2aaafb

Backtrace: 0x4008b044:0x3ffbcaa0 0x4008b4cf:0x3ffbcac0 0x400d6fd1:0x3ffbcae0 0x400d2210:0x3ffbcde0 0x400946f1:0x3ffbce00
0x4008b044: bt_correct_bbgain at ??:?

0x4008b4cf: chip_sleep_prot_en at ??:?

0x400d6fd1: wifi_set_home_channel_process at ??:?

0x400d2210: wifi_mode_set at ??:?

ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
mode:DIO, clock div:2
0x40080000: _iram_start at ??:?

entry 0x40080034
0x40080034: _iram_start at ??:?

Posts: 40
Joined: Mon Aug 07, 2017 7:53 am

Re: Issue with updating an old device OTA

Postby mpulis » Mon Aug 03, 2020 1:05 pm

Forgive me for bumping my own thread, but does anyone have an idea on why this is happening?

Posts: 1183
Joined: Wed Jun 14, 2017 9:00 pm

Re: Issue with updating an old device OTA

Postby chegewara » Mon Aug 03, 2020 4:53 pm

Im not sure it can solve your issue, but you have such option in menuconfig:

Code: Select all


Posts: 40
Joined: Mon Aug 07, 2017 7:53 am

Re: Issue with updating an old device OTA

Postby mpulis » Tue Aug 04, 2020 5:14 pm


Yes, that was already enabled.

I found the issue. It was because the firmware was attempting to mount a file-system onto a partition with subtype 'spiffs' which existed in the partition table of the new firmware, but not in the old one.

I've since managed to get around this by mounting the file-system onto an appropriate partition, but have also toyed around with trying to delete and re-flash a new partition table from the firwmare itself. This may be a bit of a derail from the original topic, but I keep getting an invalid argument error when attempting to erase the flash region containing the partition table. The amount of memory I'm trying to erase and the start memory address are 4kB aligned (see code snippet below), so I can't see why I'm getting an invalid argument. I have seen reference to the config 'SPI_FLASH_WRITING_DANGEROUS_REGIONS", but I can't enable this from the configuration menu.

Does anyone know why this is happening?

Code: Select all

err = spi_flash_erase_range(0x8000, 0x1000);

Who is online

Users browsing this forum: Baidu [Spider] and 39 guests