The current code for the USBprog adapter fails right after init when trying to do the DRSCAN for IDCODEs with:
Info : 284 201 core.c:948 jtag_examine_chain_display(): JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) Warn : 285 201 core.c:986 jtag_examine_chain_end(): Unexpected idcode after end of chain: 480 0x800000ff Warn : 286 201 core.c:986 jtag_examine_chain_end(): Unexpected idcode after end of chain: 512 0x0000007f Error: 287 201 core.c:1151 jtag_examine_chain(): double-check your JTAG setup (interface, speed, missing TAPs, ...) 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'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. Probably none of this (even a) will get done for 0.3.0, but if anyone has any thoughts, I'd be interested. -- Peter OpenOCD v0.2.0-452-gce88e8a _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
