OpenOCD (64-bit FTDI compile) + Flyswatter + LPC2368 .cfg?

Development Boards MicroMod
1

So I’m reasonably confident that my OpenOCD compilation is working fine and that I just don’t know how to use it. I’m trying to connect to an LPC2368 through a Tin Can Tools Flyswatter. When I run OpenOCD with default flyswatter.cfg file, I get the following output:

$ ./openocd.exe -f …/interface/flyswatter.cfg

Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-09-15:58)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.berlios.de/doc/doxygen/bugs.html

Info : device: 4 “2232C”

Info : deviceID: 67330064

Info : SerialNumber: FS000000A

Info : Description: Flyswatter A

Info : clock speed 6000 kHz

Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!

Error: JTAG scan chain interrogation failed: all ones

Error: Check JTAG interface, timings, target power, etc.

Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!

Error: JTAG scan chain interrogation failed: all ones

Error: Check JTAG interface, timings, target power, etc.

Command handler execution failed

Warn : jtag initialization failed; try ‘jtag init’ again.

Warn : gdb services need one or more targets defined

I can connect over telnet to 4444 and verify that my gdb port is 3333, but I’m unable to connect with any of my GDB-like tools (including NoICE). Mind you, I’m a novice when it comes to OCD and GDB configs, and I might be messing that up instead.

Here is the included flyswatter.cfg if it helps:

TinCanTools Flyswatter

http://www.tincantools.com/product.php?productid=16134

interface ft2232

ft2232_device_desc “Flyswatter”

ft2232_layout “flyswatter”

ft2232_vid_pid 0x0403 0x6010

The warnings and errors when OpenOCD starts up concern me, but I can’t find anywhere in the documentation that actually says how to resolve situations like that.

2

Homncruse:
The warnings and errors when OpenOCD starts up concern me, but I can’t find anywhere in the documentation that actually says how to resolve situations like that.

Generally, it won’t work after the first error/warning, so don’t ignore them!

In this case I think you need to specify a target config file for the LPC2368. There doesn’t appear to be one in the openocd library, so you will need to find or create one. I guess one of the other LPC devices will be a good starting point.

3

I found a lpc2378.cfg in the tcl/target directory (why is there a redundant /openocd/interface and /openocd/board directory when they exist in /openocd/tcl?). It seems to connect fine, though it gives me EmbeddedICE errors:

$ ./openocd.exe -f …/tcl/interface/flyswatter.cfg -f …/tcl/target/lpc2378.cfg

Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-09-15:58)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.berlios.de/doc/doxygen/bugs.html

adapter_nsrst_delay: 200

jtag_ntrst_delay: 200

trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain

500 kHz

Info : device: 4 “2232C”

Info : deviceID: 67330064

Info : SerialNumber: FS000000A

Info : Description: Flyswatter A

Info : clock speed 500 kHz

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

Info : Embedded ICE version 7

Error: EmbeddedICE v7 handling might be broken

Info : lpc2378.cpu: hardware has 2 breakpoint/watchpoint units

However, I’m able to telnet to localhost:4444 and issue a halt command:

Open On-Chip Debugger

halt

target state: halted

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

cpsr: 0x80000013 pc: 0x0001b6f0

And that looks sane…

But when I open gdb and issue “target remote localhost:3333”, I get the following:

Info : accepting ‘gdb’ connection from 0

Warn : acknowledgment received, but no packet pending

And gdb is all kinds of confused (thinks the PC is at 0x0, etc.), so I think my gdb config needs more work - HOWEVER, the fact that I was able to halt successfully is a good sign!

For posterity, here is the included lpc2378.cfg file in case someone comes along this thread and doesn’t have it for some reason:

NXP LPC2378 ARM7TDMI-S with 512kB Flash and 32kB Local On-Chip SRAM (58kB total), clocked with 4MHz internal RC oscillator

if { [info exists CHIPNAME] } {

set _CHIPNAME $CHIPNAME

} else {

set _CHIPNAME lpc2378

}

if { [info exists ENDIAN] } {

set _ENDIAN $ENDIAN

} else {

set _ENDIAN little

}

if { [info exists CPUTAPID ] } {

set _CPUTAPID $CPUTAPID

} else {

set _CPUTAPID 0x4f1f0f0f

}

#delays on reset lines

adapter_nsrst_delay 200

jtag_ntrst_delay 200

LPC2000 → SRST causes TRST

reset_config trst_and_srst srst_pulls_trst

jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi-s_r4

LPC2378 has 32kB of SRAM on its main system bus (so-called Local On-Chip SRAM)

$_TARGETNAME configure -work-area-phys 0x40000000 -work-area-size 0x8000 -work-area-backup 0

$_TARGETNAME configure -event reset-init {

Force target into ARM state

arm core_state arm

#do not remap 0x0000-0x0020 to anything but the flash

mwb 0xE01FC040 0x01

}

LPC2378 has 512kB of FLASH, but upper 8kB are occupied by bootloader.

After reset the chip uses its internal 4MHz RC oscillator

#flash bank lpc2000 0 0 <target#>

set _FLASHNAME $_CHIPNAME.flash

flash bank $_FLASHNAME lpc2000 0x0 0x0007D000 0 0 $_TARGETNAME lpc2000_v2 4000 calc_checksum

4MHz / 6 = 666kHz, so use 500

adapter_khz 500

Now to get gdb happy…

4

Homncruse:
But when I open gdb and issue “target remote localhost:4444”, I get the following:

Should it be “target remote localhost:3333” for gdb ?

5

bobcousins:

Homncruse:
But when I open gdb and issue “target remote localhost:4444”, I get the following:

Should it be “target remote localhost:3333” for gdb ?

Yeah… long day. Typo in the post, I’ve actually been doing 3333.

6

It seems that part of my issue was that I was simply using a buggy version of gdb, but there are a few lingering warnings and errors I can’t seem to find any information on.

$ ./openocd.exe -f ../tcl/interface/flyswatter.cfg -f ../tcl/target/lpc2378.cfg

Output from OpenOCD:

Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-09-15:58)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.berlios.de/doc/doxygen/bugs.html

adapter_nsrst_delay: 200

jtag_ntrst_delay: 200

trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain

500 kHz

Info : device: 4 “2232C”

Info : deviceID: 67330064

Info : SerialNumber: FS000000A

Info : Description: Flyswatter A

Info : clock speed 500 kHz

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

Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken

Info : lpc2378.cpu: hardware has 2 breakpoint/watchpoint units

When I connect with the latest arm-elf-gdb from Yagarto (7.0.1) and issue

target remote localhost:3333

OpenOCD says the following:

Info : accepting ‘gdb’ connection from 0

Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Warn : target not halted

And “info reg” gives me all zeroes, so it’s clearly not connected properly. I’m using the same config files outlined in my earlier post. It seems pretty likely that the problem lies in OpenOCD needing to reset the target, but I’m not finding any additional useful information.