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
4,408 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
4,344 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
4,345 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
4,333 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
4,282 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
4,388 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