Hi all,
First, sorry for posting on multiple lists, but I think this is appropriate
in this case.
Since I've used a second (still FT2232H-based) JTAG adapter I can see that the
deadlocks that
I experienced are not due to my original JTAG adapter.
Using libftd2xx 1.0.4 at the moment, but it's probably not an issue (more on
that later).
I noticed that urjtag and OpenOCD have issues, don't know yet if it's related
to FTDI cable or the JTAG chain (tested on 2 different ARM-based chains, same
thing).
xc3sprog always works fine after n invocations; let's run it a couple of times,
just to print the JTAG chain:
$ ~/dev/xc3sprog-git_svn/xc3sprog -c arm-usb-ocd-h -j
XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
JTAG loc.: 0 IDCODE: 0x1b7d102f Desc: OMAP-L138 Rev: A IR
length: 6
$ ~/dev/xc3sprog-git_svn/xc3sprog -c arm-usb-ocd-h -j
XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
JTAG loc.: 0 IDCODE: 0x1b7d102f Desc: OMAP-L138 Rev: A IR
length: 6
$
Now, let's say I want to run UrJTAG, it works once but not a second time:
$ echo -ne "cable ARM-USB-OCD-H\ndetect\n" | ~/opt/urjtag/bin/jtag
Connected to libftd2xx driver.
IR length: 6
Chain length: 1
Device Id: 00011011011111010001000000101111 (0x1B7D102F)
Manufacturer: Texas Instruments (0x02F)
Unknown part! (1011011111010001)
(/home/cJ/opt/urjtag/share/urjtag/ti/PARTS)
$ echo -ne "cable ARM-USB-OCD-H\ndetect\n" | ~/opt/urjtag/bin/jtag
Connected to libftd2xx driver.
[nothing happens, locked in FT_Read]
^C
If I run xc3sprog then UrJTAG again, UrJTAG is not happy, but in a different
way:
$ echo -ne "cable ARM-USB-OCD-H\ndetect\n" | ~/opt/urjtag/bin/jtag
Connected to libftd2xx driver.
error: when parsing command 'detect'
$
Now let's run OpenOCD, it initializes properly (same thing if run after
xc3sprog):
$ ~/opt/openocd/bin/openocd -f config.cfg
Open On-Chip Debugger 0.6.0-dev-00477-gf1c0133 (2012-03-26-20:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Error: unable to get latency timer: OK
Error: ftd2xx 1.04 detected - this has known issues with FT_GetLatencyTimer,
upgrade to a newer version
Info : device: 6 "2232H"
Info : deviceID: 364511275
Info : SerialNumber: OLUSXGHBA
Info : Description: Olimex OpenOCD JTAG ARM-USB-OCD-H A
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Info : JTAG tap: omapl138.jrc tap/device found: 0x1b7d102f (mfg: 0x017,
part: 0xb7d1, ver: 0x1)
Info : JTAG tap: omapl138.etb enabled
Info : JTAG tap: omapl138.arm enabled
Info : Embedded ICE version 6
Info : omapl138.arm: hardware has 2 breakpoint/watchpoint units
Info : ETM v1.3
^C # chain detected
$
Let's run it a second time, it does not work so well anymore:
$ ~/opt/openocd/bin/openocd -f config.cfg
Open On-Chip Debugger 0.6.0-dev-00477-gf1c0133 (2012-03-26-20:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
RCLK - adaptive
RCLK - adaptive
fast memory access is enabled
dcc downloads are enabled
force hard breakpoints
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Error: unable to get latency timer: OK
Error: ftd2xx 1.04 detected - this has known issues with FT_GetLatencyTimer,
upgrade to a newer version
Info : device: 6 "2232H"
Info : deviceID: 364511275
Info : SerialNumber: OLUSXGHBA
Info : Description: Olimex OpenOCD JTAG ARM-USB-OCD-H A
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
^C # stuck in JTAG init
$
If I run xc3sprog then OpenOCD afterwards, OpenOCD will initialize properly.
So currently, I run xc3sprog to detect the JTAG chain prior any OpenOCD
invocation.
I spent a few minutes in the code but nothing yet.
Oh wait, if I run xc3sprog, then OpenOCD, then UrJTAG, then UrJTAG can work !
I say "can" because it seems to work with a higher probability when OpenOCD
is shutdown quickly after it started.
UrJTAG behaves in the same way when using libftdi, so I don't think it's
ftd2xx's fault.
At the moment I have no diagnostic, just stupid workarounds.
I'd like to know if other people have encountered something like that before.
Perhaps someone has ideas on how to better diagnose this (I can live with
my work-arounds, as they are included in scripts, but I'm not glad I
have to resort to that).
Best regards,
--
cJ
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
UrJTAG-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/urjtag-development
