Jtagkey with OpenOCD works (sort of) on Mac OS X

Development Boards MicroMod
1

Hi all,

I’m using the the Amontec JTAGKey with the latest OpenOCD (rev65)

along with the FTTI’s beta ftd2xx driver.

I’ve compiled and installed the binaries to get OpenOCD to work under OS X 10.4.

What I’m noticing is that the processor is not being halted, even

though I can telnet to the deamon and issue the reset halt command.

I am guess that by not halting the CPU, running gdb to load an

image will cause the OpenOCD to time out with a

Error: arm7_9_common.c:1906 arm7_9_write_memory(): memory write caused data abort

I’m using an Olimex LPC-P2148 board.

here’s my config file:

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ftd2xx
ftd2xx_device_desc "Amontec JTAGkey A"
ftd2xx_layout jtagkey
ftd2xx_vid_pid 0x0403 0xcff8
jtag_speed 0
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst trst_pulls_srst

#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 <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little run_and_init 0 arm7tdmi-s_r4

#target_script 0 reset h2294_init.script
run_and_halt_time 0 30
working_area 0 0x40000000 0x4000 nobackup

#flash configuration
#flash bank lpc2000 0x0 0x7d000 0 0 lpc2000_v2 0 12000 calc_checksum
#flash bank cfi 0x80000000 0x400000 2 2 0

# mthomas: LPC2138 @ 12MHz 0x7D000 from 500*1024 (not 512!)
flash bank lpc2000 0x0 0x7D000 0 0 lpc2000_v2 0 12000 calc_checksum

Let me know if you need additional details.

Thanks,

luis…

2

You can’t use “reset halt” (target … reset_halt …) with an LPC2000. Debugging out of reset is not possible to allow protection of the flash content.

The argument to the “reset” command is optional, and the value specified in the cfg file (run_and_init in your cfg) is used if no argument is given. See http://openfacts.berlios.de/index-en.ph … figuration for a documentation of the cfg options.

To simulate a debug out of reset, reset the target (with run_and_halt or run_and_init), then execute a soft_reset_halt. If some peripherals (including PLL) got enabled before the core entered halt mode, you’ll have to disable them manually.

Regards,

Dominic

3

Thanks for the reply Dominic.

What I found out was that I FreeRTOS did not allow the CPU to halt.

I guess it is disabling some setting in the cpu…

So, I grabbed the blinky program from Olimex and am able to halt the cpu and perform some commands.

In experimenting with OpenOCD, via telnet, I tried to erase the flash partition as described at [Martin THOMAS’ website

poll

flash probe 0

flash erase 0 0 0

Unfortunately, the erase does not work for me.

This is the output (debug=3):

(telnet session)

poll

(OpenOCD debug output)

Info: server.c:62 add_connection(): accepted ‘telnet’ connection from 0

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

Debug: arm7_9_common.c:609 arm7_9_poll(): DBGACK set, dbg_state->value: 0x9

target state: halted

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

cpsr: 0x800000df pc: 0x0000015c

flash probe 0

flash ‘lpc2000’ found at 0x00000000

flash erase 0 0 0

Debug: target.c:480 target_alloc_working_area(): allocating new working area

Debug: arm7_9_common.c:1766 arm7_9_write_memory(): address: 0x40000000, size: 0x00000004, count: 0x00000002

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

Debug: arm7tdmi.c:394 arm7tdmi_write_xpsr_im8(): xpsr_im: d3, rot: 0, spsr: 0

Debug: arm7tdmi.c:394 arm7tdmi_write_xpsr_im8(): xpsr_im: df, rot: 0, spsr: 0

Debug: arm7tdmi.c:394 arm7tdmi_write_xpsr_im8(): xpsr_im: d3, rot: 0, spsr: 0

Debug: arm7tdmi.c:394 arm7tdmi_write_xpsr_im8(): xpsr_im: df, rot: 0, spsr: 0

Debug: arm7tdmi.c:394 arm7tdmi_write_xpsr_im8(): xpsr_im: d3, rot: 0, spsr: 0

Debug: arm7tdmi.c:394 arm7tdmi_write_xpsr_im8(): xpsr_im: df, rot: 0, spsr: 0

Debug: target.c:581 target_write_buffer(): writing buffer of 24 byte at 0x40000008

Debug: arm7_9_common.c:1766 arm7_9_write_memory(): address: 0x40000008, size: 0x00000004, count: 0x00000006

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

Debug: target.c:581 target_write_buffer(): writing buffer of 12 byte at 0x40000020

Debug: arm7_9_common.c:1766 arm7_9_write_memory(): address: 0x40000020, size: 0x00000004, count: 0x00000003

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

Debug: armv4_5.c:533 armv4_5_run_algorithm(): setting core_mode: 0x13

Debug: breakpoints.c:85 breakpoint_add(): added hardware breakpoint at 0x40000004 of length 0x00000004

Debug: arm7_9_common.c:1277 arm7_9_resume():

Debug: embeddedice.c:249 embeddedice_write_reg(): 8: 0x40000004

Debug: embeddedice.c:249 embeddedice_write_reg(): 9: 0x00000003

Debug: embeddedice.c:249 embeddedice_write_reg(): 11: 0xffffffff

Debug: embeddedice.c:249 embeddedice_write_reg(): 13: 0x000000f7

Debug: embeddedice.c:249 embeddedice_write_reg(): 12: 0x00000100

Debug: arm7_9_common.c:1078 arm7_9_restore_context():

Debug: arm7_9_common.c:1094 arm7_9_restore_context(): examining User mode

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r0

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r1

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r2

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r3

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r4

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r5

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r6

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r12

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: cpsr

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 0 of mode User with value 0x40000008

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 1 of mode User with value 0x40000020

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 2 of mode User with value 0x00022f0f

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 3 of mode User with value 0x004c4b3f

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 4 of mode User with value 0x00000000

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 5 of mode User with value 0xe01fc040

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 6 of mode User with value 0x80623000

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 12 of mode User with value 0x7ffffff1

Debug: arm7_9_common.c:1094 arm7_9_restore_context(): examining FIQ mode

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1094 arm7_9_restore_context(): examining IRQ mode

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1094 arm7_9_restore_context(): examining Supervisor mode

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: r13_svc

Debug: arm7_9_common.c:1115 arm7_9_restore_context(): require mode change

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: lr_svc

Debug: arm7_9_common.c:1115 arm7_9_restore_context(): require mode change

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7tdmi.c:394 arm7tdmi_write_xpsr_im8(): xpsr_im: d3, rot: 0, spsr: 0

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 13 of mode Supervisor with value 0x400000ac

Debug: arm7_9_common.c:1156 arm7_9_restore_context(): writing register 14 of mode Supervisor with value 0x40000004

Debug: arm7_9_common.c:1094 arm7_9_restore_context(): examining Abort mode

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1094 arm7_9_restore_context(): examining Undefined mode

Debug: arm7_9_common.c:1108 arm7_9_restore_context(): examining dirty reg: pc

Debug: arm7_9_common.c:1188 arm7_9_restore_context(): writing cpsr with value 0x800000d3

Debug: arm7tdmi.c:363 arm7tdmi_write_xpsr(): xpsr: 800000d3, spsr: 0

Debug: arm7_9_common.c:1195 arm7_9_restore_context(): writing PC with value 0x40000000

Debug: embeddedice.c:249 embeddedice_write_reg(): 0: 0x00000004

Debug: target.c:400 target_call_event_callbacks(): target event 4

Debug: arm7_9_common.c:1380 arm7_9_resume(): target resumed

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

…

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

Error: armv4_5.c:554 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target

Debug: arm7_9_common.c:771 arm7_9_halt(): target->state: debug_running

Debug: embeddedice.c:249 embeddedice_write_reg(): 9: 0xffffffff

Debug: embeddedice.c:249 embeddedice_write_reg(): 11: 0xffffffff

Debug: embeddedice.c:249 embeddedice_write_reg(): 12: 0x00000100

Debug: embeddedice.c:249 embeddedice_write_reg(): 13: 0x000000f7

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

Debug: arm7_9_common.c:609 arm7_9_poll(): DBGACK set, dbg_state->value: 0x9

Debug: embeddedice.c:249 embeddedice_write_reg(): 0: 0x00000005

Debug: embeddedice.c:249 embeddedice_write_reg(): 9: 0x00000003

Debug: embeddedice.c:249 embeddedice_write_reg(): 11: 0xffffffff

Debug: embeddedice.c:249 embeddedice_write_reg(): 13: 0x000000f7

Debug: embeddedice.c:249 embeddedice_write_reg(): 12: 0x00000100

Debug: arm7_9_common.c:903 arm7_9_debug_entry(): target entered debug from ARM state

Debug: arm7_9_common.c:922 arm7_9_debug_entry(): target entered debug state in Undefined mode

Debug: arm7_9_common.c:963 arm7_9_debug_entry(): entered debug state at PC 0x2e4

Debug: target.c:400 target_call_event_callbacks(): target event 3

Debug: embeddedice.c:249 embeddedice_write_reg(): 12: 0x00000000

Debug: target.c:639 target_read_buffer(): reading buffer of 12 byte at 0x40000020

Debug: arm7_9_common.c:1621 arm7_9_read_memory(): address: 0x40000020, size: 0x00000004, count: 0x00000003

Debug: embeddedice.c:153 embeddedice_read_reg_w_check(): 1

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r0 with value 0x40000008

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r1 with value 0x40000020

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r2 with value 0x00023e73

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r3 with value 0x004c0000

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r4 with value 0x00000000

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r5 with value 0xe01fc040

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r6 with value 0x80623000

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r7 with value 0x00000000

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r8 with value 0x00000040

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r9 with value 0x00000000

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r10 with value 0x00000040

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r11 with value 0x40007ed4

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r12 with value 0x40007ed8

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register r13_svc with value 0x400000ac

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register lr_svc with value 0x40000004

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register pc with value 0x000002e4

Debug: armv4_5.c:603 armv4_5_run_algorithm(): restoring register spsr_svc with value 0x00000000

Warning: lpc2000.c:445 lpc2000_erase(): lpc2000 erase sectors returned 2067070976

Which gives back a “flash erase error” on the telnet side.

Trying an “flash erase 0 0 1” comes back with the same type of error.

Any clues?

I do appreciate your help, and it is looking good to be able to do embedded development on the Mac OS X platform…

luis…](http://gandalf.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html)

4

Hi,

sorry I didn’t answer your post earlier, but I completely missed it.

I’m not sure what FreeRTOS does that stops OpenOCD from halting your target. The only thing I can imagine is that it changes the JTAG pins to GPIO.

I have to admit that I’m not sure what’s causing your problems with flash erase. Could you please send me the complete log-file with the exact .cfg file you used to Dominic.Rath gmx.de?

Regards,

Dominic

5

Dominic,

I figured out what my problem was with halting the FreeRTOS.

As your mentioned, some of my GPIO pins were set for output.

So that works fine now.

My configuration and errors are the posts.

I’ll send them to you as you requested.

If need be, I could set up an account on my machine and let

you try out what is going on the LPC2148.

Just let me know.

luis…

6

Dominic,

quick question:

Does it matter what mode the chip is in?

Should it be in Supervisor, System, other?

Thanks,

luis…

7

Hello Luis,

thank you for sending me your log.

You have to lower the jtag_speed to 2 or maybe 3. With a FT2232 device, the JTAG clock is 6MHz / (1 + jtag_speed). You can’t use a JTAG clock of more than 1/6th of the processor core frequency with a ARM7TDMI-S, but that shouldn’t matter, as the USB communication limits the effective JTAG rate to about 1.5 MHz.

The current core mode doesn’t matter, as OpenOCD switches the core to a non-user mode before running the flash algorithm, and restores the state after it is finished.

Regards,

Dominic

8

Thank’s to Dominic’s never-ending development, we have the first step

to a fully working Mac OS X PPC version! Need to smarten up those bits

and put them in the right positions! darned endianess, what does that exist! :roll:

OpenOCD will now stop the ARM core properly and is able to erase

the contents of the flash. Programing of the flash work partially.

There seems to be an issue with files > 64KB, but that’s for another thread…

9

obilix:
Hi all,

I’m using the the Amontec JTAGKey with the latest OpenOCD (rev65)

along with the FTTI’s beta ftd2xx driver.

Where did you get this driver? I haven’t found a version for OS X on ftdichip.com.

10

Andreas,

The driver is still beta, and they announce these drivers in their news letter.

Anyways, here’s the latest beta:

Current Mac OS X Driver Versions

D2XX (PPC - Requires Mac OS X 10.3 “Panther” or later) BETA [0.0.3

D2XX (Unversal Binary - Requires Mac OS X 10.4 “Tiger” or later) BETA [0.0.3

I haven’t had any kernel panics as a result of using this driver, unlike the drivers from some other usb vendor which keeps knocking me out.

cheers!

luis…](http://www.ftdichip.com/Drivers/D2XX/MacOSX/UniBin/UnivD2XX0.0.3.zip)](http://www.ftdichip.com/Drivers/D2XX/MacOSX/PPCD2XX0.0.3.zip)