ESP32 Forum

Posted: **Tue Oct 23, 2018 2:44 am**

Currently I have a project running BLE connecting to a few sensors, making a measurement and then dropping the connection. I am running into an issue were a bit of pre compiled code is getting stuck and triggering the watchdog.

It seems strange though since it is saying that CPU 1 is in the idle task, however the interrupt wdt has time out???

I have a task pinned to the same core as the BLE code which is outputting the time difference from the last time it was called by using
the gettimeofday(), this seems to be correct and demonstrating the code is not stuck.

I have also increased the interrupt wdt to 5 seconds.....

I am using version 3.1 of the IDF.

Every time I am observing this crash ASSERT_PARAM(2051 0), in llc_util.c at line 289 has been output to the terminal.

Code: Select all

ASSERT_PARAM(2051 0), in llc_util.c at line 289                                 
Task watchdog got triggered. The following tasks did not reset the watchdog in t
ime:                                                                            
 - IDLE (CPU 1)                                                                 
Tasks currently running:                                                        
CPU 0: Guru Meditation Error: Core  1 panic'ed (Interrupt wdt timeout on CPU1)  
Core 1 register dump:                                                           
PC      : 0x4008464d  PS      : 0x00060b34  A0      : 0x80046350  A1      : 0x3f
fbcb40                                                                          
A2      : 0x00000001  A3      : 0x00000000  A4      : 0x00000000  A5      : 0x60
008054                                                                          
A6      : 0x3ffc1028  A7      : 0x60008050  A8      : 0x8008464d  A9      : 0x3f
fbcb20                                                                          
A10     : 0x00000004  A11     : 0x00000000  A12     : 0x6000804c  A13     : 0xff
ffffff                                                                          
A14     : 0x00000000  A15     : 0xfffffffc  SAR     : 0x00000004  EXCCAUSE: 0x00
000006                                                                          
EXCVADDR: 0x00000000  LBEG    : 0x40084585  LEND    : 0x4008458c  LCOUNT  : 0x00
000000                                                                          
                                                                                
Backtrace: 0x4008464d:0x3ffbcb40 0x4004634d:0x3ffbcb60 0x40121ac1:0x3ffbcb80 0x4
0019d11:0x3ffbcbc0 0x40055b4d:0x3ffbcbe0 0x4011dad3:0x3ffbcc00 0x4011de55:0x3ffb
cc20                                                                            
                                                                                
Core 0 register dump:                                                           
PC      : 0x4000921a  PS      : 0x00060034  A0      : 0x80007d16  A1      : 0x3f
fc0500                                                                          
A2      : 0x00800000  A3      : 0x00060023  A4      : 0x8008cd21  A5      : 0x3f
fd3b00                                                                          
A6      : 0x00000003  A7      : 0x00060b23  A8      : 0x3ff40000  A9      : 0x00
000049                                                                          
A10     : 0x00800000  A11     : 0x3ff4001c  A12     : 0x00000000  A13     : 0x3f
fd3c20                                                                          
A14     : 0x3ffc63b0  A15     : 0x3ffc52f4  SAR     : 0x00000011  EXCCAUSE: 0x00
000006                                                                          
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00
000000                                                                          
                                                                                
Backtrace: 0x4000921a:0x3ffc0500 0x40007d13:0x3ffc0520 0x40007c69:0x3ffc0540 0x4
0008106:0x3ffc0560 0x400d1e32:0x3ffc05f0 0x4008265d:0x3ffc0610 0x4014516b:0x0000
0000

Posted: **Wed Oct 24, 2018 2:34 am**

Hm, especially given the ASSERT thing, this smells like a bug. Do you also get this if you switch to the latest master esp-idf branch? Is there any chance you can whittle this down to the smallest possible project that reproduces this (so we can see if we get it here as well) and make a new issue on the esp-idf github?

Posted: **Wed Oct 24, 2018 3:56 am**

I seem to have miss interpreted the dump, from what I understand it is that the idle task was never able to kick the task watchdog.
Since posting this issue I have possibly eliminated this crash from happening by the following;
- Pinning bluedroid and BLE to core 0

- I had a task which was starting scanning for a brief moment and then allowing some idle time of no scanning(I plan to also use wifi). This task is also now pinned to core 0. Previously I was just using xTaskCreate() and not xTaskCreatePinnedToCore().

- I also had another task which was processing a queue of commands to send to my devices over ble, this is now also pinned to core 0.

I'm assuming there's an issue when running BLE related commands on two separate cores rather than one?

ESP32 Forum

Strange Interrupt wdt timeout

Strange Interrupt wdt timeout

Re: Strange Interrupt wdt timeout

Re: Strange Interrupt wdt timeout