MCUX 10.2.1 - Debugger pauses but shows no context

[dmarks_ls]

I've been developing a C++ project on a Kinetis K24 for the last several months.  I've previously had no trouble setting breakpoints, pausing execution, and seeing my list of FreeRTOS tasks under [image_name].axf in my PEMicro debug context.  This is my third C++ project on Kinetis, and my second using MCUXpresso.

Just in the last week or so, the last couple of times I've tried to debug my program, when I press Pause to halt the program, or hit a breakpoint, the program does indeed halt, but I get no debug context at all... no RTOS tasks, not even a single-threaded instance.  When I first load my program, it does halt at the temporary breakpoint at the start of int main(); it shows the context under the AXF image in the P&E GDB tree, and pulls up the source file with main() and highlights the line.  But once the program starts running, if I hit pause, I get no debug context at all.  If I set a manual breakpoint in my main() routine and induce my target to do a watchdog reboot (by executing the command I'm presently trying to debug), when it hits the breakpoint, I see 20+ task contexts, but they're all leftovers of my previous run.  If I let the target reboot, then set a breakpoint in one of my not-buggy test routines, and trigger that breakpoint, the target halts, but no context appears under the AXF image, and no source file either.  If I let it resume, the target continues running normally.

What's going on here?  When my target is running normally, I can see through my console diagnostics that all tasks are running with lots of margin in their stacks, even after a breakpoint hit and resume.  But pausing the debugger in this state doesn't allow me to perform any source-level debugging once the app is up and running.  This is incredibly frustrating, as it's quite literally preventing me from debugging my program.  I'm now having to make alterations to my program just to isolate where the failure is, instead of tracing through.

Please advise.

(Win 10 x64 patched, MCUX v10.2.1, Kinetis K24, PEMicro Multilink Universal Rev. C, latest PEMicro debugger patch applied)

[dmarks_ls]

I didn't have time to try out a standard demo project (in the thick of development here), but we did try out using a SEGGER J-Link and got the same results (no source-level context) when we enabled RTOS awareness.  However, we were able to get the RTOS awareness working again by adding the following two lines to FreeRTOSConfig.h:

#define configFRTOS_MEMORY_SCHEME   4
#define configINCLUDE_FREERTOS_TASK_C_ADDITIONS_H   1

The file "freertos_tasks_c_additions.h" appears to carry a number of data definitions that presumably assists the debugger in identifying certain FreeRTOS structures.  I'm not sure what happened in the last couple of weeks that caused the previous RTOS awareness regime to break down, but enabling these "additions" appears to make the PEMicro and SEGGER FreeRTOS plugins much happier.  TBH, I'm not sure why this isn't enabled by default in new MCUX SDK projects.  So, thanks for the pointers, that was the direction we needed to be looking in.  I do see that the MCUonEclipse article mentions this part of the solution.  Thanks.

David R.

[lpcxpresso_supp · Accepted solution]

Can you successfully debug a standard FreeRTOS based demo project without similar problems?

Does turning off the P&E Micro rtos awareness cause any improvement in behaviour (though that will loose you your thread awareness) : using the "-kernel=none" option as per : P&E ARM Cortex-M Debugging with FreeRTOS Thread Awareness and Real Time Expressions for GDB and Ecli... 

Might also be worth running through : Troubleshooting Tips for FreeRTOS Thread Aware Debugging in Eclipse | MCU on Eclipse 

Regards,

MCUXpresso IDE Support