esp-idf: Scheduler not starting (IDFGH-9381)

Answers checklist.

I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v4.4.3-319-g26960f1734

Operating System used.

Linux

How did you build your project?

Command line with CMake

If you are using Windows, please specify command line type.

None

Development Kit.

Custom board

Power Supply used.

External 3.3V

What is the expected behavior?

Program should start executing

What is the actual behavior?

Program execution is blocked after:

I (105) boot: Defaulting to factory image
I (107) esp_image: segment 0: paddr=00400020 vaddr=3f400020 size=aec48h (715848) map
I (327) esp_image: segment 1: paddr=004aec70 vaddr=3ffbdb60 size=013a8h (  5032) load
I (329) esp_image: segment 2: paddr=004b0020 vaddr=400d0020 size=241fc0h (2367424) map
I (1045) esp_image: segment 3: paddr=006f1fe8 vaddr=3ffbef08 size=05808h ( 22536) load
I (1053) esp_image: segment 4: paddr=006f77f8 vaddr=40080000 size=1d504h (120068) load
I (1110) boot: Loaded app from partition at offset 0x400000
I (1110) boot: Disabling RNG early entropy source...
I (1116) psram: This chip is ESP32-D0WD
I (1117) spiram: Found 64MBit SPI RAM device
I (1117) spiram: SPI RAM mode: flash 80m sram 80m
I (1119) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (1123) cpu_start: Pro cpu up.
I (1125) cpu_start: Starting app cpu, entry point is 0x40081760
I (0) cpu_start: App cpu up.
I (1671) spiram: SPI SRAM memory test OK
I (1680) cpu_start: Pro cpu start user code
I (1680) cpu_start: cpu freq: 240000000
I (1680) cpu_start: Application information:
I (1681) cpu_start: Project name:     ElsIotModule
I (1684) cpu_start: App version:      1.1.1-beta-14-g5541c492
I (1687) cpu_start: Compile time:     Feb 10 2023 14:36:51
I (1690) cpu_start: ELF file SHA256:  5adf6b06c3673f43...
I (1693) cpu_start: ESP-IDF:          v4.4.3-319-g26960f1734
I (1697) heap_init: Initializing. RAM available for dynamic allocation:
I (1700) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (1703) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (1706) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (1709) heap_init: At 3FFD0710 len 0000F8F0 (62 KiB): DRAM
I (1713) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1716) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1719) heap_init: At 4009D504 len 00002AFC (10 KiB): IRAM
I (1722) spiram: Adding pool of 4083K of external SPI memory to heap allocator
I (1727) spi_flash: detected chip: generic
I (1729) spi_flash: flash io: dio
I (1756) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

Steps to reproduce.

I updated my stable project from version v4.4.3-1-gcc5640aef3 to v4.4.3-319-g26960f1734 and then this happens Changing back to commit v4.4.3-319-g7dde97d2d6 restores my project to stable again.

I have not been able to find a newer commit on branch release/v4.4 which makes execution working again. I have tried using v4.4.4.

Debug Logs.

No response

More Information.

efuses is used in the project!
ESP32-WROVER

About this issue

Original URL
State: closed
Created a year ago
Comments: 20 (3 by maintainers)

Most upvoted comments

v4.4.3-1-gcc5640aef3 is good without verbose log level for all modules but enabling verbose logging results in the same behaviour.

My thesis is that this happens due to a lot initialized variables and possibly global object constructors during startup. I plan to change the design to reduce the amount of data being handled by startup code. I will need look deeper into this in a couple of days. Now I have some other tasks to attend to.

ClaesIvarsson on Feb 20, 2023

The root cause seemed to be some tasks getting spinned up on core 1 before app_main ran and starving the idle task (cpu0 bootup process relies on the idle task for cpu1 to run at least once to signal that cpu1 boot up process is complete).

@ClaesIvarsson can we consider the problem solved on your end?

Sorry for not following up on this issue sooner (other more urgent tasks has been prioritized)

I was not able to confirm this thesis. I am using dual core functionality which makes this a possibility. The only tasks assigned to the second core is the WIFI task (CONFIG_ESP32_WIFI_TASK_PINNED_TO_CORE_1=y) and this is not started until later. User-created tasks are currently created with tskNO_AFFINITY. I will have a go at this problem again asap.

ClaesIvarsson on Apr 17, 2023