[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openocd-development
Subject:    [Openocd-development] USB bulk write failures when using
From:       dinuxbg () gmail ! com (Dimitar Dimitrov)
Date:       2009-10-30 19:23:50
Message-ID: 200910302123.51722.dinuxbg () gmail ! com
[Download RAW message or body]

On Friday 30 October 2009, David Brownell wrote:
> On Thursday 29 October 2009, Dimitar Dimitrov wrote:
> > I fixed the issue by disabling dcc memory uploads.
> 
> Bizarre.  Disabling those let the initial enumeration
> work at full speed??  Or was that caused by some other
> patches in your repository?
> 
Working configuration is high-speed USB. I have only two patches in my repository and \
they were attached to my previous message. One is trivial interface configs. The \
other one increases (at least I think so) the FT2232 retry counts. Without it I get \
errors when I "reset init".

> Is this still with adaptive clocking enabled?
Yes, working configuration uses RTCK.

> Where did those strange 16-bit values come from,
> which were breaking the JTAG scans?
They appeared in full speed USB mode. While reading the libftdi manual I stumbled on \
a note about two modem status bytes: \
http://www.intra2net.com/en/developer/libftdi/documentation/group__libftdi.html#g72d87e30015c98bd0be22e7c8c873345
 Browsing libftdi-0.16/src/ftdi.c:1232 I saw
    if (ftdi->type == TYPE_2232H || ftdi->type == TYPE_4232H)
        packet_size = 512;
    else
        packet_size = 64;

I'm not acquainted with libftdi but if it assumes that FT2232H as packet size 512 \
then it is wrong. In full speed USB it must have packet size 64. Which leads me to \
the question, has anyone successfully run FT2232H in full-speed USB mode?

> 
> 
> > Otherwise my setup hasn't changed: 
> > 
> > 1. Openocd fetched from latest GIT
> > 2. libftdi-0.16 from the latest release tarball
> 
> Good...
> 
> 
> > 3. FT2232 timeout/retry-count patch applied (attached).
> 
> Still trying to understand details here.  This
> was not needed at full speed, just high speed?
High speed needs these patches to pass "reset init". Full speed mode can't even \
validate the JTAG chain.

> 
> Looks like this should be safe to apply, but I
> need to see a decent patch description.  And if
> the so-called "timeout" isn't really a timeout,
> it'd be good to at least see that issue commented
> in the code ... if not eventually fixed, switching
> it to a real timeout scheme.
> 
I intended this patch to be more like a suggestion then a commit-ready one :) I'm \
attaching another version of my patch but please bear in mind that I'm not fully \
aware how exactly libftdi works.

> 
> > 4. ARM-USB-TINY-H interface config (attached)
> 
> I'll merge that interface config patch; but I
> fixed the URL in that file.  Didn't fix the one
> for the highspeed non-tiny product, which you're
> not quite pre-announcing here.  :)
> 
Thanks.

> 
> > After starting openocd I issue the following commands (see attached log):
> > 1. reset init
> > 2. arm7_9 dcc_downloads disable
> > 3. load_image dd 0x20000000        #THIS WORKS
> > 4. arm7_9 dcc_downloads enable
> > 5. load_image dd 0x20000000        #THIS FAILS.
> > 
> > After that the FT2232H is not usable until it is power cycled.
> 
> Hmm.  I see two problems:
> 
> - Not usable till power cycled ... can you establish
> whether this is a hardware bug of some kind?  In Linux
> you should be able to force a medium-weight reset of
> the device by writing the bConfiguration sysfs value
> for that device to zero (then back to what it was).
Setting bConfiguration to 0 and then back to 1 helps. OpenOCD starts correctly \
without the need for FT2232H power cycle.

> Being able to trigger that failure seems clearly to
> be some kind of bug on our side.  Not being able to
> recover from it could be our bug; but maybe not.
> 
> - The DCC download feature thing.  The issue shouldn't
> be the DCC per se ... but the "fast" optimization
> that disables handshaking.  If you're running the
> JTAG clock six times faster, and the code inside
> the ARM isn't running out of icache or TCM, then you
> might not be able to avoid the handshaking...
> 
> Can you sort out that DCC thing a bit better, to verify
> that it works OK with handshaking enabled?
I issued "arm7_9 fast_memory_access disable" with DCC downloads enabled but I still \
get "usb bulk write failed". I'm using RTCK. Maybe I'm hitting the following issue: \
https://lists.berlios.de/pipermail/openocd-development/2009-October/011825.html

> 
> - Dave
> 

Dimitar


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Increase-FT2232-read-retry-counts.patch
Type: text/x-diff
Size: 2136 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/openocd-development/attachments/20091030/590ac226/attachment.patch>



[prev in list] [next in list] [prev in thread] [next in thread]