Hi Guys - I'm not sure if this is a Segger problem, but maybe you've seen this before...
I'm using MCUXpresso from NXP on a Kinetis K64 (Cortex-M4F).
FreeRTOS 9.0.0 and ARM GCC tools of 1Q2017.
#define configUSE_PORT_OPTIMISED_TASK_SELECTION 0 // Note: 1 causes FreeRTOS Eclipse plug-in to crash...
#define configTASK_RETURN_ADDRESS 0 // place 0 task return address on stack to help FreeRTOS-aware debugger (GDB unwind thread stack)
#define configCHECK_FOR_STACK_OVERFLOW 2 // FreeRTOS vTaskSwitchContext checks for stack overflow => void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName );
FreeRTOS Task Aware Debugger for GDB version 1.0.2 (201702241004)
J-Link V6.14
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).
[img]http://www.nadler.com/backups/FreeRTOSawareDebugger_stackOverflow_bug.PNG[/img]
Any ideas?
Thanks!
Best Regards, Dave
PS: I checked that no optimization was used (Arne pointed out this caused trouble in past).
I'm using MCUXpresso from NXP on a Kinetis K64 (Cortex-M4F).
FreeRTOS 9.0.0 and ARM GCC tools of 1Q2017.
#define configUSE_PORT_OPTIMISED_TASK_SELECTION 0 // Note: 1 causes FreeRTOS Eclipse plug-in to crash...
#define configTASK_RETURN_ADDRESS 0 // place 0 task return address on stack to help FreeRTOS-aware debugger (GDB unwind thread stack)
#define configCHECK_FOR_STACK_OVERFLOW 2 // FreeRTOS vTaskSwitchContext checks for stack overflow => void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName );
FreeRTOS Task Aware Debugger for GDB version 1.0.2 (201702241004)
J-Link V6.14
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).
[img]http://www.nadler.com/backups/FreeRTOSawareDebugger_stackOverflow_bug.PNG[/img]
Any ideas?
Thanks!
Best Regards, Dave
PS: I checked that no optimization was used (Arne pointed out this caused trouble in past).