panic unhandled break instruction

[f.h-f.s.]

I am getting this unhandled debug exception, but I have no idea what is causing this issue.

Does anyone know what these functions do, and maybe why they cause unhandled BREAK instructions?

• 0x400832f9: huart_flow_off at ??:?
  0x4008366a: r_ld_acl_ssr_set at ??:?
  0x400816a8: wDev_ProcessFiq at ??:?
  
  0x40083b0d: r_rwble_isr at ??:?
  0x40083e72: r_rwbtdm_isr_wrapper at intc.c:?
  0x40081c3c: _xt_lowint1 at xtensa_vectors.o:?

Code: Select all

Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception)
Debug exception reason: BREAK instr
Register dump:
PC      : 0x00000000  PS      : 0x00000016  A0      : 0x80019fb8  A1      : 0x3ffc04e0
A2      : 0x4d4d4d4d  A3      : 0x3fff0000  A4      : 0x001dda5b  A5      : 0x00000022
0x4d4d4d4d: ?? ??:0

A6      : 0x000023f0  A7      : 0x3ffc0640  A8      : 0x80140e34  A9      : 0x5a5a5a5b
A10     : 0x00000001  A11     : 0x00000073  A12     : 0x00000069  A13     : 0x3ffc05d0
A14     : 0x00000001  A15     : 0x00060520  SAR     : 0x00000017  EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff
0x4000c2e0: ?? ??:0

0x4000c2f6: ?? ??:0


Backtrace: 0x00000000:0x3ffc04e0 0x40019fb8:0x3ffc0500 0x40046686:0x3ffc0530 0x40047518:0x3ffc0550 0x40048536:0x3ffc0570 0x40048675:0x3ffc0590 0x400832f9:0x3ffc05b0 0x4008366a:0x3ffc05d0 0x400816a8:0x3ffc0600
0x40019fb8: ?? ??:0

0x40046686: ?? ??:0

0x40047518: ?? ??:0

0x40048536: ?? ??:0

0x40048675: ?? ??:0

0x400832f9: huart_flow_off at ??:?

0x4008366a: r_ld_acl_ssr_set at ??:?

0x400816a8: wDev_ProcessFiq at ??:?

Code: Select all

Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception)
Debug exception reason: BREAK instr 
Register dump:
PC      : 0x00000000  PS      : 0x00000016  A0      : 0x80019fb8  A1      : 0x3ffc06f0  
A2      : 0x4d4d4d4d  A3      : 0x3fff0000  A4      : 0x002ac904  A5      : 0x00000022  
A6      : 0x000023f0  A7      : 0x3ffc0028  A8      : 0x80140794  A9      : 0x5a5a5a5b  
A10     : 0x00000001  A11     : 0x00000073  A12     : 0x00000069  A13     : 0x3ffc07e0  
A14     : 0x00000001  A15    0x4d4d4d4d: ?? ??:0
 : 0x00060320  SAR     : 0x00000017  EXCCAUSE: 0x00000001  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x00000000:0x3ffc06f0 0x40019fb8:0x3ffc0710 0x40046686:0x3ffc0740 0x40047518:0x3ffc0760 0x400x4000c2e0: ?? ??:0
0x4000c2f6: ?? ??:0
048536:0x3ffc0780 0x40048675:0x3ffc07a0 0x40083b0d:0x3ffc07c0 0x40083e72:0x3ffc07e0 0x40081c3c:0x3ffc0810

Rebooting...
0x40019fb8: ?? ??:0
0x40046686: ?? ??:0
0x40047518: ?? ??:0
0x40048536: ?? ??:0
0x40048675: ?? ??:0
0x40083b0d: r_rwble_isr at ??:?
0x40083e72: r_rwbtdm_isr_wrapper at intc.c:?
0x40081c3c: _xt_lowint1 at xtensa_vectors.o:?

[ESP_Sprite]

That's interesting; your register dump is entirely bogus (PC=0 should give invalid load or something, not debug instruction). Does the serial output before that contain anything relevant? What code are you running?

[f.h-f.s.]

The last debug message logged was a confirmation of a https get function.
I am running my own code which does a ble scan, connects to the Azure IoT Hub and does some https requests.
This crash only happens sporadically.

Also interesting is the double reset, which seems to happen on every crash:

Code: Select all

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0008,len:8
load:0x3fff0010,len:4412
ho 0 tail 12 room 4
load:0x40078000,len:11092
load:0x40080000,len:252
entry 0x40080034
0x40078000: ?? ??:0
0x40080000: _iram_start at ??:?
0x40080034: _iram_start at ??:?
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0008,len:8
load:0x3fff0010,len:4412
ho 0 tail 12 room 4
load:0x40078000,len:11092
load:0x40080000,len:252
entry 0x40080034
0x40078000: ?? ??:0
0x40080000: _iram_start at ??:?
0x40080034: _iram_start at ??:?
[0;32mI (46) boot: ESP-IDF v2.0-rc1-803-ge333f8f4-dirty 2nd stage bootloader

[martinayotte]

The double reset is due to the fact that silicon v0 has a bug ... (should be fixed in v1)
Here is the explanation provided by Igrr :
https://github.com/espressif/esp-idf/issues/494
http://espressif.com/sites/default/file ... p32_en.pdf

[ESP_igrr]

martinayotte: it isn't a case of the rev0 bug. As you can see, reset starts with a SW_CPU reset, but the bug only happens after power on or deep sleep reset.

More likely, 2nd stage bootloader doesn't start up for some reason.

What esp-idf version does this happen with, 2.0?

Regarding unhandled debug exception: might be an 'assert' which happened while flash cache is disabled.

[f.h-f.s.]

What esp-idf version does this happen with, 2.0?

I am using the master branch of esp-idf.

Regarding unhandled debug exception: might be an 'assert' which happened while flash cache is disabled.

Why would the flash cache be disabled? I am not doing anything special with the flash memory in my program. I do have the CPU1 disabled.

silicon v0 has a bug ... (should be fixed in v1)
Here is the explanation provided by Igrr :

I am not deepsleeping and this does not occur at power on.

[BuddyCasino]

Since this apparently involves the UART: do you run code on both cores?

I've had the following happen when printf() was called from both cores:

Code: Select all

Guru Meditation Error: Core  1 panic'ed (Unhandled debug exception)
Debug exception reason: BREAK instr

In the stacktrace, usually vprintf() shows up when this is the case.
The solution is to use ESP_LOGx(), they protect the UART with a MUTEX. At least thats I think thats what fixed it, I'm not a 100% sure though.

[ESP_Sprite]

BuddyCasino: printf itself should also have the mux, it's actually located in the uart vfs driver. Do you still have the code that lead to the BREAK instructions?

[ESP_igrr]

printf (or ESP_LOGx) from both cores will cause this if one core calls printf (or ESP_LOGx) from an ISR (or a callback called from an ISR).

Same one one core: if using printf or ESP_LOGx from ISR, it will cause abort() to be called, which includes an __asm__ ("break 0,0");.

[BuddyCasino]

Ah, quite possibly it was from an ISR - I don't remember. Good to know that regular printf() is already protected!

Interestingly I have an issue right now where I can reliably reproduce a "Unhandled debug exception" when calling i2s_set_sample_rates(). I'll see if I can come up with a test case.