"init_rom_log(255): Failed to set ROM log scheme" Causes crash when (Boot ROM Behavior: Log on GPIO High) (IDFGH-11799)

[SukuWc]

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.

v1.2.27-53-g05fbe4dd

Espressif SoC revision.

ESP32-S3 (QFN56) (revision v0.1)

Operating System used.

Linux

How did you build your project?

Command line with idf.py

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

None

Development Kit.

ESP32-S3 custom board

Power Supply used.

USB

What is the expected behavior?

Program execution should start normally without any crash when building with the docker image latest from docker hub

What is the actual behavior?

The processor crashes and stays in a crash loop.

Steps to reproduce.

• Use a board that has previously been running successfully with Boot ROM Behavior: Log on GPIO High
• Build a project the same project using idf:latest
• Flash the binary onto the board
• E (145) cpu_start: __esp_system_init_fn_init_rom_log(255): Failed to set ROM log scheme
• Rebuild the project using idf:v5.1.2
• Flash the binary onto the board the problem goes away!

Debug Logs.

--- esp-idf-monitor 1.3.4 on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

E (145) cpu_start: __esp_system_init_fn_init_rom_log(255): Failed to set ROM log scheme
E (145) cpu_start: init function 0x4200335c has failed (0x103), aborting
0x4200335c: __esp_system_init_fn_init_rom_log at /opt/esp/idf/components/esp_system/startup_funcs.c:250


abort() was called at PC 0x42003eef on core 0
0x42003eef: do_system_init_fn at /opt/esp/idf/components/esp_system/startup.c:129

More Information.

I am using docker to build the project. When using idf:latest I encounter this issue. When using idf:v5.1.2 the issue is not present! Images from DockerHub were updated today to make sure I am running in up-to-date environments

[ESP-Marius]

Seems like this error check was just added recently, which is why it works fine on 5.1.2 for you.

I'll take a look at it

[stephendpmurphy]

Any updates on this item? Also just updated and bumped my CI to use v5.2 and my builds now won't run.

[ESP-Marius]

Any updates on this item

@stephendpmurphy Fix is already merged internally, but we've had some big infrastructure changes in CI recently, so nothing has been able to sync to Github. The fix should be included the next time our internal repo syncs to github (and hopefully this should happen soon...)