Unexpected break/watch point in FreeRTOS code cannot be resumed
Posted: Tue Dec 05, 2017 10:57 pm
When debugging the ESP32 I get a break/watch point stops inside FreeRTOS code. The problem is I never set any break/watch point(s) in that code. What is worse is that I can never resume debugging from this condition. Trying to resume or (step into/over/out-of) from the FreeRTOS code all result in the debug session being terminated after a delay of approximately 10 seconds. This condition happens all the time.
Environment: MAC OS X Sierra 10.12.2
OpenOCD - Open On-Chip Debugger 0.10.0-dev-ga859564 (2017-07-25-00:19)
GNU gdb (GDB) 8.0.1, IDE: Eclipse Neon 3, Board: ESP32 WROVER KIT - V3, ESP-IDF: latest (about 10 days old, and with latest - as of this writing)
I see this same behavior with any combination of OpenOCD (standalone or with Eclipses) with (Eclipse GDB HW Debugging or Eclipses OpenOCD Debugging). The scenario is, I hit a breakpoint in my code (as set and expected) and when I say resume debugging, I get the unexpected break into the FreeRTOS code from which I cannot proceed.
The unexpected FreeRTOS breaks occur in queue.c::1591: portYIELD_WITHIN_API() or other places in queue.c, but as mentioned these unexpected and un-asked for breaks result in the debug session unable to resume and ultimately end. The executing thread (really FreeRTOS task) shows (Suspended : Signal : SIGTRAP:Trace/breakpoint trap).
Does anyone have any ideas as to why this is happening? I have attached my sdkconfig for reference.
Is it possible that memory/stack bugs/problems are causing SIGTRAP?
I know, SIGTRAP is normal for processors that support breakpoints/watchpoints. Of course without the debugger running, SIGTRAP would terminate the process. The issue is I don't have any breakpoints in these FreeRTOS functions and I don't have any watchpoints either. The watchpoint angle seems interesting as there are options in make menuconfig that could possibly result in watchpoints being set from FreeRTOS options:
[ ] Set a debug watchpoint as a stack overflow check
[ ] Enable FreeRTOS trace facility
[ ] Enable FreeRTOS to collect run time stats
[ ] Debug FreeRTOS internals
I don't have any of these set.
I do have:
[*] Make exception and panic handlers JTAG/OCD aware
There are other menuconfig's like these where it's not clear what the will/should do in GDB/OCD scenarios but I don't have them enabled anyways.
[ ] Use TRAX tracing feature
[ ] Heap corruption detection
[ ] Enable heap tracing
Environment: MAC OS X Sierra 10.12.2
OpenOCD - Open On-Chip Debugger 0.10.0-dev-ga859564 (2017-07-25-00:19)
GNU gdb (GDB) 8.0.1, IDE: Eclipse Neon 3, Board: ESP32 WROVER KIT - V3, ESP-IDF: latest (about 10 days old, and with latest - as of this writing)
I see this same behavior with any combination of OpenOCD (standalone or with Eclipses) with (Eclipse GDB HW Debugging or Eclipses OpenOCD Debugging). The scenario is, I hit a breakpoint in my code (as set and expected) and when I say resume debugging, I get the unexpected break into the FreeRTOS code from which I cannot proceed.
The unexpected FreeRTOS breaks occur in queue.c::1591: portYIELD_WITHIN_API() or other places in queue.c, but as mentioned these unexpected and un-asked for breaks result in the debug session unable to resume and ultimately end. The executing thread (really FreeRTOS task) shows (Suspended : Signal : SIGTRAP:Trace/breakpoint trap).
Does anyone have any ideas as to why this is happening? I have attached my sdkconfig for reference.
Is it possible that memory/stack bugs/problems are causing SIGTRAP?
I know, SIGTRAP is normal for processors that support breakpoints/watchpoints. Of course without the debugger running, SIGTRAP would terminate the process. The issue is I don't have any breakpoints in these FreeRTOS functions and I don't have any watchpoints either. The watchpoint angle seems interesting as there are options in make menuconfig that could possibly result in watchpoints being set from FreeRTOS options:
[ ] Set a debug watchpoint as a stack overflow check
[ ] Enable FreeRTOS trace facility
[ ] Enable FreeRTOS to collect run time stats
[ ] Debug FreeRTOS internals
I don't have any of these set.
I do have:
[*] Make exception and panic handlers JTAG/OCD aware
There are other menuconfig's like these where it's not clear what the will/should do in GDB/OCD scenarios but I don't have them enabled anyways.
[ ] Use TRAX tracing feature
[ ] Heap corruption detection
[ ] Enable heap tracing