Debugging recently failed (using LPC11U68 with LPC-Link.2)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Debugging recently failed (using LPC11U68 with LPC-Link.2)

Jump to solution
2,697 Views
jDrum
Contributor III

Debugging the LPC11U68 on our own PCB has recently failed. The symptoms are that the program can be downloaded and run, but breakpoints no longer cause a break.  Many of the "run" commands such as single step, step return, step over have no effect. Run (shortcut key f8) works fine. The Pause Icon works OK.

So far, we have 1) changed the PCB with the target LPC11U68, 2) changed the LPC-Link2 interface, 3) restarted the MCUXpresso, 4) rebooted the host computer.

Any suggestions would be appreciated.

jDrum

Labels (1)
0 Kudos
Reply
1 Solution
2,633 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, I recommend clean the project, refresh and build again. There is a way to replay this on my side? what is the MCU that you are using?

Could you let me know what is the IDE version and the SDK?

Best regards, 
Pavel

View solution in original post

0 Kudos
Reply
4 Replies
2,634 Views
Pavel_Hernandez
NXP TechSupport
NXP TechSupport

Hello, I recommend clean the project, refresh and build again. There is a way to replay this on my side? what is the MCU that you are using?

Could you let me know what is the IDE version and the SDK?

Best regards, 
Pavel

0 Kudos
Reply
2,622 Views
jDrum
Contributor III

Thank you @Pavel_Hernandez 

We are using LPCopen on the

MCUXpresso IDE v11.8.0 [Build 1165] [2023-07-26].  The MCU and SDK don't apply to the LPC11U68.

Since we got the debugger to function again by using the gdb, the breakpoints can be set as before.  The chip accepts 3 breakpoints max.

jDrum

0 Kudos
Reply
2,571 Views
jDrum
Contributor III

Hello again.

The debugger has been working OK since the first (and only) failure.  As we already stated, the fix was to use the gdb debugger from the console.

We still have no answer as to why the IDE debugger locked up (it wouldn't hit a break point that was set or even do a single step).  No amount of restarting, recompiling, or rebooting solved the problem.  During that incident the program was still running OK and could be paused, but no IDE-type debugging was possible.

We are setting the solved button after two weeks.

jDrum

0 Kudos
Reply
2,681 Views
jDrum
Contributor III

Hello again.  Further update

By using the gdb debugger we were able to set a breakpoint deep in the assembler code for sprintf().  I was looking for the machine language window when the program finally hit a breakpoint and stopped.

Perhaps the code got into an infinite loop and never got to any of the set breakpoints, but that doesn't explain why the debugger wouldn't single step even at the program start. 

Screen shot of IDE attached.

jDrum

Still wondering.

0 Kudos
Reply