Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

98 views
Skip to first unread message

David Madore

unread,
Sep 16, 2016, 4:00:03 AM9/16/16
to
Package: openocd
Version: 0.8.0-4

(I am reporting this against openocd version 0.8.0-4 because that is
what is found in Debian jessie, currently stable, but I also tried
0.9.0-1+b1, the version currently in sid.)

A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being
connected, version 0.5.0-1 (as found in Debian wheezy) of openocd
worked fine with it:

vega david ~ $ /tmp/openocd-0.5.0/src/openocd -f /tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.5.0 (2016-09-16-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
2000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: feroceon.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
Error: unexpected Feroceon EICE version signature
^C

but openocd 0.8.0 fails as follows:

vega david ~ $ /tmp/openocd-0.8.0/src/openocd -f /tmp/openocd-0.8.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : only one transport option; autoselect 'jtag'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Error: no device found
Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 'SheevaPlug JTAGKey FT2232D' and serial '*'
in procedure 'init'

The error message is almost identical with openocd 0.9.0:

vega david ~ $ /tmp/openocd-0.9.0/src/openocd -f /tmp/openocd-0.9.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.9.0 (2016-09-16-09:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Error: no device found
Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 'SheevaPlug JTAGKey FT2232D' and serial '*'

I also tried to get openocd 0.9.0 working with the openocd 0.5.0
scripts, with a different error message, but with no more success:

vega david ~ $ /tmp/openocd-0.9.0/src/openocd -f /tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.9.0 (2016-09-16-09:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Error: The specified debug interface was not found (ft2232)
The following debug interfaces are available:
1: parport
2: dummy
3: ftdi
4: usb_blaster
5: amt_jtagaccel
6: gw16012
7: usbprog
8: jlink
9: vsllink
10: rlink
11: ulink
12: arm-jtag-ew
13: buspirate
14: remote_bitbang
15: hla
16: osbdm
17: opendous
18: aice
19: cmsis-dap


--
David A. Madore
( http://www.madore.org/~david/ )

Paul Fertser

unread,
Sep 16, 2016, 4:20:02 AM9/16/16
to
Hello,

On Fri, Sep 16, 2016 at 09:55:21AM +0200, David Madore wrote:
> A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being

Please also provide lsusb -vvv data for this device.

> worked fine with it:
...
> Error: JTAG scan chain interrogation failed: all zeroes

No, this doesn't look fine to me.

> Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
...
> Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 'SheevaPlug JTAGKey FT2232D' and serial '*'

You might want to try to comment out ftdi_device_desc command from
interface/ftdi/sheevaplug.cfg to workaround this issue.

> The error message is almost identical with openocd 0.9.0:
...
> Error: unable to open ftdi device with vid 9e88, pid 9e8f,
> description 'SheevaPlug JTAGKey FT2232D' and serial '*'

The error you report seems to be fixed post-0.8.0, but before 0.9.0,
in v0.8.0-142-geab9af1 . So it looks as if you're trying to use 0.9.0
with scripts from 0.8.0.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:ferc...@gmail.com

David Madore

unread,
Sep 16, 2016, 6:30:02 AM9/16/16
to
On Fri, Sep 16, 2016 at 11:13:53AM +0300, Paul Fertser wrote:
> On Fri, Sep 16, 2016 at 09:55:21AM +0200, David Madore wrote:
> > A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being
>
> Please also provide lsusb -vvv data for this device.

Bus 003 Device 002: ID 9e88:9e8f
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x9e88
idProduct 0x9e8f
bcdDevice 5.00
iManufacturer 1 FTDI
iProduct 2 SheevaPlug JTAGKey FT2232D B
iSerial 3 FTU85Z4Y
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 55
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 SheevaPlug JTAGKey FT2232D B
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 SheevaPlug JTAGKey FT2232D B
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

> > worked fine with it:
> ...
> > Error: JTAG scan chain interrogation failed: all zeroes
>
> No, this doesn't look fine to me.

Indeed, the JTAG connector was badly connected at the other end.
Here's what the output of openocd 0.5.0-1 looks like when it's
correctly connected (to a GuruPlug):

vega david ~ $ /tmp/openocd-0.5.0/src/openocd -s /tmp/openocd-0.5.0/tcl -f /tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.5.0 (2016-09-16-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
2000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0x2)
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit

- and in case that's of any use, here's the additional stuff it says
when I run "reset ; init ; sheevaplug_load_uboot" from the telnet
interface:

Info : accepting 'telnet' connection from 4444
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0x2)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
230196 bytes written at address 0x00600000
downloaded 230196 bytes in 1.618897s (138.860 KiB/s)
verified 230196 bytes in 0.839952s (267.635 KiB/s)

> > Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
> ...
> > Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 'SheevaPlug JTAGKey FT2232D' and serial '*'
>
> You might want to try to comment out ftdi_device_desc command from
> interface/ftdi/sheevaplug.cfg to workaround this issue.

Now openocd connects to the device, but it still doesn't work:

vega david ~ $ $ /tmp/openocd-0.8.0/src/openocd -s /tmp/openocd-0.8.0/tcl -f /tmp/openocd-0.8.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : only one transport option; autoselect 'jtag'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz

At this point, the port 4444 is open (accepting connections), but
telnet to it does not provide a prompt; there does not seem to be
anything I can do except type ^C. The behavior is similar with 0.9.0,
except that ^C doesn't work there and I have to kill -9 it.

> > The error message is almost identical with openocd 0.9.0:
> ...
> > Error: unable to open ftdi device with vid 9e88, pid 9e8f,
> > description 'SheevaPlug JTAGKey FT2232D' and serial '*'
>
> The error you report seems to be fixed post-0.8.0, but before 0.9.0,
> in v0.8.0-142-geab9af1 . So it looks as if you're trying to use 0.9.0
> with scripts from 0.8.0.

Ah, indeed, PEBCK for that part, I forgot to pass a -s option when
using openocd from a compilation tree. But still, as noted above,
neither 0.8.0 nor 0.9.0 seem to be able to use the device, they just
get stuck.

Paul Fertser

unread,
Sep 16, 2016, 11:30:02 AM9/16/16
to
On Fri, Sep 16, 2016 at 12:22:12PM +0200, David Madore wrote:
> > The error you report seems to be fixed post-0.8.0, but before 0.9.0,
> > in v0.8.0-142-geab9af1 . So it looks as if you're trying to use 0.9.0
> > with scripts from 0.8.0.
>
> Ah, indeed, PEBCK for that part, I forgot to pass a -s option when
> using openocd from a compilation tree. But still, as noted above,
> neither 0.8.0 nor 0.9.0 seem to be able to use the device, they just
> get stuck.

In this case it would help to see -d3 output.

David Madore

unread,
Sep 16, 2016, 6:10:04 PM9/16/16
to
On Fri, Sep 16, 2016 at 06:25:27PM +0300, Paul Fertser wrote:
> In this case it would help to see -d3 output.

Attached are the output of

/tmp/openocd-0.5.0/src/openocd -s /tmp/openocd-0.5.0/tcl -f /tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg -d3

("openocd-good.log"), which is version 0.5.0-1 from Debian, and

/tmp/openocd-0.9.0/src/openocd -s /tmp/openocd-0.9.0/tcl -f /tmp/openocd-0.9.0/tcl/board/sheevaplug.cfg -d3

("openocd-bad.log"), which is version 0.9.0-1+b1 from Debian.

I have to say, however, that success connecting to the DreamPlug even
with openocd-0.5.0 is somewhat random (quite often I get "Error: JTAG
scan chain interrogation failed: all zeroes"), and I couldn't quite
decide whether the cause lies in the JTAGKey module, its JTAG
connection with the DreamPlug, on the DreamPlug itself. For some
reason, success is much better when the DreamPlug is in the U-Boot
bootloader than when it is in the Linux kernel. It's also possible
that running openocd-0.9.0 causes later attempts to use openocd-0.5.0
to fail. None of this is reliably reproducible, so I can't be too
certain about anything. Maybe the hardware is flaky. Still, my
success rate with openocd >=0.8.0 is exactly zero, while with <=0.7.0
it is fairly high.

Happy hacking,
openocd-good.log
openocd-bad.log

Paul Fertser

unread,
Sep 17, 2016, 4:30:03 PM9/17/16
to
On Fri, Sep 16, 2016 at 11:59:59PM +0200, David Madore wrote:
> Open On-Chip Debugger 0.5.0 (2016-09-16-09:33)
...
> Error: 217 472 core.c:945 jtag_examine_chain_check(): JTAG scan chain interrogation failed: all zeroes
> Error: 218 472 core.c:946 jtag_examine_chain_check(): Check JTAG interface, timings, target power, etc.
...
> Error: 230 476 feroceon.c:671 feroceon_examine(): unexpected Feroceon EICE version signature

Hm, can't see anything good about it...

David Madore

unread,
Sep 17, 2016, 5:00:03 PM9/17/16
to
On Sat, Sep 17, 2016 at 11:18:20PM +0300, Paul Fertser wrote:
> Hm, can't see anything good about it...

Ah, sorry, as I mentioned, behaviour is somewhat erratic even with
openocd-0.5.0. This log is definitely good (I was able to upload
U-Boot). Maybe the comparison between the two can be instructive in
some way? Also, even in the "bad" case (when "JTAG scan chain
interrogation failed: all zeroes"), openocd-0.5.0 will still let me
issue a reset command which works (whereas openocd-0.9.0 won't even
let me telnet).

Sorry about all the confusion!
openocd-good.log
0 new messages