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

Fatal Error not reboot (IDFGH-13506) #14400

Closed
3 tasks done
andres-st opened this issue Aug 19, 2024 · 7 comments
Closed
3 tasks done

Fatal Error not reboot (IDFGH-13506) #14400

andres-st opened this issue Aug 19, 2024 · 7 comments
Assignees
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@andres-st
Copy link

andres-st commented Aug 19, 2024

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.

v5.2.2-526-g3cd08fff66

Espressif SoC revision.

ESP32-C6

Operating System used.

macOS

How did you build your project?

Command line with idf.py

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?

When we encounter cases where the chip prints the following message:

`
Print CPU 0 (current core) registers
Stack dump detected
Core 0 register dump:
MEPC : 0x4080a6d6 RA : 0x4080a6c0 SP : 0x4083da80 GP : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP : 0x408039a4 T0 : 0x40022494 T1 : 0x408099de T2 : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP : 0x4083ba48 S1 : 0xffffffff A0 : 0x00000000 A1 : 0x00000001
A2 : 0x4082c000 A3 : 0x4082c000 A4 : 0x600c5090 A5 : 0x00000000
A6 : 0x000052d1 A7 : 0xffff0fff S2 : 0x00000000 S3 : 0x4083dad8
S4 : 0x00000000 S5 : 0x40880000 S6 : 0x40880000 S7 : 0x40880000
S8 : 0x40880000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x600a4d68 T4 : 0x0fffffff T5 : 0x00010001 T6 : 0x00110000
MSTATUS : 0x00000000 MTVEC : 0xffffffff MCAUSE : 0x4083ba48 MTVAL : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000
Print CPU 0 (current core) registers
Core 0 register dump:
MEPC : 0x4080a6d6 RA : 0x4080a6c0 SP : 0x4083da80 GP : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP : 0x408039a4 T0 : 0x40022494 T1 : 0x408099de T2 : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP : 0x4083ba48 S1 : 0xffffffff A0 : 0x00000000 A1 : 0x00000001
A2 : 0x4082c000 A3 : 0x4082c000 A4 : 0x600c5090 A5 : 0x00000000
A6 : 0x000052d1 A7 : 0xffff0fff S2 : 0x00000000 S3 : 0x4083dad8
S4 : 0x00000000 S5 : 0x40880000 S6 : 0x40880000 S7 : 0x40880000
S8 : 0x40880000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x600a4d68 T4 : 0x0fffffff T5 : 0x00010001 T6 : 0x00110000
MSTATUS : 0x00000000 MTVEC : 0xffffffff MCAUSE : 0x4083ba48 MTVAL : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000
Print CPU 0 (current core) registers
Core 0 register dump:
MEPC : 0x4080a6d6 RA : 0x4080a6c0 SP : 0x4083da80 GP : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP : 0x408039a4 T0 : 0x40022494 T1 : 0x408099de T2 : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP : 0x4083ba48 S1 : 0xffffffff A0 : 0x00000000 A1 : 0x00000001
A2 : 0x4082c000 A3 : 0x4082c000 A4 : 0x600c5090 A5 : 0x00000000
A6 : 0x000052d1 A7 : 0xffff0fff S2 : 0x00000000 S3 : 0x4083dad8
S4 : 0x00000000 S5 : 0x40880000 S6 : 0x40880000 S7 : 0x40880000
S8 : 0x40880000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x600a4d68 T4 : 0x0fffffff T5 : 0x00010001 T6 : 0x00110000
MSTATUS : 0x00000000 MTVEC : 0xffffffff MCAUSE : 0x4083ba48 MTVAL : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000
Print CPU 0 (current core) registers
Core 0 register dump:
MEPC : 0x4080a6d6 RA : 0x4080a6c0 SP : 0x4083da80 GP : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
(inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP : 0x408039a4 T0 : 0x40022494 T1 : 0x408099de T2 : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP : 0x4083ba48 S1 : 0xffffffff A0 : 0x00000000 A1 : 0x00000001
A2 : 0x4082c000 A3 : 0x4082c000 A4 : 0x600c5090 A5 : 0x00000000
A6 : 0x000052d1 A7 : 0xffff0fff S2 : 0x00000000 S3 : 0x4083dad8
S4 : 0x00000000 S5 : 0x40880000 S6 : 0x40880000 S7 : 0x40880000
S8 : 0x40880000 S9 : 0x00000000 S10 : 0x00000000 S11 : 0x00000000
T3 : 0x600a4d68 T4 : 0x0fffffff T5 : 0x00010001 T6 : 0x00110000
MSTATUS : 0x00000000 MTVEC : 0xffffffff MCAUSE : 0x4083ba48 MTVAL : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000


`

What is the actual behavior?

Instead, it keeps printing the same message.

We have a function that detects if there is no more memory or if there are memory leaks and restarts the system at 75KB.

We also have the CONFIG_ESP_SYSTEM_PANIC_PRINT_REBOOT configuration set in the sdkconfig.

We are trying to find a method that detects these types of panics and restarts the system, but we haven’t found any in the documentation. We want this as a backup solution.

We do not use the vPortYield function nor xQueueReceive in our code.

Steps to reproduce.

We actually do not know what triggers this error. However, it happens when the chip has been running for at least 24 hours or more.

The firmware runs a WiFi-Mesh using the base of MDF-MWifi. and the board also has 8 sensors. and they send all this information to our Root.

Debug Logs.

Print CPU 0 (current core) registers
Stack dump detected
Core  0 register dump:
MEPC    : 0x4080a6d6  RA      : 0x4080a6c0  SP      : 0x4083da80  GP      : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP      : 0x408039a4  T0      : 0x40022494  T1      : 0x408099de  T2      : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP   : 0x4083ba48  S1      : 0xffffffff  A0      : 0x00000000  A1      : 0x00000001
A2      : 0x4082c000  A3      : 0x4082c000  A4      : 0x600c5090  A5      : 0x00000000
A6      : 0x000052d1  A7      : 0xffff0fff  S2      : 0x00000000  S3      : 0x4083dad8
S4      : 0x00000000  S5      : 0x40880000  S6      : 0x40880000  S7      : 0x40880000
S8      : 0x40880000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x600a4d68  T4      : 0x0fffffff  T5      : 0x00010001  T6      : 0x00110000
MSTATUS : 0x00000000  MTVEC   : 0xffffffff  MCAUSE  : 0x4083ba48  MTVAL   : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000
Print CPU 0 (current core) registers
Core  0 register dump:
MEPC    : 0x4080a6d6  RA      : 0x4080a6c0  SP      : 0x4083da80  GP      : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP      : 0x408039a4  T0      : 0x40022494  T1      : 0x408099de  T2      : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP   : 0x4083ba48  S1      : 0xffffffff  A0      : 0x00000000  A1      : 0x00000001
A2      : 0x4082c000  A3      : 0x4082c000  A4      : 0x600c5090  A5      : 0x00000000
A6      : 0x000052d1  A7      : 0xffff0fff  S2      : 0x00000000  S3      : 0x4083dad8
S4      : 0x00000000  S5      : 0x40880000  S6      : 0x40880000  S7      : 0x40880000
S8      : 0x40880000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x600a4d68  T4      : 0x0fffffff  T5      : 0x00010001  T6      : 0x00110000
MSTATUS : 0x00000000  MTVEC   : 0xffffffff  MCAUSE  : 0x4083ba48  MTVAL   : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000
Print CPU 0 (current core) registers
Core  0 register dump:
MEPC    : 0x4080a6d6  RA      : 0x4080a6c0  SP      : 0x4083da80  GP      : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP      : 0x408039a4  T0      : 0x40022494  T1      : 0x408099de  T2      : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP   : 0x4083ba48  S1      : 0xffffffff  A0      : 0x00000000  A1      : 0x00000001
A2      : 0x4082c000  A3      : 0x4082c000  A4      : 0x600c5090  A5      : 0x00000000
A6      : 0x000052d1  A7      : 0xffff0fff  S2      : 0x00000000  S3      : 0x4083dad8
S4      : 0x00000000  S5      : 0x40880000  S6      : 0x40880000  S7      : 0x40880000
S8      : 0x40880000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x600a4d68  T4      : 0x0fffffff  T5      : 0x00010001  T6      : 0x00110000
MSTATUS : 0x00000000  MTVEC   : 0xffffffff  MCAUSE  : 0x4083ba48  MTVAL   : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000
Print CPU 0 (current core) registers
Core  0 register dump:
MEPC    : 0x4080a6d6  RA      : 0x4080a6c0  SP      : 0x4083da80  GP      : 0x40821c50
0x4080a6d6: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 1)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 1)
0x4080a6c0: vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:652 (discriminator 2)
 (inlined by) vPortYield at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:627 (discriminator 2)

TP      : 0x408039a4  T0      : 0x40022494  T1      : 0x408099de  T2      : 0x31313131
0x408039a4: esp_flash_read_encrypted at /Users/andres/esp/esp-idf/components/spi_flash/esp_flash_api.c:1134
0x40022494: multi_heap_internal_unlock in ROM
0x408099de: xQueueGenericSend at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1144

S0/FP   : 0x4083ba48  S1      : 0xffffffff  A0      : 0x00000000  A1      : 0x00000001
A2      : 0x4082c000  A3      : 0x4082c000  A4      : 0x600c5090  A5      : 0x00000000
A6      : 0x000052d1  A7      : 0xffff0fff  S2      : 0x00000000  S3      : 0x4083dad8
S4      : 0x00000000  S5      : 0x40880000  S6      : 0x40880000  S7      : 0x40880000
S8      : 0x40880000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x600a4d68  T4      : 0x0fffffff  T5      : 0x00010001  T6      : 0x00110000
MSTATUS : 0x00000000  MTVEC   : 0xffffffff  MCAUSE  : 0x4083ba48  MTVAL   : 0x4080a016
0x4080a016: xQueueReceive at /Users/andres/esp/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1659

MHARTID : 0x40880000



More Information.

We have tried with many versions of esp idf and in the end it always fails.

@andres-st andres-st added the Type: Bug bugs in IDF label Aug 19, 2024
@github-actions github-actions bot changed the title Fatal Error not reboot Fatal Error not reboot (IDFGH-13506) Aug 19, 2024
@espressif-bot espressif-bot added the Status: Opened Issue is new label Aug 19, 2024
@offgrid88
Copy link

it's possible that the issue you're encountering could be related to strapping pins, especially considering the specific context of the ESP32 microcontroller. Strapping pins are used on the ESP32 to determine the boot mode and other initial configuration settings at startup. Incorrect settings or issues with these pins can lead to abnormal behavior, including failures during boot or operation. Can you test the same code on a dev board and try to reproduce the crash

@ESP-Marius
Copy link
Collaborator

Hmm, never seen a looping panic print like this.

Actually, looking at the register values some of them seem wrong/impossible? MTVEC : 0xffffffff MCAUSE : 0x4083ba48 does not seem like valid values to me.

We have a function that detects if there is no more memory or if there are memory leaks and restarts the system at 75KB.

Are you able to show me this function? Do the error still happen if you dont use this one?

Any more information/logs you could provide would be helpful.

@ESP-Marius
Copy link
Collaborator

Did you by any chance disable logs?

If we get a task WDT and CONFIG_ESP_TASK_WDT_PANIC=n then you would get periodic dumps like this when the WDT triggers, but no reboot.

If logs are also disabled then you'll miss the message telling you what is actually happening, i.e. a WDT.

@espressif-bot espressif-bot added Status: Reviewing Issue is being reviewed and removed Status: Opened Issue is new labels Aug 20, 2024
@andres-st
Copy link
Author

@ESP-Marius Thanks for the replies.

Did you by any chance disable logs?

We do disable some of the logs:

esp_log_level_set("*", ESP_LOG_NONE);
esp_log_level_set("gpio", ESP_LOG_NONE);
esp_log_level_set("wifi", ESP_LOG_NONE);
esp_log_level_set("wifi_init", ESP_LOG_NONE);
esp_log_level_set("mesh", ESP_LOG_NONE);
esp_log_level_set("mwifi", ESP_LOG_NONE);
esp_log_level_set("httpd", ESP_LOG_NONE);
esp_log_level_set("MESH", ESP_LOG_DEBUG);
esp_log_level_set("mesh_ota_check", ESP_LOG_VERBOSE);
esp_log_level_set("mesh_ota_node", ESP_LOG_VERBOSE);
esp_log_level_set("REG", ESP_LOG_DEBUG);
esp_log_level_set("WSK", ESP_LOG_DEBUG);
esp_log_level_set("OTA", ESP_LOG_DEBUG);
esp_log_level_set("I2C", ESP_LOG_DEBUG);
esp_log_level_set("I2S", ESP_LOG_DEBUG);
esp_log_level_set(TAG, ESP_LOG_DEBUG);

We also had the CONFIG_ESP_TASK_WDT_PANIC=n so maybe this could be it, I will be trying to reproduce the error now.

Are you able to show me this function? Do the error still happen if you dont use this one?

Here it is:

uint32_t print_free_heap(const char *location, uint32_t last_heap, bool _print)
{
    uint32_t free_heap = esp_get_free_heap_size();
    if (_print)
    {
        printf(ANSI_COLOR_YELLOW);
        printf("%s: ", location);
        printf(ANSI_COLOR_RESET);
        printf(" Free heap: ");
        printf("%lu\t", free_heap);

        if (last_heap > free_heap)
        {
            printf(ANSI_COLOR_RED);
            printf("*\t");
            printf("%d\n", free_heap - last_heap);
            printf(ANSI_COLOR_RESET);
        }
        else if (last_heap < free_heap)
        {
            printf(ANSI_COLOR_GREEN);
            printf("*\t");
            printf("%d\n", free_heap - last_heap);
            printf(ANSI_COLOR_RESET);
        }
        else
        {
            printf("*\t");
            printf("%d\n", free_heap - last_heap);
        }
    }
    return free_heap;
}

// In the main function:
uint32_t min_mem = 75000;
while(true)
{
        now = esp_timer_get_time() / 1000;
        if (last_time + 1000 < now)
        {
            the_state.mem_total_heap = print_free_heap("End main", the_state.mem_total_heap, true);
            if (the_state.mem_total_heap < min_mem)
            {
                ESP_LOGW(TAG, ">> Restarting low memory");
                vTaskDelay(10);
                silent_restart();
            }
            last_time = now;
        }
}

The error stills happens even with the function activated or not.

@andres-st
Copy link
Author

@offgrid88 That couldn’t be it. We just checked those, and if they were the strapping pins, the microcontroller wouldn’t even start. But thanks!

@ESP-Marius
Copy link
Collaborator

@andres-st

esp_log_level_set("*", ESP_LOG_NONE);

Yeah, this explains it. What you are seeing here is the task wdt triggering (so not an actual fatal error). But since the log is turned off you dont see all the output from it.

You can try with CONFIG_ESP_TASK_WDT_PANIC=y, then if it happens it should do a full dump, which should give you a backtrace when idf.py monitor decodes it. That you help locate a bit what is happening when the watchdog is starved

@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: NA Issue resolution is unavailable and removed Status: Reviewing Issue is being reviewed labels Aug 26, 2024
@andres-st
Copy link
Author

@ESP-Marius Thanks for the fix!

Will you be adding this commit to the v5.2.2?

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

5 participants