spacewrench wrote on Saturday, February 28, 2009:
> What is giving me grief is the debugger.
Debugging a micro with GDB is actually a two-part process. GDB itself is a pretty well-behaved program, and you should be able to compile a version for arm-elf from source without much trouble. (Or maybe you can find a pre-compiled version in ports.)
The second part is much trickier. GDB interacts with the target by talking to a “target remote program” over a TCP connection. It’s the responsibility of target remote program to start, stop and reset the micro, and to report any information that GDB asks for.
The only target remote program I know of is OpenOCD. Configuration files for OpenOCD usually set it up to talk to GDB on port 3333, and you can also talk to OpenOCD directly by telnetting to port 4444. OpenOCD knows how to operate a few different JTAG interface dongles, and also knows some of the things you can do with the JTAG protocol.
> Using Yagarto, I am able to compile for sure and maybe link. The reason why I’m not sure with
> the debugger is because I couldn’t find a readily available cmd file for the LPC2129. I’ve modified
> cmd files I’ve found for the LPC2148 and I think it’s ok.
That’s what I did at first, and it worked out OK. IIRC, most of the differences between the LPC2k procs are in the peripherals and the _end_ addresses of ROM and RAM. So, if your linker command file correctly identifies the amount of RAM in your 2129, then you probably won’t have the problem of the start-up code setting the stack pointer in the wrong place, or “initializing” non-existent memory. Still, if something _is_ trying to read or write non-existent RAM, you’ll get a Data Fault, which may make your CPU crash.
When having problems with a new setup, I like to write a little spaghetti-code assembly language routine that does the bare minimum necessary to wiggle a pin or blink an LED or something. Check the assembled code and binary file pretty carefully, then turn your attention to getting that code flashed into the CPU and running. The crt0 startup for most systems does WAY more than you need, and if you’re not intimately familiar with it (and have trustworthy debugger support!) then it’ll waste way more of your time than writing a simple routine.
> So far when debugging, at best openOCD succeeds in flashing the board, but seems to timeout
> waiting for the processor to halt or something.
Have you gotten an LED-blinker program running? If so, you’re golden! (Or at least silver!)
Try telnetting to port 4444 on the machine where OpenOCD is running. Some commands that may be useful are: "halt", "soft_reset_halt", "resume", and "flash info 0". (You can get lists of other commands with "help". The interactive interface is a little wonky, though, particularly for the flash commands.)
Also, start OpenOCD from a terminal window; you may see warning or error messages there.
Typically, when GDB hangs, it’s because OpenOCD is confused about the JTAG state. One thing I’ve found helpful is to start OpenOCD first, then telnet to it and do “halt” followed by “soft_reset_halt”, and only after that, start GDB and have it connect to the target. I think it’s because OpenOCD is a little shaky at stopping and resetting the target.
So, the next-smallest step for you is to figure out how to get OpenOCD to work. If you can get it to dump Flash contents (“mdw 0 32”) that’s a good sign. If it recognizes the flash device, even better. Erase flash? Almost there. Program a binary file? Done.
Here’s the OpenOCD config file I use for a Wiggler parallel-port JTAG and LPC2148. I also have a board with an FTDI 2232 USB interface, but that was a LOT harder to figure out.
[BTW, I see you’ve just posted another message about OpenOCD…sounds like you’re on the right track.]
#reset_config trst_and_srst|trst_only|srst_only srst_pulls_trst|trst_pulls_srst|combined
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#target <type> <endianness> <startup mode> <chainpos> <variant>
target arm7tdmi little reset_halt 0 arm7tdmi-s_r4
flash bank lpc2000 0x0 0x7d000 0 0 lpc2000_v2 0 12000 calc_checksum