On Monday 29 January 2007 20:06, Edwin Olson wrote: > Dominic Rath wrote:
>
> Thanks for the explanation (some of which I've trimmed from this
reply).
> I've got things more-or-less working now; I'm using jtag_speed 12,
which I
> reduce in my gdbinit script. I'm also currently using:
>
> reset_config trst_and_srst srst_pulls_trst
>
> I'm still not clear on the proper setting of these parameters, but it
seems
> to work.
> That's the correct setting for debugging a LPC2000, as they
internally force
nTRST low whenever nSRST is asserted (for code read protection (CRP), search
the group archive for details). I suppose the LPC23xx is similar in that
regard, but I don't have one to test myself. You could try to remove
the "srst_pulls_trst" and see if a "reset halt" (at the telnet prompt) gets
the target into debug mode at address 0x0 (but I don't think so).
> Can you (or someone else) clarify the role of ETM,
and how it interacts
> with JTAG? I.e., I've observed that P2.0-P2.7 stop working as GPIOs
when
> the JTAG header is plugged in, but it appears I can override the ETM
> function... Does openocd + arm-usb-ocd make use of ETM, or are they a
> purely JTAG implementation?
> I guess that's because the ARM-USB-OCD connects RTCK to GND. On
previous LPCs
(LPC21xx, LPC22xx), pulling RTCK low enabled the JTAG pins. This has changed
with the LPC23xx, which uses RTCK to enable/disable the trace pins. You could
try to disconnect that pin from the JTAG interface, or just have your
application code program the PINSEL register accordingly.
The OpenOCD is a JTAG only implementation with no trace capability.
I'm currently working on trace, but getting data from the ETM is going to
require (expensive) hardware in addition to the JTAG interface.
The LPC3180 I'm currently working with is an exception, as it contains an
ETB
(Embedded Trace Buffer) that allows trace data to be read using the JTAG
interface.
> I've also observed that arm-usb-ocd+openocd seem
to get "stuck" and become
> unresponsive occasionally (after repeated resets & crashes of my app);
I've
> been power cycling them (which fixes it), but is there a better way?
> Debugging resets is difficult enough with the LPCs because of the CRP
(see
above). You must never manually press a reset button while the OpenOCD is
running, as the OpenOCD can't detect that reset and the debugger and target
get out of sync.
Dominic Rath wrote: > the LPCs use the synthesizable ARM7TDMI-S core which
requires the JTAG signals
> to be synchronized to the core frequency. The synchronization circuit limits
> the maximum TCK frequency to 1/6th of the core frequency. Thanks for the explanation (some of which I've trimmed from this
reply). I've got things more-or-less working now; I'm using jtag_speed
12, which I reduce in my gdbinit script. I'm also currently using:
reset_config trst_and_srst srst_pulls_trst
I'm still not clear on the proper setting of these parameters, but it seems
to work.
Can you (or someone else) clarify the role of ETM, and how it interacts with
JTAG? I.e., I've observed that P2.0-P2.7 stop working as GPIOs when the
JTAG header is plugged in, but it appears I can override the ETM function...
Does openocd + arm-usb-ocd make use of ETM, or are they a purely JTAG
implementation?
I've also observed that arm-usb-ocd+openocd seem to get "stuck" and become
unresponsive occasionally (after repeated resets & crashes of my app); I've
been power cycling them (which fixes it), but is there a better way?
Thanks!
-Ed
Reply by Dominic Rath●January 28, 20072007-01-28
Hello Ed,
the LPCs use the synthesizable ARM7TDMI-S core which requires the JTAG signals
to be synchronized to the core frequency. The synchronization circuit limits
the maximum TCK frequency to 1/6th of the core frequency.
The FT2232 used in the arm-usb-ocd can be programmed to work at 6MHz / (1 +
divider), so your setting of "jtag_speed 3" makes the FT2232 run at 1.5MHz.
The LPC23xx starts up running from the internal RC oszillator at 4MHz. As long
as there's no software on the LPC that enables the main oszillator or PLL,
you have to limit the JTAG frequency to ~600kHz, "jtag_speed 9" should work,
but you could use a slightly higher value just to be sure.
You could use an initialization script that enables the PLL, switches the
clock source and then increases the JTAG frequency.
Regards,
Dominic
On Saturday 27 January 2007 19:27, EdwinOlson wrote: > I am using a linux/gcc toolchain with openocd and an
arm-usb-ocd. My
> target is an Keil MCB2300 with an LPC2378. (Repeat: I'm NOT using Keil
> tools, I'm using a gcc toolchain under Linux, but I can verify that
> the board's JTAG interface worked fine with Keil's ULINK2 and
uVision.)
>
> I've had trouble with the arm-usb-ocd debugger and the arm-usb-ocd:
> while I have gotten it to work a handful of times, most of the time, I
> get the following error:
>
> [eolson@localhost trunk]$ sudo ./src/openocd -fopenocd.cfg
> Info: openocd.c:84 main(): Open On-Chip Debugger (2006-01-26 13:30 CET)
> Error: jtag.c:1202 jtag_examine_chain(): number of discovered
> devices in JTAG chain (20) doesn't match configuration (1)
>
> There's only one JTAG device, so running openocd with --debug:
>
> [eolson@localhost trunk]$ sudo ./src/openocd -fopenocd.cfg --debug
> Info: openocd.c:84 main(): Open On-Chip Debugger (2006-01-26 13:30 CET)
> Debug: jtag.c:1307 jtag_init():
> Debug: ft2232.c:1246 ft2232_init(): 'ft2232' interface using
libftdi
> with 'olimex-jtag' layout
> Debug: ft2232.c:1374 ft2232_init(): current latency timer: 2
> Debug: ft2232.c:1583 olimex_jtag_init(): 80 08 1b
> Debug: ft2232.c:1626 olimex_jtag_init(): 82 09 0f
> Debug: ft2232.c:242 ft2232_speed(): 86 03 00
> Debug: jtag.c:258 jtag_call_event_callbacks(): jtag event: 1
> Debug: jtag.c:1106 jtag_reset_callback():
> Debug: jtag.c:258 jtag_call_event_callbacks(): jtag event: 1
> Debug: jtag.c:1106 jtag_reset_callback():
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Debug: jtag.c:1192 jtag_examine_chain(): JTAG device found:
> 0xffffffff (Manufacturer: 0x7ff, Part: 0xffff, Version: 0xf
> Error: jtag.c:1202 jtag_examine_chain(): number of discovered
> devices in JTAG chain (20) doesn't match configuration (1)
>
> So something is misbehaving... Unfortunately, I have no idea why it
> has sometimes worked: it seems random.
>
> I've played with the configuration file quite a lot, particularly the
> mysterious jtag_speed flag. My current configuration looks like:
>
> #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 3
> jtag_nsrst_delay 500
> jtag_ntrst_delay 500
>
> #use combined on interfaces or targets that can't set TRST/SRST
separately
> reset_config srst_only srst_pulls_trst
> #reset_config trst_and_srst srst_pulls_trst
>
> #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
> run_and_halt_time 0 30
>
> # For more information about the configuration files, take a look at:
> # http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger
>
> Any ideas? I'm eager to get a free toolchain up and running. (Please
> cc e...@mit.edu on any responses)
>
> Thanks!
>
> -Ed
Reply by EdwinOlson●January 27, 20072007-01-27
I am using a linux/gcc toolchain with openocd and an arm-usb-ocd. My
target is an Keil MCB2300 with an LPC2378. (Repeat: I'm NOT using Keil
tools, I'm using a gcc toolchain under Linux, but I can verify that
the board's JTAG interface worked fine with Keil's ULINK2 and
uVision.)
I've had trouble with the arm-usb-ocd debugger and the arm-usb-ocd:
while I have gotten it to work a handful of times, most of the time, I
get the following error:
[eolson@localhost trunk]$ sudo ./src/openocd -fopenocd.cfg
Info: openocd.c:84 main(): Open On-Chip Debugger (2006-01-26 13:30 CET)
Error: jtag.c:1202 jtag_examine_chain(): number of discovered
devices in JTAG chain (20) doesn't match configuration (1)
There's only one JTAG device, so running openocd with --debug:
#use combined on interfaces or targets that can't set TRST/SRST
separately
reset_config srst_only srst_pulls_trst
#reset_config trst_and_srst srst_pulls_trst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
