Eclipse GDB “init” and “run” settings for ARM LPC1768 using OpenOCD?

Question

I finally figured out how to get code running on this LPC1768 mini board, however now I'm trying to get debugging working.

The toolchain I'm using is: Yagarto + Eclipse (Indigo) (w/ GDB Hardware Debugger) + OpenOCD. My JTAG interface is: Bus Blaster V2 board.

I found one guide that walks through a similar setup, but it's for a different JTAG interface so not very useful. There's also this post regarding an LPC1768 example, but the gdb commands aren't for OpenOCD.

At this point the only command I know for sure (for init) is target remote localhost:3333 (for connecting to the OpenOCD gdb server).

What settings and gdb commands should I be using in this dialog?

(Ignore the "SAM7X256", just re-using a screenshot from one of the above links. I'm using an ARM LPC1768)

Also, does the fact my board uses a secondary bootloader (user code starts at 0x2000) affect any of these debug settings?

UPDATE: Taking dwelch's advice, I did manage to get some basic OpenOCD commands to work (reset init, mdw, mww, load_image, etc). The weird "JTAG-DP STICKY" error was something with my ram linker script, found a project template for the LPC1758 with a RAM linker script, just had to modify the memory sizes for the LPC1768 and load_image worked great.

I'd still like to know how to properly configure eclipse for GDB debugging though.

Answer 1

Perhaps try one step at a time.

Start openocd, probably something like -f interface/jlink.cfg -f target/lpc1768.cfg or whatever, sounds like you have that working.

second telnet localhost 4444 or whatever the windows command line is (something similar)

WITHIN THE TELNET SESSION:

> halt
> mdw 0x0000

and stuff like that to see that you are talking to the part.

if you have already compiled some programs you can simply load them and run them, for example if you make a ram only program (tell the linker .text, .data, etc are all at 0x10000000) then

> load_image /path/to/myprog.elf
> resume 0x10000001

(yes add 1 to make it odd, this is a thumb processor wont run ARM instructions (lsbit = 0 is arm mode lsbit = 1 is thumb mode).

To re-run after re-compiling:

> halt
> load_image /path/to/myprog.elf
> resume 0x10000001

then worry about flashing, etc after you have ram based programs showing signs of life.

If none of that is working then gdb is just one more level of complexity on top of that and going to make it harder to figure out.

As far as the bootloader goes, the answer is it depends are you trying to run from ram or program to rom. If running from ram you can take over the system and take all the ram, some chips (stm32) have some routines you can call and those require some ram to be untouched, but if you are taking over the chip you can have all the ram, it is a matter of telling the linker and perhaps the debugger if it doesnt know from the binary (using elf files or ihex or srec or pretty much anything that is not a .bin is good, if the tool supports it).

if you are going to write to flash then you had better know exactly what portion of flash might contain a bootloader, what that bootloader does to hand off to your code, etc, and again tell the linker and the debugger this information. you could easily erase/trash the bootloader depending on where it is and what you are doing (a lot of these lpc and st parts have bootloaders, serial or usb, that are somewhat protected from casual mistakes, but you can still usually erase them and replace them if you are not careful).