AnsweredAssumed Answered

MCUX 10.2.1 - Debugger pauses but shows no context

Question asked by David Rodgers on Oct 22, 2018
Latest reply on Oct 25, 2018 by David Rodgers

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)