so for me I cannot see any trouble on the use of the send immediat 87 command regarding and the full-speed and high-speed device. We have used it a lot as with our Amontec JTAGkey SVF Player or vector player.... We never see any bad effect using this command.
Also, regarding the mips32, I do not understand why you expect the send immediat command to be the trouble. For me it should come from the upper layer. But in an other way, the patch touch the buffer by using buffer_write inside in the send_and_recv function. This could generate issue if the buffer was full before the send_and_receiv. So the actual patch is really not so good. Maybe this is why you have sometimes some issues. Regards, Laurent http://www.amontec.com ;-) > > Am 01.02.2013 17:51, schrieb Laurent Gauch: >> Hi Peter, >> >> Where is this patch sourced ? >> >> Regards, >> Laurent >> >> I can test with AMONTEC JTAGKEY ft2232D based and AMONTEC JTAGKEY-2 >> ft2232H based . >> http://www.amontec.com >> >> >> >> Le 01.02.2013 16:34, Peter Henn a écrit : >>> 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
