On Tuesday 03 November 2009, Peter Denison wrote: > Unfortunately this is down to how the firmware in the adapter is written. > Comms is limited to 64 byte USB packets, and the WRITE_READ command can > therefore take a maximum of 488 bits (61 bytes after 3 header bytes). The > 640 bit IDCODE scan is split up into 2 transactions, of which the first > completes successfully. There is special-case code for 488-bit commands to > hold TMS low on the last bit, so the TAP stays in DRSHIFT. Normally, TMS > goes high for the last bit, to bring the TAP out to DREXIT1. > > Sadly though, the main loop of the adapter firmware adds a TMS=0, TDI=0 > clock at the end of every WRITE_READ command. Under normal (entire command > fits in 1 transaction) circumstances, this is to make the TAP transition > from DREXIT1 to DRPAUSE. With split transactions, this extra clock loses a > bit, and the returned data then makes no sense, leading to the "Unexpected > idcode" messages above.
I guess I don't understand why TMS should ever *implicitly* be changed, or clocks *implicitly* be added. This won't be the only problem that causes ... > I'm working on a solution, but have several options. > > a) Add yet more special case "if (bits == 488)" code in the adapter > firmware main loop. This is horrible, but a quick fix. Would still go > wrong if exactly 488 bits were required. > > b) Drop the extra clock from the adapter firmware, and add it in to the > OpenOCD driver code. Good solution, but requires coordination of releases > of both the adapter firmware and OpenOCD. > > c) Drop the existing limited adapter firmware in favour of a more capable > protocol, not limited to 64 byte transfers, and understanding complete "do > this entire scan" or "do this entire TMS sequence" commands. Even better, > but quite some considerable work. Or just trim some of the side effects. That would necessarily call for changes in client firmware -- you could minimally just update the device's bcdVersion code! But the tweaks shouldn't need to be huge. "Send this data" would ignore TMS and just clock data in/out. "Walk this TMS path" would hold TDI fixed and just clock TMS... individual packets could still be 64 byts if you like. Given the bug is a side effect of the protocol, I don't see a way around some level of "flag day". There are ways to cut the main involved in such stuff though. Or if you want a "no flagdays approach", then maybe OpenOCD could be taught that it's got to transition from SHIFT to PAUSE every adapter-specific-N bits. That'd let you break scans up into smaller chunks ... that's more or less just why the PAUSE state exists. > Probably none of this (even a) will get done for 0.3.0, but if anyone has > any thoughts, I'd be interested. There are also two other usbprog issues noted in the TODO list... at least one of which seems kind of related (the "long" sequences). - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
