Open VitorBFreitas opened 1 year ago
Jiangyafeng
commented
1 year ago @VitorBFreitas Thank you very much for this question. It is true that the latest idf v4.4.2 has this problem in adapting to mdf, and this problem will be fixed as soon as possible. If there is any new progress, it will be updated as soon as possible.
Jiangyafeng
commented
1 year ago @VitorBFreitas You can not enable Component config -> MDF Mupgrade -> Fall back to the previous version. There is no problem.
VitorBFreitas
commented
1 year ago @Jiangyafeng Unfortunetly this is a feature that I'm using in my actual project to prevent loose communication with MQTT broker case a bad firmware is flashed.
mmrein
commented
1 year ago Is there some fix for this? Does anyone know what causes this? Does v4.4.3 have same problem?
I'm planning to make some changes in my project which would require some safety measures with possibility to revert to previous firmware in case wrong image has been flashed.
VitorBFreitas
commented
1 year ago @mmrein It's occurs with esp-idf v4.4.3 as well.
mmrein
commented
1 year ago I didn't realize this occurs even after first flash, not just after OTA. So I can confirm this bug is still present in v4.4.4
mmrein
commented
1 year ago Found some kind of clue - with debul log level set to Verbose the app seems to be starting, but on level Debug or less it freezes:
--- LOG OUTPUT DEFAULT VERBOSITY: DEBUG
D (1564) intr_alloc: Connected src 24 to int 3 (cpu 0)
I (1569) cpu_start: Starting scheduler on PRO CPU.
D (1574) intr_alloc: Connected src 25 to int 2 (cpu 1)
I (1579) cpu_start: Starting scheduler on APP CPU.
D (1574) partition: Loading the partition table
D (1594) partition: Partition table MD5 verified
--- FREEZE--- LOG OUTPUT DEFAULT VERBOSITY: VERBOSE
D (2099) intr_alloc: Connected src 24 to int 3 (cpu 0)
I (2104) cpu_start: Starting scheduler on PRO CPU.
V (0) intr_alloc: esp_intr_alloc_intrstatus (cpu 1): checking args
V (2116) intr_alloc: esp_intr_alloc_intrstatus (cpu 1): Args okay. Resulting flags 0x40E
D (2124) intr_alloc: Connected src 25 to int 2 (cpu 1)
I (2129) cpu_start: Starting scheduler on APP CPU.
D (2110) partition: Loading the partition table
V (2145) calculated md5: 0x3ffb7cb8 86 8a 0e ec e7 f1 b4 8a 6f 58 5b ed dd 1e ed e3 |........oX[.....|
V (2149) stored md5: 0x3f45e190 86 8a 0e ec e7 f1 b4 8a 6f 58 5b ed dd 1e ed e3 |........oX[.....|
D (2158) partition: Partition table MD5 verified
D (2167) nvs: nvs_open_from_partition ESP-MDF 1
D (2168) nvs: nvs_set_blob mupgrade_count 4
D (2172) nvs: nvs_close 1
D (2174) [mupgrade_check, 127]: version_fallback_task exit
D (2180) heap_init: New heap initialised at 0x3ffe0440
D (2185) heap_init: New heap initialised at 0x3ffe4350
I (2190) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
D (2199) spiram: Allocating block of size 32768 bytes
V (2204) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (2204) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (2204) intr_alloc: Connected src 16 to int 9 (cpu 0)
--- GOING...I tried to setup proper JTAG GDB debug in Eclipse to try and see where exactly it gets stuck, but as this happens before entering app_main I could not debug anything.
So far it seems like it is getting stuck somewhere in mupgrade_version_fallback_task. I'm not sure about inner workings of that task, but what also got my suspicion (aside from missing brackets in the comparison) was that the task is created without specifying core. So I tried doing just that and so far it seems to be starting normally:
xTaskCreatePinnedToCore(mupgrade_version_fallback_task, "mupgrade_version_fallback", 4 * 1024,
NULL, CONFIG_MDF_TASK_DEFAULT_PRIOTY + 5, NULL, CONFIG_MDF_TASK_PINNED_TO_CORE);It worth noting that it started when I used both 0 or 1 instead of CONFIG_MDF_TASK_PINNED_TO_CORE macro, so this may as well be just coincidence. I did not try if the actual fallback process works and as I see it I probably never will and rather implement it using IDF OTA fallback functions.
VitorBFreitas
commented
1 year ago Thanks for share your tests! I'm sure this will help those who get stuck on it.
Environment
Problem Description
ESP32 doesn't complete boot with mupgrade fallback version flag with two cores enabled after update from idf 4.4.1 to 4.4.2
Expected Behavior
ESP32 boot normally
Actual Behavior
ESP32 freeze while booting
Steps to reproduce
Code to reproduce this issue
Mupgrade example at esp-mdf\examples\function_demo\mupgrade
Debug Logs