FreeRTOS-aware Eclipse plug-in problems

Posted by dnadler on July 13, 2017

Hi Guys - This isn't strictly a FreeRTOS problem but a problem with Eclipse debugging. Hope someone can help...

**FreeRTOS task missing or incorrectly shows stack overflow ** FreeRTOS Task Aware Debugger for GDB version 1.0.2 (201702241004) Segger J-Link V6.14 MCUXpresso (Eclipse Neon?) from NXP on a Kinetis K64 (Cortex-M4F). FreeRTOS 9.0.0 (M4F port) and ARM GCC tools of 1Q2017 (not NXP-distributed GCC). Debug build with no GCC optimizations. ~~~

define configUSEPORTOPTIMISEDTASKSELECTION 0 // Note: 1 causes FreeRTOS Eclipse plug-in to crash...
define configTASKRETURNADDRESS 0 // place 0 task return address on stack to help FreeRTOS-aware debugger (GDB unwind thread stack)
define configCHECKFORSTACK_OVERFLOW 2 // FreeRTOS vTaskSwitchContext checks for stack overflow => void vApplicationStackOverflowHook

~~~

When I pause the application in the debugger, sometimes the MainLoop task is missing. When visible MainLoop always erroneously shows stack overflow (verified all OK using uxTaskGetStackHighWaterMark, after I nearly had a heart attack), as shown here:

Any ideas? Thanks! Best Regards, Dave

FreeRTOS-aware Eclipse plug-in problems

Posted by rtel on July 14, 2017

Which plug-in are you using? Probably best to report the problem to the person supplying the plug-in. I suspect either a subtle bug in how the structures are being read, or just an error in how the internal FreeRTOS data structures are being interpreted.

FreeRTOS-aware Eclipse plug-in problems

Posted by dnadler on July 14, 2017

As listed above, "FreeRTOS Task Aware Debugger for GDB version 1.0.2 (201702241004)" I'm not sure where it comes from, but I'll try find out...

FreeRTOS-aware Eclipse plug-in problems

Posted by dnadler on July 14, 2017

OK, this seems to be from NXP. The solution: ~~~

define configUSETRACEFACILITY 1 // without this, FreeRTOS-aware debug task list can miss tasks and show bogus stack overflows

~~~

FreeRTOS-aware Eclipse plug-in problems

Posted by rtel on July 14, 2017

Ah, interesting. I'm not sure why that would be. Did you work that out yourself, or is it documented somewhere.

If it is from NXP then I suspect the plug-in will have come from PEMicro.