For that matter, if I put a breakpoint at the second instruction it never stops there, either. That's not really surprising since it's a two-part update, but if I put a breakpoint on the other side of the WDOG setup it never gets there. If I put it in instruction stepping mode, I can step through until the WDOG unlock and then it jumps back to the entry point. I have to kill the pegdbgserver_console.exe process before I can launch it again, and until then none of the debugger controls in the IDE do anything, including the terminate button. I'll launch the application and if I let it run and hit pause, the debugger is no longer responding. On four different boards today, of two very different designs (all based on the MK22FN1M0AVLH12) I've had the debugger just stop doing anything. P&E recently made some updates that really helped the stability - it no longer hangs if you just reset the target board or disconnect the cable, for example - but it's still failing sometimes and they're blaming it on the gdb side. I'm using a P&E Cyclone ACP as my primary debug interface. I had this problem prior to the MCUX 10.2.0 upgrade but it seems to be cropping up more now.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |