2012/11/26 Andreas Fritiofson <[email protected]>: > > On Sun, Nov 25, 2012 at 10:44 PM, Franck Jullien <[email protected]> > wrote: >> >> >> My waveform wasn't complete, the TAP doesn't hang while "polling DR >> SHIFT", it's just longer... > > > Yes, you're seeing the effect of USB latency and this will totally kill > performance of your polling scheme. Every jtag_execute will take > milliseconds for a full speed USB connection. > > How long on average is the wait time before status bit sets? Looking at your > waveforms it seems to be set the very first clock cycle so I assume the wait > will generally be on the order of a few TCK cycles at most? >
Yes exactly. > A better solution once this bug (or whatever it is) has been fixed, may be > to speculatively scan the full read plus some amount of extra bits, instead > of just scanning one bit until it's set and then the full read. Then in most > cases you'll have all data on the host in one go and can perform the search > for the first set bit there, in order to locate and shift the data. If you > didn't read enough bits, you'll have to read the remaining with a separate > scan. You can also adjust the amount of extra bits based on previous scans, > so the method can optimize itself online. > Yes, good idea. Moreover, that could fix my problem as well.... >> >> However, my problem is coming from this TMS set to '1' after the >> jtag_add_dr_scan of >> 1 bit with an end state set to DRSHIFT (plus this clock pulse in the >> middle of the waveform) : >> >> http://picpaste.com/pics/jtag_2-sZk1MbUP.1353879598.png >> >> Still searching.... > > > Weird... I don't see where that extra clock is coming from. > > However, I suspect I may be sending invalid opcodes to the FTDI chip and > that may be what is toggling TMS. Perhaps the MPSSE commands are not as > orthogonal as it seems from ยง3.2 in "AN2232C-01 Command Processor for MPSSE > and MCU Host Bus Emulation Modes" rev 2.2. The chip may not like that the > clock edge specifier for write data is set when the command is read only. > > I don't have the logic analyzer available until tomorrow or something so I > haven't tested this myself, but you can try the following patch and let me > know the result. > > diff --git a/src/jtag/drivers/mpsse.c b/src/jtag/drivers/mpsse.c > index d6cbc84..9d2454e 100644 > --- a/src/jtag/drivers/mpsse.c > +++ b/src/jtag/drivers/mpsse.c > @@ -438,8 +438,12 @@ int mpsse_clock_data(struct mpsse_ctx *ctx, const > uint8_t *out, unsigned out_off > /* TODO: On H chips, use command 0x8E/0x8F if in and out are both 0 > */ > if (out || (!out && !in)) > mode |= 0x10; > + else > + mode &= ~0x01; > if (in) > mode |= 0x20; > + else > + mode &= ~0x04; > > while (length > 0) { > /* Guarantee buffer space enough for a minimum size transfer > */ > @@ -512,6 +516,8 @@ int mpsse_clock_tms_cs(struct mpsse_ctx *ctx, const > uint8_t *out, unsigned out_o > mode |= 0x42; > if (in) > mode |= 0x20; > + else > + mode &= ~0x04; > > while (length > 0) { > /* Guarantee buffer space enough for a minimum size transfer > */ > No, I doesn't fix the problem. Thanks for your help. Franck. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
