OpenOCD Issues

I finally have Open OCD (Running through eclipse) functioning on an IAR Kickstart board (LPC2106). Yea!

I am unable to get it to run on a Keil board, the MCB2100 (LPC2124).

The debugger APPEARS to program the micro but then it just hangs while the “launching” progress bar runs, forever.

The console output when I start the debugger:

(gdb) target state: halted

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

cpsr: 0x600000d7 pc: 0x000002ec

flash ‘lpc2000’ found at 0x00000000

erased sectors 0 through 0 on flash bank 0 in 0s 641043us

wrote file main.bin to flash bank 0 at offset 0x00000000 in 0s 656678us

requesting target halt and executing a soft reset

force hardware breakpoints enabled


*The CFG file I am using:


#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface ft2232

ft2232_device_desc “Olimex OpenOCD JTAG A”

ft2232_layout “olimex-jtag”

ft2232_vid_pid 0x15BA 0x0003

jtag_speed 10

#use combined on interfaces or targets that can’t set TRST/SRST separately

reset_config trst_and_srst separate

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 4 0x1 0xf 0xe

#target configuration

daemon_startup reset

#target

#target arm7tdmi

target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

run_and_halt_time 0 30

#target_script 0 reset oocd_flash2138.script

working_area 0 0x40000000 0x40000 nobackup

#flash configuration

flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14765 calc_checksum

For more information about the configuration files, take a look at:

http://openfacts.berlios.de/index-en.ph … p+Debugger

Thanks for the help

Rich

Hello Richard,

I’ve posted the same reply to your thread in the lpc2000 group.

if it works on a LPC2106 then it’s got to work on the LPC2124, too.

I have no idea what Eclipse does while that “launching” progress bar runs - that’s one of the reasons why I don’t use it, it hides what’s happening.

What you could try to check:

  • Jumper settings. If P0.14 is low then the LPC is going to enter bootloader mode, and your application wont be started

  • Try without Eclipse. Use the telnet interface at first, to verify everything’s working as expected. If your application doesn’t operate properly (like no LED blinking), issue a “halt”, and see what PC is reported, the current mode the uC is in and so on. You can display all ARM registers using the “armv4_5 reg” command. There’s even a disassembler available using the “armv4_5 disassemble ” command.

Regards,

Dominic

Thank you for the help Dominic. Here are the results from a halt and a register dump. It appears I have ended up in a data abort exception, not sure why…

Rich

Open On-Chip Debugger

halt

requesting target halt…

Target 0 halted

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

cpsr: 0x600000d7 pc: 0x000002e8

armv4_5 reg

r0: 00000000 r0: 00000000 r0: 00000000 r0: 00000000 r0: 00000000 r0: 00000000

r1: 40000234 r1: 40000234 r1: 40000234 r1: 40000234 r1: 40000234 r1: 40000234

r2: 40000234 r2: 40000234 r2: 40000234 r2: 40000234 r2: 40000234 r2: 40000234

r3: 40000218 r3: 40000218 r3: 40000218 r3: 40000218 r3: 40000218 r3: 40000218

r4: 00000000 r4: 00000000 r4: 00000000 r4: 00000000 r4: 00000000 r4: 00000000

r5: e01fc040 r5: e01fc040 r5: e01fc040 r5: e01fc040 r5: e01fc040 r5: e01fc040

r6: 40000128 r6: 40000128 r6: 40000128 r6: 40000128 r6: 40000128 r6: 40000128

r7: 00000000 r7: 00000000 r7: 00000000 r7: 00000000 r7: 00000000 r7: 00000000

r8: 900d89c8 r8_fiq: 0099400d r8: 900d89c8 r8: 900d89c8 r8: 900d89c8 r8: 900d89c8

r9: 00039020 r9_fiq: 805040a4 r9: 00039020 r9: 00039020 r9: 00039020 r9: 00039020

r10: 9057700c r10_fiq: c50c1330 r10: 9057700c r10: 9057700c r10: 9057700c r10: 9057700c

r11: 40003ff8 r11_fiq: 100b02c8 r11: 40003ff8 r11: 40003ff8 r11: 40003ff8 r11: 40003ff8

r12: 40003ffc r12_fiq: 29805100 r12: 40003ffc r12: 40003ffc r12: 40003ffc r12: 40003ffc

r13_usr: 4000feb8 r13_fiq: 4000fed4 r13_irq: 4000fed0 r13_svc: 4000fecc r13_abt: 40003fec r13_und: 4000fedc

lr_usr: 240a2852 lr_fiq: 8c26be40 lr_irq: 040a0a64 lr_svc: 7fffe2cf lr_abt: 000002e0 lr_und: 3ee0c112

pc: 000002e8 pc: 000002e8 pc: 000002e8 pc: 000002e8 pc: 000002e8 pc: 000002e8

cpsr: 600000d7 spsr_fiq: 00000010 spsr_irq: 00000010 spsr_svc: 00000010 spsr_abt: 600000d7 spsr_und: 00000010

yes, the 0xD7 in the CPSR indicates a Data Abort. Now why?..

I have installed the Yagarto toolchain to try the insight debugger. I end up with a similar result. I see this output in the console window:

target state: running

requesting target halt and executing a soft reset

software breakpoints enabled

error: access caused data abort, system possibly corrupted

0xe01fc040: 00000002

Rich

Data exceptions are usually pointer bugs where you are trying to read or write non-existent memory locations. Overwriting the stack is a good way to get a bad pointer. Another good way is using a register but not saving it during an interrupt.