If it fails for you with OHCI, I'd expect you have a fairly clean failure mode and that using a fullspeed hub won't change anything.
Now, one thing that's interesting is that you seem to have gotten a *different* failure mode at full speed. Suggesting there are two different bugs associated with (this?) FT223H support ... On Wednesday 28 October 2009, Dimitar Dimitrov wrote: > Open On-Chip Debugger 0.3.0-dev-00457-g512ae75 (2009-10-28-20:51) Your repository has at least five commits that aren't in mainline ... they might cause trouble. > $URL$ > For bug reports, read > http://openocd.berlios.de/doc/doxygen/bugs.html > User : 5 0 command.c:400 command_print(): debug_level: 3 > Debug: 6 0 configuration.c:83 find_file(): > found ../openocd/tcl/interface/olimex-arm-usb-tiny-h.cfg Aha! A new adapter! Want! http://www.olimex.com/dev/arm-usb-tiny-h.html Not available until November; sigh. :( Let me guess ... those extra commits are ft2232 driver updates to suport this! If so, let's take a few steps backwards to see where the problem came in: - Adaptive clocking ... it might be problematic. Force "jtag_khz 8" so it behaves with the 32K clock. - Does this work OK with the D2XX drivers? If so, that would suggest the issue is specific to libftdi, or its use in this context. (Related: does D2XX on Windows behave for you?) - If this is really wired like a usb-tiny, except of course for the adaptive clocking, try telling OpenOCD that it's a Tiny not a Tiny-H. If you see differences at full speed there's something pretty odd going on... What I'd expect to see is everything working fine. (Idealy, at both speeds.) - You can try using an older libftdi version. If there seem to be libftdi 0.16 issues, maybe they're coupled to the FT2232H changes in that version.. Related, I came across some interesting libftdi patches on their mailing list, and there are a few in their repository already that will appear in the 0.17 code. > Info : 75 53 core.c:1367 jtag_interface_init(): RCLK (adaptive clock speed) Do these problems show up if you don't use adaptive clocking? I've noticed that clocking bugs often show up with bitshift type symptoms, which you have aplenty (see below). Now as to the specific failure you saw -- and thanks for the detailed debug log! -- the key stuff seems to be: > Info : 146 569 core.c:948 jtag_examine_chain_display(): > JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, > part: 0x7926, ver: 0x0) Success!! oops, maybe not so fast ... > Warn : 147 569 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 480 0x603100ff > Warn : 148 569 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 512 0x00ff0000 > Warn : 149 569 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 544 0x00ff0000 > Warn : 150 569 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 576 0x00ff0000 > Warn : 151 569 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 608 0x00ff0000 All those should be 0x000000ff ... looks like an 0x6031 got inserted at the end of a USB packet, which threw off the rest of that scan by 16 bits. Then it retried later and things got even worse: > Warn : 245 1093 core.c:948 jtag_examine_chain_display(): > JTAG tap: at91sam9260.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, > part: 0x0000, ver: 0x0) > Error: 246 1093 core.c:948 jtag_examine_chain_display(): > JTAG tap: at91sam9260.cpu expected 1 of 1: 0x0792603f (mfg: 0x01f, > part: 0x7926, ver: 0x0) > Warn : 247 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 1 0x301f8000 > Warn : 248 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 33 0x007f83c9 > Warn : 249 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 65 0x007f8000 > Warn : 250 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 97 0x007f8000 Looks like maybe sixteen zero bits got inserted at the *beginning* of a packet, which threw everything off ... the 0x007f8000 being the expected value of 0x000000ff shifted right by one bit, 301f8 being 603f0 shifted right by one bit, etc. (The first zero byte got consumed, it's what a BYPASS instruction emits. Then there were no more taps listed, so all the other values are shifted by 15 bits.) > Warn : 251 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 129 0x007f8000 > Warn : 252 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 161 0x007f8000 > Warn : 253 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 193 0x007f8000 > Warn : 254 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 225 0x007f8000 > Warn : 255 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 257 0x007f8000 > Warn : 256 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 289 0x007f8000 > Warn : 257 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 321 0x007f8000 > Warn : 258 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 353 0x007f8000 > Warn : 259 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 385 0x007f8000 > Warn : 260 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 417 0x007f8000 > Warn : 261 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 449 0x007f8000 > Warn : 262 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 481 0x807f8000 > Warn : 263 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 513 0x80003018 And another hiccup here: more data stuffed into the bitstream. > Warn : 264 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 545 0x8000007f > Warn : 265 1093 core.c:986 jtag_examine_chain_end(): Unexpected idcode after > end of chain: 577 0x8000007f Notice 0x8000007f is the expected 0x000000ff bitshifted by one bit again... _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
