On Fri, May 18, 2012 at 4:59 PM, Bill Traynor <[email protected]> wrote: > > When I comment out the nSRST line in the flyswatter2.cfg, I no longer > receive the tri-sate error but continue to see the looping through of: > > Debug: 402 86 command.c:145 script_debug(): command - runtest ocd_runtest > 200 > Debug: 404 86 mpsse.c:760 mpsse_flush(): write 199+1, read 81 > Debug: 405 86 mpsse.c:743 write_cb(): transferred 200 of 200 > Debug: 406 324 mpsse.c:729 read_cb(): raw chunk 2, transferred 0 of 81 > Debug: 407 579 mpsse.c:729 read_cb(): raw chunk 2, transferred 0 of 81 > Debug: 409 834 mpsse.c:729 read_cb(): raw chunk 2, transferred 0 of 81 > Debug: 410 1089 mpsse.c:729 read_cb(): raw chunk 2, transferred 0 of 81 > etc. etc.
So the driver sent a stream of MPSSE commands, 199 bytes long, of which some were read commands, expecting a total of 81 bytes in return. Every 255 ms (the latency timeout) the FT2232 sends an empty transfer (2 status bytes only, no payload). I imagine the only thing that can cause the read data to remain unavailable for a longer period of time is if you use RTCK and that signal is missing somehow. Can you try to use a fixed, low adapter_khz setting instead of RTCK? /Andreas ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
