Constant Reboot Loop in thread_border_router example on ESP32-C6 and ESP32-S3 - ESP32H2
Description:
I am experiencing a continuous reboot loop when running the thread_border_router example from the ESP-Matter SDK. The issue persists across different hardware targets, specifically ESP32-C6 and ESP32-S3, suggesting a potential software regression or configuration conflict in the OpenThread/Matter stack integration.
Environment:
ESP-IDF Version: v5.4.1]
ESP-Matter Version: lates
Target Hardware: ESP32-C6 or ESP32-S3
Device as Border Router: (e.g., RCP connected via UART with esp32s3 or Standalone on C6)
Host OS: macOS
Steps to Reproduce:
Navigate to examples/thread_border_router.
Set target: idf.py set-target esp32s3.
Build and flash the project: idf.py build flash monitor.
Observe the serial output.
Observed Behavior:
The device enters a boot loop immediately after flashing. It fails to reach the application start. The logs show a SW_CPU_RESET (or Panic) shortly after the ROM bootloader hands over control to the application entry point. No OpenThread or Matter initialization logs are visible, suggesting the crash occurs during the early system startup or due to an invalid partition/memory configuration.
Expected Behavior:
The device should initialize the Thread network and stay stable, waiting for Matter commissioning over Bluetooth LE or Wi-Fi.
I have tested the project using both Octal Mode PSRAM and Quad Mode PSRAM configurations in sdkconfig to match my hardware, but the boot loop occurs in both scenarios.
This suggests that the issue is not a simple misconfiguration of the SPI mode,The crash happens consistently regardless of the PSRAM mode selected (Octal vs. Quad).
--- esp-idf-monitor 1.9.0 on /dev/cu.wchusbserial58960323601 115200
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x2b (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2820,len:0x15a0
load:0x403c8700,len:0x4
load:0x403c8704,len:0xc80
load:0x403cb700,len:0x2f0c
entry 0x403c8914
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)
Saved PC:0x40375d98
--- 0x40375d98: esp_restart_noos at /Users/kriso/esp-idf/components/esp_system/port/soc/esp32s3/system_internal.c:160
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2820,len:0x15a0
load:0x403c8700,len:0x4
load:0x403c8704,len:0xc80
load:0x403cb700,len:0x2f0c
entry 0x403c8914
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)
Saved PC:0x40375d98
--- 0x40375d98: esp_restart_noos at /Users/kriso/esp-idf/components/esp_system/port/soc/esp32s3/system_internal.c:160
SoC (eg: ESP32c6 or ESP32-s3):
Host Machine OS: mac
Host Machine Python version: 3.11
Constant Reboot Loop in thread_border_router example on ESP32-C6 and ESP32-S3 - ESP32H2
Description:
I am experiencing a continuous reboot loop when running the thread_border_router example from the ESP-Matter SDK. The issue persists across different hardware targets, specifically ESP32-C6 and ESP32-S3, suggesting a potential software regression or configuration conflict in the OpenThread/Matter stack integration.
Environment:
ESP-IDF Version: v5.4.1]
ESP-Matter Version: lates
Target Hardware: ESP32-C6 or ESP32-S3
Device as Border Router: (e.g., RCP connected via UART with esp32s3 or Standalone on C6)
Host OS: macOS
Steps to Reproduce:
Navigate to examples/thread_border_router.
Set target: idf.py set-target esp32s3.
Build and flash the project: idf.py build flash monitor.
Observe the serial output.
Observed Behavior:
The device enters a boot loop immediately after flashing. It fails to reach the application start. The logs show a SW_CPU_RESET (or Panic) shortly after the ROM bootloader hands over control to the application entry point. No OpenThread or Matter initialization logs are visible, suggesting the crash occurs during the early system startup or due to an invalid partition/memory configuration.
Expected Behavior:
The device should initialize the Thread network and stay stable, waiting for Matter commissioning over Bluetooth LE or Wi-Fi.
I have tested the project using both Octal Mode PSRAM and Quad Mode PSRAM configurations in sdkconfig to match my hardware, but the boot loop occurs in both scenarios.
This suggests that the issue is not a simple misconfiguration of the SPI mode,The crash happens consistently regardless of the PSRAM mode selected (Octal vs. Quad).