Using GDB to debug and restart LPC 4357

lpcware · ‎06-15-2016

Content originally posted in LPCWare by philippschrader on Mon Dec 22 11:41:03 MST 2014
Hi,

I'm trying to set up our build system that lets us use LPCXpresso's gdb to debug the 4357 applications. I've gotten to the point where I can flash code and debug the M4 portion of it.
This is the gdb script I use for the M4 code:

set trace-commands on
set logging on
target extended-remote | crt_emu_cm_redlink -g -2 -vendor=NXP -pLPC4357 -ResetScript=LPC18LPC43InternalFLASHBootResetscript.scp -reset= -CoreIndex=0 -flash-driver=LPC18x7_43x7_2x512_BootA.cfx
b main

First question: How do I reset execution using gdb commands? In LPCXpresso I can just hit the little "Restart" icon and I can restart execution that way. The traditional "monitor reset" in gdb just tells me "Target does not support this command."

Second question: How do I debug the M0 code at the same time? LPCXpresso works beautifully for this, but I can't figure it out with gdb. Here's the M0 gdb script I use, but it seems to attach to the M4 core no matter what I try to do:

set trace-commands on
set logging on
target extended-remote | crt_emu_cm_redlink -g -2 -vendor=NXP -pLPC4357-M0 -attach -reset= -CoreIndex=1 -flash-driver=LPC18x7_43x7_2x512_BootA.cfx
b main

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Dec 24 00:00:00 MST 2014

Quote: philippschrader
I can now use GDB to connect to each individual core when I pass the additional

-ProbeHandle=1

argument to crt_emu_cm_redlink.

A bit of background here. This is an undocumented feature, originally intended as a short cut for user's who would use the command line debug stub for flash programming. If the stub sees the

ProbeHandle=

argument default to zero (as it does if not specified on the command line), it ignores any

CoreIndex=

argument.The probe handle is ultimately determined by a Redlink Server PROBEFIRSTFOUND command, and the CoreIndex is forced to zero to select the M4. This is intentional since the flash driver executes on the M4 which is always available. The M0 core is typically not available until the M4 takes it out of reset.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by philippschrader on Tue Dec 23 20:48:02 MST 2014

Quote:
When the debugger starts a debug session, it also starts and communicates with redlinkserver (redlinkserv.exe). You will see this communication in the Redlink console. This does some setup to enable the debug drivers (stubs) to communicate with the correct target.

Actually, after a bit of trial-and-error, I wrote a Python script that starts redlinkserv, connects to it via telnet and executes the same commands that LPCXpresso does (as reported on the Redlink console).

I can now use GDB to connect to each individual core when I pass the additional

-ProbeHandle=1

argument to

crt_emu_cm_redlink

.

Haven't looked into restarting the Cortex M4 from GDB yet. That'll be after the holidays

PS: Thanks a lot for the hint, I think this will work great for me!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by philippschrader on Tue Dec 23 15:35:04 MST 2014

Quote:

Dual core debugging through command line GDB isn't really supported, although is do-able.
...
If you want to communicate with redlink server, you need to use telnet to port 3025

Would you happen to have an example for this? I've never used GDB via telnet.

Quote:
But, I have to ask - why do you want to do this when (as you have already said) it works well through the IDE...

This is mostly a question of automation. For past projects we've set up dedicated test machines that autonomously check out the source code, compile it, load it on the target and then run all kinds of tests. We've set the machine up so developers can submit custom GDB scripts with fancy breakpoints, watch points etc. and provide them with backtraces reg dumps etc. when an error occurs.

Also, I'm personally used to using GDB; I'm fairly proficient at using it. It lets me SSH into work and debug everything remotely.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Tue Dec 23 02:05:07 MST 2014
Dual core debugging through command line GDB isn't really supported, although is do-able.

When the debugger starts a debug session, it also starts and communicates with redlinkserver (redlinkserv.exe). You will see this communication in the Redlink console. This does some setup to enable the debug drivers (stubs) to communicate with the correct target.

If you want to communicate with redlink server, you need to use telnet to port 3025.

But, I have to ask - why do you want to do this when (as you have already said) it works well through the IDE...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by philippschrader on Mon Dec 22 12:59:02 MST 2014
Just in case it helps, my LPCXpresso version is:
LPCXpresso v7.3.0 [Build 186] [2014-07-09]