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

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

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

ソリューションへジャンプ
4,411件の閲覧回数
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

ラベル(1)
0 件の賞賛
返信
1 解決策
4,347件の閲覧回数
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 件の賞賛
返信
4 返答(返信)
4,348件の閲覧回数
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 件の賞賛
返信
4,336件の閲覧回数
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 件の賞賛
返信
4,285件の閲覧回数
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 件の賞賛
返信
4,391件の閲覧回数
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 件の賞賛
返信