Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabling boot logs on ESP32-C3 causes infinite reset loops for load access fault. (IDFGH-7940) #9457

Closed
2 of 3 tasks
ermacv opened this issue Jul 29, 2022 · 1 comment
Closed
2 of 3 tasks
Assignees
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@ermacv
Copy link

ermacv commented Jul 29, 2022

Environment

  • Development Kit: none
  • Kit version none
  • Module or chip used: ESP32-C3
  • IDF version (run git describe --tags to find it): v5.0-dev-3954-g271f4e4c40
  • Build System: idf.py
  • Compiler version (run xtensa-esp32-elf-gcc --version to find it): 11.2.0
  • Operating System: Ubuntu 22.04
  • Using an IDE?: No
  • Power Supply: USB

Problem Description

When boot rom logs are set to disabled (CONFIG_BOOT_ROM_LOG_ALWAYS_OFF=y in sdkconfig) for ESP32-C3 that causes infinite reset loops for load access fault. Hardware revision is 3.

It also seems that on some ESP32-C3 MCUs the issue cannot be reproduced even they have the same HW revision number. So it should be tested on multiple MCUs.

Expected Behavior

No infinite reset loops for load access fault.

Actual Behavior

infinite reset loops for load access fault.

Steps to reproduce

Use ESP32-C3 MCU with examples/get-started/hello_world example with default generated sdkconfig except that option CONFIG_BOOT_ROM_LOG_ALWAYS_OFF should be set to y (CONFIG_BOOT_ROM_LOG_ALWAYS_OFF=y ).

Code to reproduce this issue

examples/get-started/hello_world example with default generated sdkconfig except that option CONFIG_BOOT_ROM_LOG_ALWAYS_OFF should be set to y (CONFIG_BOOT_ROM_LOG_ALWAYS_OFF=y ).

Debug Logs

Just after device flashing:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xd (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6108,len:0x16ac
load:0x403ce000,len:0x954
load:0x403cf600,len:0x2dc0
entry 0x403ce000
I (30) boot: ESP-IDF v5.0-dev-3954-g271f4e4c40 2nd stage bootloader
I (30) boot: compile time 15:25:29
I (30) boot: chip revision: 3
I (34) boot.esp32c3: SPI Speed      : 80MHz
I (38) boot.esp32c3: SPI Mode       : DIO
I (43) boot.esp32c3: SPI Flash Size : 2MB
I (48) boot: Enabling RNG early entropy source...
I (53) boot: Partition Table:
I (57) boot: ## Label            Usage          Type ST Offset   Length
I (64) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (71) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (79) boot:  2 factory          factory app      00 00 00010000 00100000
I (86) boot: End of partition table
I (91) esp_image: segment 0: paddr=00010020 vaddr=3c020020 size=07660h ( 30304) map
I (104) esp_image: segment 1: paddr=00017688 vaddr=3fc8a800 size=014f0h (  5360) load
I (108) esp_image: segment 2: paddr=00018b80 vaddr=40380000 size=07498h ( 29848) load
I (121) esp_image: segment 3: paddr=00020020 vaddr=42000020 size=14470h ( 83056) map
I (138) esp_image: segment 4: paddr=00034498 vaddr=40387498 size=0326ch ( 12908) load
I (140) esp_image: segment 5: paddr=0003770c vaddr=50000010 size=00010h (    16) load
I (147) boot: Loaded app from partition at offset 0x10000
I (149) boot: Disabling RNG early entropy source...
I (166) cpu_start: Pro cpu up.
Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.

Stack dump detected
Core  0 register dump:
MEPC    : 0x4200e1c6  RA      : 0x4200e1ba  SP      : 0x3fcde1b0  GP      : 0x3fc8b000  
0x4200e1c6: vprintf at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vprintf.c:34 (discriminator 5)

0x4200e1ba: vprintf at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vprintf.c:31

TP      : 0x00000000  T0      : 0x4005890e  T1      : 0x00000000  T2      : 0x0000bf49  
S0/FP   : 0x00000000  S1      : 0x3c025058  A0      : 0x00000000  A1      : 0x3fcde20c  
A2      : 0x00000001  A3      : 0x00000004  A4      : 0x600c2000  A5      : 0x3fce0000  
A6      : 0x000000c0  A7      : 0x00000000  S2      : 0x3fcde20c  S3      : 0x3fcde20c  
S4      : 0x00000000  S5      : 0x00000000  S6      : 0x00000018  S7      : 0x00000000  
S8      : 0x00020020  S9      : 0x00010020  S10     : 0x00000006  S11     : 0x3fcde3cc  
T3      : 0x00000000  T4      : 0x00000000  T5      : 0x03ffffff  T6      : 0xbfffffff  
MSTATUS : 0x00001881  MTVEC   : 0x40380001  MCAUSE  : 0x00000005  MTVAL   : 0x00000008  
0x40380001: _vector_table at ??:?

MHARTID : 0x00000000  


Backtrace:


vprintf (fmt=<optimized out>, ap=<optimized out>) at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vprintf.c:34
34      /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vprintf.c: No such file or directory.
#0  vprintf (fmt=<optimized out>, ap=<optimized out>) at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/newlib/newlib/libc/stdio/vprintf.c:34
#1  0x4201447e in esp_log_writev (level=level@entry=ESP_LOG_INFO, tag=tag@entry=0x3c024d24 "", format=format@entry=0x3c025058 "", args=args@entry=0x3fcde20c) at /home/vlad/esp/esp-idf/components/log/log.c:200
#2  0x40389024 in esp_log_write (level=level@entry=ESP_LOG_INFO, tag=tag@entry=0x3c024d24 "", format=format@entry=0x3c025058 "") at /home/vlad/esp/esp-idf/components/log/log.c:210
#3  0x4200740a in esp_efuse_utility_burn_chip () at /home/vlad/esp/esp-idf/components/efuse/esp32c3/esp_efuse_utility.c:160
#4  0x42006d50 in esp_efuse_utility_burn_efuses () at /home/vlad/esp/esp-idf/components/efuse/src/esp_efuse_utility.c:171
#5  0x420068f0 in esp_efuse_write_field_blob (field=<optimized out>, src=src@entry=0x3fcde2ac, src_size_bits=src_size_bits@entry=2) at /home/vlad/esp/esp-idf/components/efuse/src/esp_efuse_api.c:97
#6  0x4200680e in esp_efuse_set_rom_log_scheme (log_scheme=<optimized out>, log_scheme@entry=ESP_EFUSE_ROM_LOG_ALWAYS_OFF) at /home/vlad/esp/esp-idf/components/efuse/esp32c3/esp_efuse_fields.c:46
#7  0x403804cc in call_start_cpu0 () at /home/vlad/esp/esp-idf/components/esp_system/port/cpu_start.c:633
ELF file SHA256: 9b066f76e606a3a0

Rebooting...
ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x403805c6
0x403805c6: esp_restart_noos_dig at /home/vlad/esp/esp-idf/components/esp_system/esp_system.c:46 (discriminator 1)

SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6108,len:0x16ac
load:0x403ce000,len:0x954
load:0x403cf600,len:0x2dc0
entry 0x403ce000

Other items if possible

  • sdkconfig file (attach the sdkconfig file from your project folder)
  • elf file in the build folder (note this may contain all the code details and symbols of your project.)
  • coredump (This provides stacks of tasks.)
    elf_sdkconfig.zip
@espressif-bot espressif-bot added the Status: Opened Issue is new label Jul 29, 2022
@github-actions github-actions bot changed the title Disabling boot logs on ESP32-C3 causes infinite reset loops for load access fault. Disabling boot logs on ESP32-C3 causes infinite reset loops for load access fault. (IDFGH-7940) Jul 29, 2022
@ESP-Marius
Copy link
Collaborator

Seems like the functions used to disable the ROM logging tries to print with esp_log which aint initialized at this point.

We'll fix this.

Thanks for reporting the issue.

@espressif-bot espressif-bot added Status: Reviewing Issue is being reviewed Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Resolution: Done Issue is done internally and removed Status: Opened Issue is new Status: Reviewing Issue is being reviewed Resolution: NA Issue resolution is unavailable labels Aug 1, 2022
espressif-bot pushed a commit that referenced this issue Aug 12, 2022
Functions used for burning this efuse would log, but at this point
esp_log is not initialized. Moved to a later point in the startup process.

Closes #9457
duncandrennan pushed a commit to duncandrennan/esp-idf that referenced this issue Nov 19, 2022
Functions used for burning this efuse would log, but at this point
esp_log is not initialized. Moved to a later point in the startup process.

Closes espressif#9457
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

3 participants