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
From da66e20211aadd34784c3a36de3b1f1f1aba4e5b Mon Sep 17 00:00:00 2001
From: Dimitar Dimitrov <dinu...@gmail.com>
Date: Fri, 30 Oct 2009 20:54:07 +0200
Subject: [PATCH] Increase FT2232 read retry counts
This change is necessary to debug AT91SAM9260 on my PC with a
FT2232H dongle.
Signed-off-by: Dimitar Dimitrov <dinu...@gmail.com>
---
src/jtag/ft2232.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/jtag/ft2232.c b/src/jtag/ft2232.c
index cf3fc01..fac321f 100644
--- a/src/jtag/ft2232.c
+++ b/src/jtag/ft2232.c
@@ -71,6 +71,13 @@
/* this speed value tells that RTCK is requested */
#define RTCK_SPEED -1
+/*
+ * On my Athlon XP 1900+ EHCI host with FT2232H JTAG dongle I get read timeout
+ * errors with a retry count of 100. Increasing it solves the problem for me.
+ * - Dimitar
+ */
+#define FT2232_READ_RETRY_COUNT 2000
+
#ifndef BUILD_FT2232_HIGHSPEED
#if BUILD_FT2232_FTD2XX == 1
enum { FT_DEVICE_2232H = 6, FT_DEVICE_4232H };
@@ -400,7 +407,7 @@ static int ft2232_read(uint8_t* buf, uint32_t size, uint32_t* bytes_read)
#elif BUILD_FT2232_LIBFTDI == 1
int retval;
- int timeout = 100;
+ int timeout = FT2232_READ_RETRY_COUNT;
*bytes_read = 0;
while ((*bytes_read < size) && timeout--)
@@ -679,7 +686,7 @@ static int ft2232_send_and_recv(jtag_command_t* first, jtag_command_t* last)
if (ft2232_expect_read)
{
- int timeout = 100;
+ int timeout = FT2232_READ_RETRY_COUNT;
ft2232_buffer_size = 0;
#ifdef _DEBUG_USB_IO_
@@ -711,14 +718,14 @@ static int ft2232_send_and_recv(jtag_command_t* first, jtag_command_t* last)
{
LOG_ERROR("ft2232_expect_read (%i) != ft2232_buffer_size (%i) (%i retries)", ft2232_expect_read,
ft2232_buffer_size,
- 100 - timeout);
+ FT2232_READ_RETRY_COUNT - timeout);
ft2232_debug_dump_buffer();
exit(-1);
}
#ifdef _DEBUG_USB_COMMS_
- LOG_DEBUG("read buffer (%i retries): %i bytes", 100 - timeout, ft2232_buffer_size);
+ LOG_DEBUG("read buffer (%i retries): %i bytes", FT2232_READ_RETRY_COUNT - timeout, ft2232_buffer_size);
ft2232_debug_dump_buffer();
#endif
}
--
1.5.6.5
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
