Hi Oliver and OpenOCD developers,
thanks for testing the patch. The patch was related to the FTDI
application note: "AN 108 Command Processor for MPSSE and MCU Host Bus
Emulation Modes", which also includes the older FT2232D chip. So I would
not expect bad things happen, if that inserted flush commands is send to
the old FT2232D chip. But unfortunately I haven't a JTAG dongle with
that old chip, which prevents me for checking it using a LeCroy USB tracer.
More interesting than seen my patch included in OpenOCD is the fact that
the new ftdi driver also uses that flush command to decrease the USB
latency time or slow down the overall JTAG memory read performance as
you have detected with the FT2232D chip here. The intention of the flush
command is just to stop the hardware built-in latency timeout timer and
starting a short package transfer immediately.
Without that flush command a next USB read transfer needs some time
longer. But a faster USB read transfer is something different than an
OpenOCD memory read or write command.
Before we understand your findings here my remarks: You tested with
STM32, which is ARM based. I used an AR7161 MIPS32 controller. MIPS do
memory read and write in some kind of JTAG remote controlled CPU
instructions in PRAC mode. I guess that is different compared to ARM and
slows down memory read from OpenOCD anyway. At least the MIPS-EJTAG
needs some kind of polling a JTAG status register for every JTAG
controlled CPU instruction.
My patch decrease the USB read latency. But in detail it has only an
effect, if the next JTAG commands often arrive faster and the polling of
the status register detects a CPU not yet ready situation, before the
USB-latency timer anyway would elapse.
Additionally USB allows transfers only in a discrete timing raster of
125 uSec or possibly 1ms, because USB host controllers mostly start the
next USB transfer only at the beginning of the next USB-Microframe
and/or depending on the host controller implementation using Full Speed
this timing raster may be increased to 1 ms. At the final end the JTAG
instruction speed, which depends on the JTAG clock rate, interferes with
that USB timing raster and could become worse using USB 1.1
I would expect that this is the case using the old FT2232D chip running
with USB1.1. Without an USB analyzer in place, we need some more input
from your measurement:
1. Which OS and PC did you use?
2. Which JTAG clock rate did you use and did you try with different rates?
3. Which absolute memory read (write) transfer speeds did you measure?
4. Was the read out data always correct?
Here are my measurements:
1. I used an Core-2 Notebook and did the measurement running Debian
Lenny i386 and Debian Squeeze AMD64.
2. The AR7161 JTAG speed was 10MHz in case of the USB FT2232H based
dongle and 0.5MHz in case of the Parport Wiggler dongle. Higher clock
rates result sometimes in incorrect CPU behaviour.
3. I guess you see with your ARM system much higher throughput. However
I measured only read performance, because write was dramatically faster
on the MIPS system:
- 0.1 KiB/s with the original ft2232 driver and Olimex ARM-USB-OCD-H
- 0.5 KiB/s with the flush patch included in the ft2232 driver
- 0.5 KiB/s with a parport driver
- 5.0 KiB/s with a ftdi driver including all newest MIPS performance
patches using the Olimex ARM-USB-OCD-H
4. Sometimes I measured a higher read performance, but the read data
were incorrect. The above reads are naturally related to correct data read.
How to proceed? If you are convinced that the inserted flush command
make some bad things using the FT2232D adapter, please do some
measurements using the new FTDI driver too, once a time the original
code and once with that patch included:
Omit the FTDI flush command just for test purposes, because with FT2232D
the read throughput may be decreased. But note that this patch is still
untested.
--- a/src/jtag/drivers/mpsse.c
+++ b/src/jtag/drivers/mpsse.c
@@ -777,7 +777,7 @@
struct libusb_transfer *read_transfer = 0;
struct transfer_result read_result = { .ctx = ctx, .done = true };
if (ctx->read_count) {
- buffer_write_byte(ctx, 0x87); /* SEND_IMMEDIATE */
+// buffer_write_byte(ctx, 0x87); /* SEND_IMMEDIATE */
read_result.done = false;
read_transfer = libusb_alloc_transfer(0);
libusb_fill_bulk_transfer(read_transfer, ctx->usb_dev,
ctx->in_ep,
ctx->read_chunk,
Another way might be checking how often polling a JTAG status register
miss with/without the flush (patched) included, expecting that an ARM
system requires as well polling a status register in read mode. That
could give us a hint, if the decreased read performance is related to an
interference problem of the polling cycle time with the JTAG instruction
cycles. But when you measure higher read throughput using a different or
slower JTAG clock rates may give us also an indication here.
Thanks and Kind Regards,
Peter
Am 31.01.2013 13:43, schrieb Spencer Oliver (Code Review):
> Spencer Oliver has posted comments on this change.
>
> Change subject: ft2232 flush before read
> ......................................................................
>
>
> Patch Set 1: I would prefer that you didn't submit this
>
> (1 inline comment)
>
> I have done some basic testing using a FT2232 and a FT2232H on a stm32 board.
>
> A increase of about 4KiB/s was seen during a read test using the H adapter,
> however the older chip (non H) seemed to be slightly slower 3KiB/s. Did not
> see any change in write speed.
>
> Perhaps we need to check the type and use flush only for the newer H parts?
>
> The other issue is do we update this driver and add potential regressions
> when it is as such deprecated. Maybe needs discussing on the ml.
>
> ....................................................
> File src/jtag/drivers/ft2232.c
> Line 810: LOG_DEBUG("Send Immediate buffer to PC");
> can you remove any debug messages as they can make it a bit to noisy.
> if they are needed then use a _DEBUG_USB_IO_ block
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
