esp32 resetting when running code updated via ota but direct make flash running fine
Posted: Thu Mar 12, 2020 3:24 pm
Hi,
I have some doubts regarding the esp32 ota. I customized the OTA for my requirement and I am using factory and ota_0 where factory is having my bluetooth bootloader. As of now all is fine but now I am finding my new firmware build is resetting if I do it via ota. Even I tried to load the app via espflash on my ota_0 partition but still it is happening.
If I do make flash from my app build directory then it is working fine.
Mine is custom partition table.
In application code I just commented the factory and in my bluetooth bootloader I uncommented it. I tried all options and realized that if I burn the factory commented partition table alone to a not working setup, it is working fine because the second stage bootloader is directly jumping to the application in ota_0 and is working perfectly. But when I do make flash from by bluetooth ota folder, it is loading the ota and I can upload the firmware to ota_0 via bluetooth. I am not using ota_1, instead I am erasing the ota_0 by holding a pin on bootup which is enabled in my bluetooth bootloader menuconfig.
My application is resetting due to some heap related issue. But this is not happening if I do make flash from my application folder.
Even I tried make flash from bluetooth bootloader and then uploaded the firmware via bluetooth, it is having same issue, then I burned the applicaion alone to the ota_0 address 0x160000 and it is still having same issue, so it is not about the ota failure. It works for my previous bins but now only for new changes it is creating issue, But my worry is why is this happening if there is a factory + ota_0 and not happening when I burn the partition table commenting the factory ?
Also I have few doubts, when I opened bootloader_Init.c I can see
How is this bootloader deciding the bss start, data start etc because it is not even loaded the application from ota_0.
So is it loading the new stack pointer etc after loading binary from ota_0 ?
I am just trying to see what is the difference.
Working bootup log:
Resetting bootup log when factory partition is there. But I believe second stage bootloader wont allow the code to jump to factory unless I press the button while bootup or ota_0 is corrupted. So I am not able to understand how factory partition is creating issue in code running from ota_0. It is getting some heap corruption while running after 2 to 3 seconds. This means it is running fine but issue while running, some memory issue or so.
Issue bootup: (after burning factory and new bootloader.bin and partition table from bluetooth ota build and running the application without invoking the bootloader, it is jumping to ota_0 and started working , but after few seconds it is crashing due to heap issue)
I have some doubts regarding the esp32 ota. I customized the OTA for my requirement and I am using factory and ota_0 where factory is having my bluetooth bootloader. As of now all is fine but now I am finding my new firmware build is resetting if I do it via ota. Even I tried to load the app via espflash on my ota_0 partition but still it is happening.
If I do make flash from my app build directory then it is working fine.
Mine is custom partition table.
Code: Select all
1 # Espressif ESP32 Partition Table
2 # Name, Type, SubType, Offset, Size
3 #OTA1 = 2.5MB
4 #OTA2 = 10KB
5 #FACTORY OTA BT = <1.2MB
6 nvs, data, nvs, 0xa000, 0x6000
7 otadata, data, ota, 0x10000, 0x4000
8 phy_init, data, phy, 0x14000, 0x2000
9 #factory, 0, 0, 0x20000, 0x140000
10 ota_0, 0, ota_0, 0x160000, 0x280000
11 ota_1, 0, ota_1, 0x3e0000, 102400
My application is resetting due to some heap related issue. But this is not happening if I do make flash from my application folder.
Even I tried make flash from bluetooth bootloader and then uploaded the firmware via bluetooth, it is having same issue, then I burned the applicaion alone to the ota_0 address 0x160000 and it is still having same issue, so it is not about the ota failure. It works for my previous bins but now only for new changes it is creating issue, But my worry is why is this happening if there is a factory + ota_0 and not happening when I burn the partition table commenting the factory ?
Also I have few doubts, when I opened bootloader_Init.c I can see
Code: Select all
70 esp_err_t bootloader_init()
71 {
72 cpu_configure_region_protection();
73 cpu_init_memctl();
74
75 /* Sanity check that static RAM is after the stack */
76 #ifndef NDEBUG
77 {
78 int *sp = get_sp();
79 assert(&_bss_start <= &_bss_end);
80 assert(&_data_start <= &_data_end);
81 assert(sp < &_bss_start);
82 assert(sp < &_data_start);
83 }
84 #endif
How is this bootloader deciding the bss start, data start etc because it is not even loaded the application from ota_0.
So is it loading the new stack pointer etc after loading binary from ota_0 ?
I am just trying to see what is the difference.
Working bootup log:
Code: Select all
I (11) boot: ESP-IDF v3.3-dirty 2nd stage bootloader
I (11) boot: compile time 20:17:21
I (11) boot: Enabling RNG early entropy source...
I (15) boot: SPI Speed : 40MHz
I (19) boot: SPI Mode : DIO
I (23) boot: SPI Flash Size : 4MB
I (27) boot: Partition Table:
I (31) boot: ## Label Usage Type ST Offset Length
I (38) boot: 0 nvs WiFi data 01 02 0000a000 00006000
I (45) boot: 1 otadata OTA data 01 00 00010000 00004000
I (53) boot: 2 phy_init RF data 01 01 00014000 00002000
I (60) boot: 3 ota_0 OTA app 00 10 00160000 00280000
I (68) boot: 4 ota_1 OTA app 00 11 003e0000 00019000
I (75) boot: End of partition table
I (80) esp_image: segment 0: paddr=0x00160020 vaddr=0x3f400020 size=0x4cfc8 (315336) map
I (195) esp_image: segment 1: paddr=0x001acff0 vaddr=0x3ffbdb60 size=0x026ac ( 9900) load
I (199) esp_image: segment 2: paddr=0x001af6a4 vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _WindowOverflow4 at /home/vinod/esp/esp-idf/components/freertos/xtensa_vectors.S:1779
I (202) esp_image: segment 3: paddr=0x001afaac vaddr=0x40080400 size=0x00564 ( 1380) load
I (211) esp_image: segment 4: paddr=0x001b0018 vaddr=0x400d0018 size=0x70a24 (461348) map
0x400d0018: _flash_cache_start at ??:?
I (375) esp_image: segment 5: paddr=0x00220a44 vaddr=0x40080964 size=0x11c48 ( 72776) load
I (413) boot: Loaded app from partition at offset 0x160000
I (413) boot: Disabling RNG early entropy source...
I (414) cpu_start: Pro cpu up.
I (417) cpu_start: Application information:
I (422) cpu_start: Project name: http-request
I (428) cpu_start: App version: 2b850aa-dirty
I (433) cpu_start: Compile time: Mar 11 2020 20:17:20
I (439) cpu_start: ELF file SHA256: cc9af1e836640122...
I (445) cpu_start: ESP-IDF: v3.3-dirty
I (450) cpu_start: Starting app cpu, entry point is 0x4008134c
0x4008134c: call_start_cpu1 at /home/vinod/esp/esp-idf/components/esp32/cpu_start.c:270
I (0) cpu_start: App cpu up.
I (461) heap_init: Initializing. RAM available for dynamic allocation:
I (468) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (474) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (480) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (486) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (492) heap_init: At 3FFCAAB0 len 00015550 (85 KiB): DRAM
I (498) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (505) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (511) heap_init: At 400925AC len 0000DA54 (54 KiB): IRAM
I (517) cpu_start: Pro cpu start user code
I (88) cpu_start: Chip Revision: 1
W (88) cpu_start: Chip revision is higher than the one configured in menuconfig. Suggest to upgrade it.
I (91) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (122) pm_esp32: Frequency switching config: CPU_MAX: 240, APB_MAX: 240, APB_MIN: 10, Light sleep: DISABLED
I (122) gpio: GPIO[34]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 1| Intr:1
I (132) Touch pad: Initializing touch pad
I (192) Touch pad: test init: touch pad [5] val is 1160
I (192) Touch pad: test init: touch pad [6] val is 1143
Resetting bootup log when factory partition is there. But I believe second stage bootloader wont allow the code to jump to factory unless I press the button while bootup or ota_0 is corrupted. So I am not able to understand how factory partition is creating issue in code running from ota_0. It is getting some heap corruption while running after 2 to 3 seconds. This means it is running fine but issue while running, some memory issue or so.
Issue bootup: (after burning factory and new bootloader.bin and partition table from bluetooth ota build and running the application without invoking the bootloader, it is jumping to ota_0 and started working , but after few seconds it is crashing due to heap issue)
Code: Select all
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x4009253f PS : 0x00060133 A0 : 0x80092313 A1 : 0x3ffce730
0x4009253f: block_data_size at /home/vinod/esp/esp-idf/components/heap/multi_heap.c:150
A2 : 0x00ffffff A3 : 0x3ffce880 A4 : 0x3ffd0fe4 A5 : 0x00000001
A6 : 0x3ff000e0 A7 : 0x00000001 A8 : 0xc002f004 A9 : 0xc002f000
A10 : 0x3ffc5d4c A11 : 0x00060123 A12 : 0x00060120 A13 : 0x3ffd0ff4
A14 : 0x00000000 A15 : 0x00000000 SAR : 0x00000016 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00ffffff LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000
ELF file SHA256: cc9af1e8366401228a0291f251a130eb740b45f32931603415cc9dc2c93b2179
Backtrace: 0x4009253f:0x3ffce730 0x40092310:0x3ffce750 0x40082d16:0x3ffce780 0x40082d58:0x3ffce7b0 0x40083045:0x3ffce7d0 0x4000beaf:0x3ffce7f0 0x4008307d:0x3ffce810 0x4000bef5:0x3ffce830 0x4013dca3:0x3ffce850 0x4013e9b7:0x3ffce870 0x40125e23:0x3ffce8b0 0x40125f49:0x3ffce8d0 0x401258f9:0x3ffce8f0 0x4012592d:0x3ffce920 0x40125b8f:0x3ffce940 0x401257a2:0x3ffce970
0x4009253f: block_data_size at /home/vinod/esp/esp-idf/components/heap/multi_heap.c:150
0x40092310: multi_heap_malloc_impl at /home/vinod/esp/esp-idf/components/heap/multi_heap.c:433
0x40082d16: heap_caps_malloc at /home/vinod/esp/esp-idf/components/heap/heap_caps.c:196
0x40082d58: heap_caps_malloc_default at /home/vinod/esp/esp-idf/components/heap/heap_caps.c:196
0x40083045: _malloc_r at /home/vinod/esp/esp-idf/components/newlib/syscalls.c:37
0x4008307d: _calloc_r at /home/vinod/esp/esp-idf/components/newlib/syscalls.c:58
0x4013dca3: i2c_cmd_link_append at /home/vinod/esp/esp-idf/components/driver/i2c.c:854
0x4013e9b7: i2c_master_write_byte at /home/vinod/esp/esp-idf/components/driver/i2c.c:1048
0x40125e23: i2c_read_reg at /media/sf_VM/myapp/components/fuelgauge/stc3115_I2C.c:45
0x40125f49: I2C_Read at /media/sf_VM/myapp/components/fuelgauge/stc3115_I2C.c:148
0x401258f9: STC3115_ReadByte at /media/sf_VM/myapp/components/fuelgauge/stc3115_Driver.c:701
0x4012592d: STC3115_Status at /media/sf_VM/myapp/components/fuelgauge/stc3115_Driver.c:701
0x40125b8f: GasGauge_Task at /media/sf_VM/myapp/components/fuelgauge/stc3115_Driver.c:718
0x401257a2: i2c_test_task at /media/sf_VM/myapp/components/fuelgauge/fuelgauge_main.c:117
Rebooting...
I (11) boot: ESP-IDF v3.3-dirty 2nd stage bootloader
I (12) boot: compile time 16:46:11
I (12) boot: Enabling RNG early entropy source...
I (15) boot: SPI Speed : 40MHz
I (19) boot: SPI Mode : DIO
I (23) boot: SPI Flash Size : 4MB
I (28) boot: Partition Table:
I (31) boot: ## Label Usage Type ST Offset Length
I (38) boot: 0 nvs WiFi data 01 02 0000a000 00006000
I (46) boot: 1 otadata OTA data 01 00 00010000 00004000
I (53) boot: 2 phy_init RF data 01 01 00014000 00002000
I (61) boot: 3 factory factory app 00 00 00020000 00140000
I (68) boot: 4 ota_0 OTA app 00 10 00160000 00280000
I (76) boot: 5 ota_1 OTA app 00 11 003e0000 00019000
I (83) boot: End of partition table
I (87) esp_image: segment 0: paddr=0x00160020 vaddr=0x3f400020 size=0x4cfc8 (315336) map
I (203) esp_image: segment 1: paddr=0x001acff0 vaddr=0x3ffbdb60 size=0x026ac ( 9900) load
I (206) esp_image: segment 2: paddr=0x001af6a4 vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _WindowOverflow4 at /home/vinod/esp/esp-idf/components/freertos/xtensa_vectors.S:1779
I (210) esp_image: segment 3: paddr=0x001afaac vaddr=0x40080400 size=0x00564 ( 1380) load
I (219) esp_image: segment 4: paddr=0x001b0018 vaddr=0x400d0018 size=0x70a24 (461348) map
0x400d0018: _flash_cache_start at ??:?
I (383) esp_image: segment 5: paddr=0x00220a44 vaddr=0x40080964 size=0x11c48 ( 72776) load
I (421) boot: Loaded app from partition at offset 0x160000
I (421) boot: Disabling RNG early entropy source...
I (422) cpu_start: Pro cpu up.
I (425) cpu_start: Application information:
I (430) cpu_start: Project name: http-request
I (435) cpu_start: App version: 2b850aa-dirty
I (441) cpu_start: Compile time: Mar 11 2020 20:17:20
I (447) cpu_start: ELF file SHA256: cc9af1e836640122...
I (453) cpu_start: ESP-IDF: v3.3-dirty
I (458) cpu_start: Starting app cpu, entry point is 0x4008134c
0x4008134c: call_start_cpu1 at /home/vinod/esp/esp-idf/components/esp32/cpu_start.c:270
I (459) cpu_start: App cpu up.
I (469) heap_init: Initializing. RAM available for dynamic allocation:
I (476) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (482) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (488) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (494) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (500) heap_init: At 3FFCAAB0 len 00015550 (85 KiB): DRAM
I (506) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (513) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (519) heap_init: At 400925AC len 0000DA54 (54 KiB): IRAM
I (525) cpu_start: Pro cpu start user code
I (96) cpu_start: Chip Revision: 1
W (96) cpu_start: Chip revision is higher than the one configured in menuconfig. Suggest to upgrade it.
I (99) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (131) pm_esp32: Frequency switching config: CPU_MAX: 240, APB_MAX: 240, APB_MIN: 10, Light sleep: DISABLED
I (131) gpio: GPIO[34]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 1| Intr:1
I (141) Touch pad: Initializing touch pad
I (211) Touch pad: test init: touch pad [5] val is 1175
I (211) Touch pad: test init: touch pad [6] val is 1152