4

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?

enter image description here

(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.

artless noise
  • 21,212
  • 6
  • 68
  • 105
Craig
  • 4,323
  • 2
  • 29
  • 32

1 Answers1

2

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).

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • Was able to get a few of those commands work, never got the load_image to work, it would just come back with a "JTAG-DP STICKY ERROR MEM_AP_CSW 0x23000052" error. I did mess around with the the flash write_image command and managed to blow away the boot loader somehow, then got it back (but lost it again, heh). – Craig Oct 28 '11 at 05:57
  • Must be some wrong in my "ram" linker script because I pulled down your mbed_samples/ebay_board/blinker01 code and it loaded fine and ran fine with load_image / resume 0x10000001. My linker scripts and Makefile are here: https://gist.github.com/1322088 – Craig Oct 28 '11 at 11:21
  • I have not had much luck with those other ram sections, I wonder if something has to be turned on for them to work. using arm...objdump to disassemble the elf file will show what is at 0x23000052 in your program. Looking at the lpc1768.cfg openocd config file it specifies some ram at 0x10000000 but I dont see a 0x23000000 entry, that is likely why the warning has a jtag complaint to it. maybe the jtag is refusing to write there. – old_timer Oct 28 '11 at 14:15
  • Finally got load_image to work, yay! 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. (see my "UPDATE") – Craig Oct 29 '11 at 16:55
  • Good to hear, if the basic openocd commands dont work then gdb wont work either, so you are perhaps half way there. I dont use gdb or any debugger so I cannot help you beyond this point...good luck...have fun. – old_timer Oct 29 '11 at 18:47