OpenOCD and LPC2101 - Degug init code

Development Boards MicroMod
1

Hello,

I have a board with a LPC2101 processor, and I am debugging it with OpenOCD.

I would like to know if anyone can help to understand what is going on…

I connected to de board using telnet and run the following commands:

reset

JTAG tap: lpc2101.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)

reset halt

JTAG tap: lpc2101.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)

target state: halted

target halted in ARM state due to debug-request, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000000

step

target state: halted

target halted in ARM state due to single-step, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000004

step

target state: halted

target halted in ARM state due to single-step, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000008

step

target state: halted

target halted in ARM state due to single-step, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x0000000c

step

target state: halted

target halted in ARM state due to single-step, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000010

step

timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0

Runtime error, file “command.c”, line 473:

I do not understand why after the first command “step” program counter goes to 0x00000004

when my init code is the following:

Vectors:

b _start // reset - _start

ldr pc,_undf // undefined - _undf

ldr pc,_swi // SWI - _swi

ldr pc,_pabt // program abort - _pabt

ldr pc,_dabt // data abort - _dabt

nop // reserved

ldr pc,[pc,#-0xFF0] // IRQ - read the VIC

ldr pc,_fiq // FIQ - _fiq

it shouldn’t go to “_start”?

Thanks

2

Sorry for the late reply Thomas. You’ve probably solved this by now, but if not…

Maybe you should display the memory location from 0x00 to 0x40 and make sure it is what you expected. It could be that you are in user RAM mode or (more likely) stuck in bootloader mode, so that the interrupt vectors are re-mapped.

I guess it cannot hurt to ask if you’re certain you’ve gotten the magic checksum into location 0x14. Some loaders (like the NXP utility) automatically calculate that for you. OpenOCD does not.

My (mildly frustrating) experience with the LPC21xx parts has been almost the opposite of what you describe. Since the bootloader always runs, openocd cannot get control immediately after reset, but must issue the halt command after a delay which is adjustable in the config files. So, unless I put a delay loop early in crt.s, by the time openOCD halts the uC, all the init code is already done.

-Hugh

3

hsutherl:
I guess it cannot hurt to ask if you’re certain you’ve gotten the magic checksum into location 0x14. Some loaders (like the NXP utility) automatically calculate that for you. OpenOCD does not.

OpenOCD does, but if someone replaces GOOD config files with some random scraps from the network, than... you know.

My (mildly frustrating) experience with the LPC21xx parts has been almost the opposite of what you describe. Since the bootloader always runs, openocd cannot get control immediately after reset, but must issue the halt command after a delay which is adjustable in the config files. So, unless I put a delay loop early in crt.s, by the time openOCD halts the uC, all the init code is already done.

Perfectly true - debugging the first steps of the core is impossible with LPCs.

4/3!!

4

You do need to get a stack setup, but then do a branch to a function that is a while(1). Then you invoke gdb and tell it to jump to the location after the call to the loop.

Here’s what my asm code looks like after getting a stack set up:

/*

let the application stop processor advancement if they want

to get gdb started at a known location. after starting gdb

they need to tell gdb jump past_gdb_hook

*/

bl gdb_hook

.global past_gdb_hook

past_gdb_hook:

ldr r1, =system_stack_ptr

ldr sp, [r1]

I reset the system stack pointer after the call to gdb_hook. Once the debugger is no longer needed, ifdef out the while(1) in the gdb_hook function.