SparkFun Forums

[obilix]

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

Code: Select all

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:

Code: Select all

#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...

[Dominic]

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

[obilix]

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...

[Dominic]

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 <at> gmx.de?

Regards,

Dominic

[obilix]

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...

[obilix]

Dominic,

quick question:

Does it matter what mode the chip is in?

Should it be in Supervisor, System, other?

Thanks,


luis...

[Dominic]

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

[obilix]

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!

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...

[andreas]

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.

[obilix]

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...