This issue appears to be affecting me as well while trying to connect to a
DreamPlug.
Most of my troubleshooting has been performed using with Vagrant
debian/jessie64. I've tried the backports package for 'openocd' as well,
and dist-upgrading to Stretch. The only difference I've noticed is that
the OpenOCD shipped with Jessie (0.8.0-4) refuses to match the adapter with
this line in place in
"/usr/share/openocd/scripts/interface/ftdi/sheevaplug.cfg".
> ftdi_device_desc "SheevaPlug JTAGKey FT2232D B"
On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
andr...@fritiofson.net> wrote:
> A lot has happened since 0.5.0 apart from the adapter driver change so the
> problem might lie somewhere else than ftdi vs ft2232. Can you try the
> latest release that included the ft2232 driver (0.8?), or even better,
> build from source and explicitly pass --enable-legacy-ft2232_libftdi to
> configure (make sure you have libusb-1.0 and libftdi dev packages
> installed). The feroceon target has AFAIK not been tested in a long time
so
> there might be issues with that. Does the hardware allow you to connect
> other targets to the same debug adapter or vice versa (i.e. an external
> debug connector or such)? Just trying to reduce the number of unknowns.
I compiled OpenOCD 0.9.0 from source first without
"--enable-legacy-ft2232_libftdi" to confirm no change in behavior, and then
with "--enable-legacy-ft2232_libftdi". With a couple caveats, it's
actually working now.
Caveat 1: Switching back to the non-FTDI interface is necessary (obvious
reasons).
> vagrant@jessie:~$ diff -u {a,b}/openocd-0.9.0/tcl/board/sheevaplug.cfg
> --- a/openocd-0.9.0/tcl/board/sheevaplug.cfg 2015-05-17
21:14:10.000000000 +0000
> +++ b/openocd-0.9.0/tcl/board/sheevaplug.cfg 2016-08-10
02:07:55.674787653 +0000
> @@ -1,6 +1,6 @@
> # Marvell SheevaPlug
>
> -source [find interface/ftdi/sheevaplug.cfg]
> +source [find interface/sheevaplug.cfg]
> source [find target/feroceon.cfg]
>
> adapter_khz 2000
Caveat 2: When I don't have a serial connection open (screen /dev/ttyUSB0
115200), everything works great. When I do, OpenOCD periodically chokes.
This may be related to my hardware configuration (Debian Jessie as set up
by Vagrant debian/jessie64 running on VirtualBox on a Mac), but I'm
mentioning it just in case others experience similar behavior.
> Error: ftdi_write_data: usb bulk write failed
> Error: couldn't write MPSSE commands to FT2232
> Polling target feroceon.cpu failed, trying to reexamine
> Info : Embedded ICE version 0
> Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
> For reference, the telltale
On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
andr...@fritiofson.net> wrote:
> On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands <p...@hands.com> wrote:
> > I notice that running openocd causes the /dev/ttyUSB0 device to
disapear,
> > so it's certainly doing something, even if it's not very useful.
>
> OpenOCD detaches the kernel driver on the selected interface (FTDI
channel)
> which might serve a serial port if so configured. Do you really have a tty
> on the same interface/channel as the JTAG circuitry? Channel A *should* be
> unaffected by OpenOCD if "ftdi_channel 1" is selected.
With the legacy driver "/dev/ttyUSB0" is no longer disappearing upon
running OpenOCD. It was disappearing with the FTDI driver.
For reference, here is the output of OpenOCD with the FTDI driver.
> vagrant@jessie:~/a/openocd-0.9.0$ src/openocd -f tcl/board/sheevaplug.cfg
-s tcl
> Open On-Chip Debugger 0.9.0 (2016-08-10-02:21)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> 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
> Info : clock speed 2000 kHz
> Info : TAP feroceon.cpu does not have IDCODE
> Info : TAP auto0.tap does not have IDCODE
> Info : TAP auto1.tap does not have IDCODE
> Info : TAP auto2.tap does not have IDCODE
> Info : TAP auto3.tap does not have IDCODE
Cheers!
Benjamin Rodgers
