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

What is "Double exception"? (IDFGH-1548) #3810

Closed
KaeLL opened this issue Jul 22, 2019 · 24 comments
Closed

What is "Double exception"? (IDFGH-1548) #3810

KaeLL opened this issue Jul 22, 2019 · 24 comments
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@KaeLL
Copy link
Contributor

KaeLL commented Jul 22, 2019

I've been getting this exception after isolating a corner case to trigger it. I tried looking online for information about it, and couldn't find anything but the xtensa ISA pdf file, in which it's said to be a vector of CPU exceptions rather than the exception itself.
What I want to know is: what is this class of exceptions? Why the ESP32 doesn't automatically reboots itself after this (class of) exception(s) is triggered with the "Print registers and reboot" option enabled for FreeRTOS? Is THIS supposed to be anything other than useless?

@github-actions github-actions bot changed the title What is "Double exception"? What is "Double exception"? (IDFGH-1548) Jul 22, 2019
@igrr
Copy link
Member

igrr commented Jul 23, 2019

@KaeLL Can you please share the output you get from the monitor when this issue happens? The interesting part is the beginning of the crash, the first couple of panic handler output cycles.

DoubleException happens when an exception happens while handling another exception. So there are two issues here: first is that the panic handler crashes (triggers the DoubleException) and second is that it keeps looping, reentering the panic handler and triggering the exception again.
With information from your monitor output, we can fix the first issue. Also we will modify the DoubleException vector to cause an RTC watchdog reset instead of entering the panic handler. This will provide less information but will be a better safeguard against the device being locked up.

@KaeLL
Copy link
Contributor Author

KaeLL commented Jul 23, 2019

Guru Meditation Error: Core  1 panic'ed (Double exception)
 1 1 1 1 1���? 1���? 1���?
Guru Meditation Error: Core  1 panic'ed (Double except�
Guru Meditation Error: Core  1 panic'ed (Double exception)

Unhelpful, I know. But that's all that it prints. It should be noticed that the app was compiled with Info level log

Here's the complete log of all runs

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6684
load:0x40078000,len:15664
load:0x40080400,len:5696
entry 0x400806a8
I (797) cpu_start: Pro cpu up.
I (797) cpu_start: Application information:
I (797) cpu_start: Project name:     TEST
I (800) cpu_start: App version:      0.2.1-dirty
I (806) cpu_start: Compile time:     Jul  8 2019 18:04:32
I (812) cpu_start: ELF file SHA256:  ae32296154201836...
I (818) cpu_start: ESP-IDF:          v4.0-dev-1136-g28f1cdf-dirty
I (825) cpu_start: Starting app cpu, entry point is 0x40081214
0x40081214: call_start_cpu1 at ~/Documents/VSCode/esp-idf/components/esp32/cpu_start.c:298

W (831) cpu_start: Flash encryption mode is DEVELOPMENT
I (0) cpu_start: App cpu up.
I (841) heap_init: Initializing. RAM available for dynamic allocation:
I (848) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (854) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (860) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (866) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (872) heap_init: At 3FFCB330 len 00014CD0 (83 KiB): DRAM
I (878) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (885) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (891) heap_init: At 40097A44 len 000085BC (33 KiB): IRAM
I (897) cpu_start: Pro cpu start user code
I (936) spi_flash: detected chip: generic
I (936) spi_flash: flash io: dio
I (936) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (984) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (989) main: APPLICATION VERSION: 0.2.1-dirty
I (989) main: PROJECT NAME: TEST
I (994) main: COMPILE DATE: Jul  8 2019 18:04:32
I (999) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (1004) main: esp_register_shutdown_handler: 0
I (1009) softwd: WD OK
I (1014) gpio: GPIO[16]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1019) gpio: GPIO[22]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1029) gpio: GPIO[13]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1039) gpio: GPIO[14]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1049) gpio: GPIO[5]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1069) gpio: GPIO[12]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1269) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
W (6789) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (9084) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (11204) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (13339) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

I (14409) main: initializing NFC... 
I (14414) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 
I (14424) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 1| Intr:1 
I (14429) main: initializing Bluetooth

I (14429) BTDM_INIT: BT controller compile version [7a7769b]
I (14439) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (14529) phy: phy_version: 4100, 2a5dd04, Jan 23 2019, 21:00:07, 0, 0
I (14809) BEACON: Register callback
I (14819) BEACON: Start scanning...
W (31624) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (34269) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

I (61009) softwd: WD OK
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x4010ecb8  PS      : 0x00060e30  A0      : 0x8010edca  A1      : 0x3ffe1b00  
0x4010ecb8: cnx_node_leave at ??:?

A2      : 0x3ffc6750  A3      : 0x3ffc6754  A4      : 0x00000000  A5      : 0x00000000  
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x8010ecb8  A9      : 0x3ffe1aa0  
A10     : 0x3ffc67ae  A11     : 0x00000061  A12     : 0x00000062  A13     : 0x02028354  
A14     : 0x40021000  A15     : 0x01800101  SAR     : 0x00000000  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

ELF file SHA256: ae32296154201836951dd857974a71b30d727be7931fd32b77af4ab2c44734d9

Backtrace: 0x4010ecb5:0x3ffe1b00 0x4010edc7:0x74828249 |<-CORRUPTED
0x4010ecb5: cnx_node_leave at ??:?

0x4010edc7: cnx_node_join at ??:?


Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6684
load:0x40078000,len:15664
load:0x40080400,len:5696
entry 0x400806a8
I (797) cpu_start: Pro cpu up.
I (797) cpu_start: Application information:
I (797) cpu_start: Project name:     TEST
I (800) cpu_start: App version:      0.2.1-dirty
I (806) cpu_start: Compile time:     Jul  8 2019 18:04:32
I (812) cpu_start: ELF file SHA256:  ae32296154201836...
I (818) cpu_start: ESP-IDF:          v4.0-dev-1136-g28f1cdf-dirty
I (825) cpu_start: Starting app cpu, entry point is 0x40081214
0x40081214: call_start_cpu1 at ~/Documents/VSCode/esp-idf/components/esp32/cpu_start.c:298

W (831) cpu_start: Flash encryption mode is DEVELOPMENT
I (822) cpu_start: App cpu up.
I (841) heap_init: Initializing. RAM available for dynamic allocation:
I (848) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (854) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (860) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (866) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (872) heap_init: At 3FFCB330 len 00014CD0 (83 KiB): DRAM
I (879) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (885) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (891) heap_init: At 40097A44 len 000085BC (33 KiB): IRAM
I (897) cpu_start: Pro cpu start user code
I (936) spi_flash: detected chip: generic
I (936) spi_flash: flash io: dio
I (937) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (984) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (989) main: APPLICATION VERSION: 0.2.1-dirty
I (989) main: PROJECT NAME: TEST
I (994) main: COMPILE DATE: Jul  8 2019 18:04:32
I (999) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (1004) main: esp_register_shutdown_handler: 0
I (1009) softwd: WD OK
I (1014) gpio: GPIO[16]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1019) gpio: GPIO[22]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1029) gpio: GPIO[13]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1039) gpio: GPIO[14]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1049) gpio: GPIO[5]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1069) gpio: GPIO[12]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1269) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
W (6784) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (9214) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (11329) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

I (12399) main: initializing NFC... 
I (12399) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 
I (12414) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 1| Intr:1 
I (12414) main: initializing Bluetooth

I (12419) BTDM_INIT: BT controller compile version [7a7769b]
I (12424) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (12519) phy: phy_version: 4100, 2a5dd04, Jan 23 2019, 21:00:07, 0, 0
I (12789) BEACON: Register callback
I (12799) BEACON: Start scanning...
W (13819) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (16579) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

Guru Meditation Error: Core  1 panic'ed (Double exception)
 1 1 1 1 1���? 1���? 1���?ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6684
load:0x40078000,len:15664
load:0x40080400,len:5696
entry 0x400806a8
I (797) cpu_start: Pro cpu up.
I (797) cpu_start: Application information:
I (797) cpu_start: Project name:     TEST
I (800) cpu_start: App version:      0.2.1-dirty
I (806) cpu_start: Compile time:     Jul  8 2019 18:04:32
I (812) cpu_start: ELF file SHA256:  ae32296154201836...
I (818) cpu_start: ESP-IDF:          v4.0-dev-1136-g28f1cdf-dirty
I (824) cpu_start: Starting app cpu, entry point is 0x40081214
0x40081214: call_start_cpu1 at ~/Documents/VSCode/esp-idf/components/esp32/cpu_start.c:298

W (831) cpu_start: Flash encryption mode is DEVELOPMENT
I (0) cpu_start: App cpu up.
I (841) heap_init: Initializing. RAM available for dynamic allocation:
I (848) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (854) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (860) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (866) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (872) heap_init: At 3FFCB330 len 00014CD0 (83 KiB): DRAM
I (878) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (884) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (891) heap_init: At 40097A44 len 000085BC (33 KiB): IRAM
I (897) cpu_start: Pro cpu start user code
I (936) spi_flash: detected chip: generic
I (936) spi_flash: flash io: dio
I (936) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (984) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (989) main: APPLICATION VERSION: 0.2.1-dirty
I (989) main: PROJECT NAME: TEST
I (994) main: COMPILE DATE: Jul  8 2019 18:04:32
I (999) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (1004) main: esp_register_shutdown_handler: 0
I (1009) softwd: WD OK
I (1014) gpio: GPIO[16]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1019) gpio: GPIO[22]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1029) gpio: GPIO[13]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1039) gpio: GPIO[14]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1049) gpio: GPIO[5]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1069) gpio: GPIO[12]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1269) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
W (6774) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (9049) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (11154) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

I (12219) main: initializing NFC... 
I (12219) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 
I (12234) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 1| Intr:1 
I (12234) main: initializing Bluetooth

I (12239) BTDM_INIT: BT controller compile version [7a7769b]
I (12244) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (12339) phy: phy_version: 4100, 2a5dd04, Jan 23 2019, 21:00:07, 0, 0
I (12619) BEACON: Register callback
I (12629) BEACON: Start scanning...
W (14984) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (17384) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

Guru Meditation Error: Core  1 panic'ed (Double exception)
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6684
load:0x40078000,len:15664
load:0x40080400,len:5696
entry 0x400806a8
I (797) cpu_start: Pro cpu up.
I (797) cpu_start: Application information:
I (797) cpu_start: Project name:     TEST
I (800) cpu_start: App version:      0.2.1-dirty
I (806) cpu_start: Compile time:     Jul  8 2019 18:04:32
I (812) cpu_start: ELF file SHA256:  ae32296154201836...
I (818) cpu_start: ESP-IDF:          v4.0-dev-1136-g28f1cdf-dirty
I (824) cpu_start: Starting app cpu, entry point is 0x40081214
0x40081214: call_start_cpu1 at ~/Documents/VSCode/esp-idf/components/esp32/cpu_start.c:298

W (831) cpu_start: Flash encryption mode is DEVELOPMENT
I (0) cpu_start: App cpu up.
I (841) heap_init: Initializing. RAM available for dynamic allocation:
I (848) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (854) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM
I (860) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM
I (866) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM
I (872) heap_init: At 3FFCB330 len 00014CD0 (83 KiB): DRAM
I (878) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (884) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (891) heap_init: At 40097A44 len 000085BC (33 KiB): IRAM
I (897) cpu_start: Pro cpu start user code
I (936) spi_flash: detected chip: generic
I (936) spi_flash: flash io: dio
I (936) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
[0;32mI (984) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (989) main: APPLICATION VERSION: 0.2.1-dirty
I (989) main: PROJECT NAME: TEST
I (994) main: COMPILE DATE: Jul  8 2019 18:04:32
I (999) main: IDF VERSION: v4.0-dev-1136-g28f1cdf-dirty
I (1004) main: esp_register_shutdown_handler: 0
I (1009) softwd: WD OK
I (1014) gpio: GPIO[16]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1019) gpio: GPIO[22]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1029) gpio: GPIO[13]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1039) gpio: GPIO[14]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1049) gpio: GPIO[5]| InputEn: 1| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1069) gpio: GPIO[12]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 
I (1269) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
[0;33mW (6789) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (9394) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

W (11509) mbedtls: ssl_tls.c:5757 x509_verify_cert() returned -9984 (-0x2700)

I (12569) main: initializing NFC... 
I (12569) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 
I (12584) gpio: GPIO[33]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 1| Intr:1 
I (12584) main: initializing Bluetooth

I (12589) BTDM_INIT: BT controller compile version [7a7769b]
I (12594) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (12689) phy: phy_version: 4100, 2a5dd04, Jan 23 2019, 21:00:07, 0, 0
I (12974) BEACON: Register callback
I (12984) BEACON: Start scanning...
Guru Meditation Error: Core  1 panic'ed (Double except�

@KaeLL
Copy link
Contributor Author

KaeLL commented Mar 18, 2021

@user897943 are you sure your issue is even related to mine?

@igrr
Copy link
Member

igrr commented Mar 18, 2021

@user897943 Sorry that you are seeing this issue!
As @KaeLL points out, your issue seems to be unrelated to the original issue report here. IllegalInstruction is a different exception type than DoubleException, and the documentation page linked by @KaeLL describes the situations when it occurs. I am sorry but I don't understand why the vendor of your device thinks this issue is related.

From the crash dump, it looks like the a0 register value, which normally contains the return address of the function, is invalid. The instruction at PC is 00f01d22, which is a retw instruction. So the crash occurs upon a return from a function, when the return address is corrupted.
This might be a but in ESP-IDF, this might be a bug in the application. Without having more details, I'm afraid this issue isn't actionable from our side.

@chegewara
Copy link
Contributor

@user897943 You are using language that is insulting people from espressif, even if your issue is completely not related to this one, and honestly i dont expect you will apology.

Here is link that shows the part of issue from OP is caused by user code (wrong certificate)
Mbed-TLS/mbedtls#139

Also based on my experience and very few logs, i can guessing the double exception is related to low heap/RAM. Problems with ssl + BT in logs and double exception, which may occur when crash dump is being printed, but due to lack of heap it will lead to another exception. I saw it one or two times already, not in my projects thou.

@chegewara
Copy link
Contributor

chegewara commented Mar 20, 2021

It is a disgrace when a bug is unfixed for 2 years while customers are suffering daily problems

Is your bug related to this one? NO. Do you suffer due to not solved bug for 2 years? I doubt.
Did you read issue template at all? I dont think so

----------------------------- Delete below -----------------------------

**Reminder: If your issue is a general question, starts similar to "How do I..", or is related to 3rd party development kits/libs, please discuss this on our community forum at https://esp32.com instead.**

INSTRUCTIONS
============

Before submitting a new issue, please follow the checklist and try to find the answer.

- [ ] I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) 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.

If the issue cannot be solved after the steps before, please follow these instructions so we can get the needed information to help you in a quick and effective fashion.

1. Fill in all the fields under **Environment** marked with [ ] by picking the correct option for you in each case and deleting the others.
2. Describe your problem.
3. Include [debug logs from the "monitor" tool](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html#automatically-decoding-addresses), or [coredumps](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/core_dump.html).
4. Providing as much information as possible under **Other items if possible** will help us locate and fix the problem.
5. Use [Markdown](https://guides.github.com/features/mastering-markdown/) (see formatting buttons above) and the Preview tab to check what the issue will look like.
6. Delete these instructions from the above to the below marker lines before submitting this issue.

**IMPORTANT: If you do not follow these instructions and provide the necessary details, your issue may not be resolved.**

----------------------------- Delete above -----------------------------

## Environment

- Development Kit:      [ESP32-Wrover-Kit|ESP32-DevKitC|ESP32-PICO-Kit|ESP32-LyraT|ESP32-LyraTD-MSC|none]
- Kit version (for WroverKit/PicoKit/DevKitC): [v1|v2|v3|v4]
- Module or chip used:  [ESP32-WROOM-32|ESP32-WROOM-32D|ESP32-WROOM-32U|ESP32-WROVER|ESP32-WROVER-I|ESP32-WROVER-B|ESP32-WROVER-IB|ESP32-SOLO-1|ESP32-PICO-D4|ESP32]
- IDF version (run ``git describe --tags`` to find it):
    // v3.2-dev-1148-g96cd3b75c
- Build System:         [Make|CMake|idf.py]
- Compiler version (run ``xtensa-esp32-elf-gcc --version`` to find it):
    // 1.22.0-80-g6c4433a
- Operating System:     [Windows|Linux|macOS]
- (Windows only) environment type: [MSYS2 mingw32|ESP Command Prompt|Plain Command Prompt|PowerShell].
- Using an IDE?: [No|Yes (please give details)]
- Power Supply:         [USB|external 5V|external 3.3V|Battery]

## Problem Description

//Detailed problem description goes here.

### Expected Behavior

### Actual Behavior

### Steps to reproduce

1. step1
2. ...

// If possible, attach a picture of your setup/wiring here.


### Code to reproduce this issue

```cpp
// the code should be wrapped in the ```cpp tag so that it will be displayed better.
#include "esp_log.h"

void app_main()
{

}

// If your code is longer than 30 lines, GIST is preferred.

Debug Logs

Debug log goes here, should contain the backtrace, as well as the reset source if it is a crash.
Please copy the plain text here for us to search the error log. Or attach the complete logs but leave the main part here if the log is *too* long.

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.)

Your complain is like calling to doctor and saying, hey doctor, i am sick, heal me.

From your logs i can say you are having issue with TCP, not the double exception
(27390) TRANS_TCP: tcp_poll_read select error 113, errno = Software caused connection abort, fd = 52
Then how anyone can help you with your issue if we not even know which esp-idf version you are working with?
You are just trying to hijack someones else issue and spam it with useless info.

@KaeLL
Copy link
Contributor Author

KaeLL commented Mar 20, 2021

@chegewara He may have a point though. Now I think I understand what @user897943 is talking about.
The issue with DoubleException is the fact that it completely bricks the ESP32 to a state that it can't reset itself even with panic restart enabled. That's the problem, that the board needs a manual power cycle, which is a huge deal given the implications.
@chegewara you're also missing the fact that DoubleException is the exception thrown against the first exception, which is thrown by the CPU and/or IDF, making it hardly related to any app code. The first exception is indeed related to the app, and generally is our fault, but the second one, that happens while handling of the first one isn't, which is why filling up the bug report form won't be of much help. But I could be wrong, it could help, and I would've submitted all info had I had this issue in a non-NDA protected codebase.
The fact of the matter is this issue of DoubleException bricking the ESP32 and it not resetting itself is in fact lurking within IDF and it will continue to be so because of how rare and elusive it is. So far, I've seen only me and #6519 have that issue. The fact that it's a deal-breaking bug that it's hard to get people from Espressif to prioritize it only adds to the irony.

@chegewara
Copy link
Contributor

chegewara commented Mar 20, 2021

@KaeLL I am not saying this issue is less important or something, but using such language, in topic which is not an inch close to his, is not accepted in cultural community. It is hard to fix something when you dont know what is broken, but there is not much data to diagnose it. Like i said, double exception is something that may happen when there is crash in code, and after crash when core dump is generated and/or printed another exception occur due to memory shortage or memory corruption (caused by esp-idf or client code).
espressif/arduino-esp32#3280
espressif/arduino-esp32#2621
me-no-dev/ESPAsyncWebServer#519

Please check this. He instead of creating issue and filling issue template is trolling other users issues:
#5227 (comment)

EDIT i can find few more double exception issues, but not much info to narrow it down and usually it is user error

espressif/arduino-esp32#2686 (comment)

@KaeLL
Copy link
Contributor Author

KaeLL commented Mar 20, 2021

but using such language, in topic which is not an inch close to his, is not accepted in cultural community.
Please check this. He instead of creating issue and filling issue template is trolling other users issues:
#5227 (comment)

Tbh, I couldn't care less about it. I care only about the problem.

due to memory shortage or memory corruption (caused by esp-idf or client code).

Do you have any sources on this? Because I've looked into DoubeException (not on IDF as I don't have the expertise enough to understand the inner-workings of the chip and the assembly), and only got what @igrr said above 1.5 years ago. Or are you just taking Ibernstone's word for it? If you do have more information regarding this exception, please share it, as I'd love to know more about it, and perhaps we might even make this issue useful.

@chegewara
Copy link
Contributor

I remember that me-no-dev mentioned that once on gitter too, but i never got this issue personally, i think.
If i only could help with that issue i would do it for sure, like with many other issues i do.

@igrr
Copy link
Member

igrr commented Mar 21, 2021

@user897943 I'm sorry I didn't understand the core of your issue report first — I understand now that the chip doesn't restart after the panic occurs, and ELF file SHA256 is the last thing being printed. This is indeed a serious issue, although quite different than the one reported originally in this ticket by @KaeLL.

I believe this specific issue (lock-up when printing ELF file SHA256) has been fixed in commit fc03161. The fix was done in release v4.2, and was backported to release/v4.1, release/v4.0, release/v3.3 i.e. all currently maintained release branches.

@igrr
Copy link
Member

igrr commented Mar 21, 2021

Based on the info so far, I suppose your product is the Konnekted Alarm Panel based on the ESP32. According to the author, the software is based on the dev-esp32 branch of nodemcu, a Lua interpreter. At the moment, dev-esp32 branch of nodemcu is built using ESP-IDF 3.3.2. The fix I have mentioned has been merged into the 3.3 branch in commit 2705b76, and released in v3.3.3. It should be sufficient to update the esp-idf submodule pointer to v3.3.3 or v3.3.4 and re-build the application. Paging @heythisisnate — please let me know if this helps.

@heythisisnate
Copy link

@igrr thanks for the ping and the insight. Very helpful! I hope that this fix will solve the lockup problem that some Konnected users are having.
I've bumped the nodemcu firmware to use ESP-IDF 3.3.4 and rebuilt the Konnected application. I'm communicating offline with @user897943 for feedback. 🙌 🙌

@marcelstoer
Copy link

@igrr 🥇 absolutely fantastic customer service! You went above and beyond in your effort to get to the bottom of this. Even though this does not affect me personally I want to thank you as an ESP8266/ESP32/NodeMCU community member.

@Alvin1Zhang
Copy link
Collaborator

Thanks for reporting, feel free to reopen.

@KaeLL
Copy link
Contributor Author

KaeLL commented Apr 12, 2021

Also we will modify the DoubleException vector to cause an RTC watchdog reset instead of entering the panic handler. This will provide less information but will be a better safeguard against the device being locked up.

Was this implemented?

@espressif-bot espressif-bot added Resolution: Done Issue is done internally Status: Done Issue is done internally labels Apr 26, 2021
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

8 participants
@heythisisnate @marcelstoer @chegewara @igrr @KaeLL @Alvin1Zhang @espressif-bot and others