I'm having trouble debuging the blinky example on my lpc2138 (MCB2130 board) The program is compiled from Eclipse using the arm-elf-gcc compiler with a startup.s file which comes from a blinky example for the MCB2100 board, which has a LPC2129. When debuging it seems as if the program gets stuck either around address 0x00000240 or around 0x7FFFD2A2, the first being an flash memory address and the second being the RAM boot block. It could also be the RAM.ld linker script that's causing the problem, since it's also taken from a MCB2100 blinky example. Does anyone have a startup.s and Ram.ld for the MCB2130 board for GNU? Or even better, does anyone know what's causing the problem, and how it's fixed? Best Regards Søren Hansen Mjølner Informatics A/S Denmark
I just tried the example Keil\ARM\GNU\Boards\Keil\MCB2100 on the MCB2130 Board. It just runs fine (I only changed the Flash programming alorithm to the IAP2). So I do not really understand where your problem is. Maybe you debug first in the Simulator. Reinhard
Are you using the debugger in uVision? When I try this program in uVision with the CARM compiler, the AIN0 doesn't work, since the example includes LPC21xx.h instead og LPC213x.h and ADCR is AD0CR on the LPC2138. There are also a number of other smaller errors regarding start of A/D convertion. As stated I tried using the arm-elf-gdb debugger, whithout succes. Maybe it when I load the program that it gets the wrong starting address. What happens is that it gets stuck on address 0x00000048 Best Regards Søren Hansen
Sorry - I can see that I didn't mention earlier, that I'm using the arm-elf-gdb as debugger. Best Regards Søren Hansen
Maybe you should try the Keil ARM tools instead. You can download an Eval Version from: http://www.keil.com/demo Included are several example projects for the MCB2130 Board. Reinhard
I would really like to use gdb, since I have a lot of experience with this tool. I'm not using the ULINK from Keil, but the RAVEN OCDemon from Macraigor. I don't know if this should cause any trouble, since they are both JTAG adapters. If I load the program to RAM and then makes one nexti statement, it is possible to make a continue afterwards. But if I make a continue right away, the PC jumps to address 0x00000048 and stays there. It seems as if the startup.s file is the root to this problem. Is there a GNU startup.s for MCB2130? Best Regards Søren Hansen
From the STARTUP file point of view all Philips LPC2xxx parts are identical. The startup code is in Keil\GNU\STARTUP\Philips. Reinhard P.S. Did you tried Keil ULINK together with uVision?
I haven't tried the ULINK/uVision combo yet, since I'm having a little trouble how to debug a program compiled outside uVision. Do I have to make a project an import all the source files, or could I just tell the debugger which .elf file I would like to debug? Best Regards Søren Hansen
You do not need a complex setup. Basically this should help: http://www.keil.com/support/docs/2310.htm Reinhard
I have forgot to tell you. Use the simulator before you got to target hardware. This really reduces debugging time a lot, since you need not to struggle with incorrect device/peripheral initializations that disable for example the JTAG interface. Reinhard
Thanks for the link - I'll try that first thing. Does the ULINK and uVision use some kind of alternatet JTAG protocol for debugging the LPC2138? When I try to use the RAVEN OCDemon with OCDRemote and arm-elf-gdb, I get a lot of "SW breakpoint at 0x[address]: unable to write breakpoint: Target bus error" messages Best Regards Søren Hansen
ULINK uses the Embedded ICE to set breakpoints (when it cannot write into the memory). Reinhard