ESP32 Forum

Posted: **Thu Jan 18, 2018 1:17 am**

I've been using v2.1.1 with my prijects for some time, but I ran into a show-stopping problem with I2C, so I moved my project to v3.0rc1 instead. This seems to have fixed the I2C problem but unfortunately I've now run into some stability problems that I didn't see with v2.1.1.

The most serious one involves a seemingly random watchdog timeout that causes a reboot, followed by repeated and continuous rebooting of the board until either a long reset or power-cycle is performed. The error is usually (but not always) mentioning I2C:

Code: Select all

Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Register dump:
PC      : 0x400863cf  PS      : 0x00060034  A0      : 0x80085908  A1      : 0x3ffb0570  
0x400863cf: vPortCPUAcquireMutexIntsDisabled at /Users/david/esp32/esp-idf-v3.0/components/freertos/./tasks.c:4571
 (inlined by) vTaskEnterCritical at /Users/david/esp32/esp-idf-v3.0/components/freertos/./tasks.c:4216

A2      : 0x3ffbc94c  A3      : 0x00060023  A4      : 0x00060021  A5      : 0x3ffbad90  
A6      : 0x00000000  A7      : 0x4008497c  A8      : 0x00000000  A9      : 0x00000001  
0x4008497c: i2c_isr_handler_default at /Users/david/esp32/esp-idf-v3.0/components/driver/./i2c.c:1023

A10     : 0xb33fffff  A11     : 0x00000000  A12     : 0x00060023  A13     : 0x00000001  
A14     : 0x00060023  A15     : 0x00000000  SAR     : 0x00000012  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x400863cf:0x3ffb0570 0x40085905:0x3ffb0590 0x40084602:0x3ffb05b0 0x40084a09:0x3ffb05e0 0x40082b25:0x3ffb0610 0x4000bfed:0x00000000
0x400863cf: vPortCPUAcquireMutexIntsDisabled at /Users/david/esp32/esp-idf-v3.0/components/freertos/./tasks.c:4571
 (inlined by) vTaskEnterCritical at /Users/david/esp32/esp-idf-v3.0/components/freertos/./tasks.c:4216

0x40085905: xQueueGenericSendFromISR at /Users/david/esp32/esp-idf-v3.0/components/freertos/./queue.c:2037

0x40084602: i2c_master_cmd_begin_static at /Users/david/esp32/esp-idf-v3.0/components/driver/./i2c.c:1023

0x40084a09: i2c_isr_handler_default at /Users/david/esp32/esp-idf-v3.0/components/driver/./i2c.c:1023

0x40082b25: _xt_lowint1 at /Users/david/esp32/esp-idf-v3.0/components/freertos/./xtensa_vectors.S:1105


Rebooting...

I connected my C232HM-EDHSL (FTDI) JTAG debug cable and attempted to catch the fault. I use the ESP-IDF instructions for debugging with Eclipse. With SDK 2.1.1 this always seemed to work pretty much first try, and I've debugging a range of issues in the past, but with v3.0rc1 I've had a lot of problems. In particular, when attempting to start a debug session:

"Problem Occurred: Error in final launch sequence"

Code: Select all

Error in final launch sequence
Failed to execute MI command:
x $a1=0
Error message from debugger back end:
Cannot access memory at address 0x0
Failed to execute MI command:
x $a1=0
Error message from debugger back end:
Cannot access memory at address 0x0
Cannot access memory at address 0x0

This seems to happen almost every time. I went back to a v2.1.1 build to test that my setup is working, and it is, and in fact after returning to the v3.0rc1 build I was able to get it to work correctly once, but not on any subsequent attempt.

Can anyone shed any light on this particular error? If I had some clues about what it's doing I might be able to work out what I'm doing that may be causing it.

Incidentally, the (Espressif-modified) openocd output at the time of this error is:

Code: Select all

Info : accepting 'gdb' connection on tcp/3333
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32: Debug controller was reset (pwrstat=0x5F, after clear 0x0F).
Info : esp32: Core was reset (pwrstat=0x5F, after clear 0x0F).
Info : Target halted. PRO_CPU: PC=0x5000004B (active)    APP_CPU: PC=0x00000000 
esp32: target state: halted
Info : esp32: Core was reset (pwrstat=0x1F, after clear 0x0F).
Info : Target halted. PRO_CPU: PC=0x40000400 (active)    APP_CPU: PC=0x40000400 
esp32: target state: halted
Info : dropped 'gdb' connection

Posted: **Thu Jan 18, 2018 1:46 am**

I saw this error just now with a v2.1.1 project however I found that reseting my USB interface and restarting Eclipse cleared it. So I have confirmed (again) that I can debug with v2.1.1.

Interestingly, I note with my v2.1.1 project that the system halts at this part of the boot process:

Code: Select all

I (930) cpu_start: Starting scheduler on PRO CPU.
I (696) cpu_start: Starting scheduler on APP CPU.

But with my v3.0rc1 project, it doesn't halt there at all. Instead, the application starts and runs as normal. Only when it crashes (or hits an assert) does it actually suspend (and openocd reports it). Eclipse, though, consistently reports the error mentioned earlier.

EDIT: in fact, if I ignore Eclipse entirely, if I press the reset button on the dev board, I would expect the system to halt at boot, and OpenOCD to report that, then I could use gdb to continue. It's not halting.

EDIT 2: I've tried a second ESP32 board - same behaviour: when using 3.0rc1, it doesn't halt at the start of the application as it does with v2.1.1. Maybe there's a menuconfig option that has changed?

Posted: **Thu Jan 18, 2018 2:25 am**

You may be right there... I think we removed the feature to halt on the first task that starts because we added functionality to halt at CPU reset to OpenOCD at a certain point. You may want to look into updating your OpenOCD setup.

Posted: **Thu Jan 18, 2018 2:53 am**

I updated to the latest openocd-esp32 and recompiled, and it still doesn't halt (perhaps as you say) but I'm still getting that original error in Eclipse regarding "Cannot access memory at address 0x0". The OpenOCD output looks pretty much the same too, and reports that the gdb connection was dropped.

I have tried command-line gdb as well, and I did have some success setting manual breakpoints and stepping through code, so this will be usable in the meantime I think. If I can work out why Eclipse cannot connect that would be much better though.

ESP32 Forum

JTAG debug issue with v3.0rc1

JTAG debug issue with v3.0rc1

Re: JTAG debug issue with v3.0rc1

Re: JTAG debug issue with v3.0rc1

Re: JTAG debug issue with v3.0rc1