I've been trying to use USBprog hardware to do JTAG debugging of a US Robotics USR8200 router. This is an XScale target, specifically the IXP422 processor. I know from other people that openocd works with this target with a different JTAG adapter.
The communications with the board initially works, and the Manufacturer ID is read out correctly, but things go wrong after a reset is issued. The messages visible on the telnet console are: > reset halt JTAG tap: ixp42x.cpu tap/device found: 0x19277013 (Manufacturer: 0x009, Part: 0x9277, Version: 0x1) JTAG Tap/device matched TAP ixp42x.cpu: value captured during scan didn't pass the requested check: captured: 0x7f check_value: 0x01 check_mask: 0x7f in_handler: w/o "in_value", mismatch in SIR JTAG error while writing DCSR BUG: keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (5357) TAP ixp42x.cpu: value captured during scan didn't pass the requested check: captured: 0x07 check_value: 0x02 check_mask: 0x06 in_handler: with "in_value", mismatch in SDR TAP (unknown): value captured during scan didn't pass the requested check: captured: 0x01 check_value: 0x00 check_mask: 0x01 in_handler: w/o "in_value", mismatch in SDR JTAG error while reading TX error while polling TX register, reset CPU target state: halted What seems to be happening, having traced both the USB traffic and the JTAG traces on a logic analyser, is that the reset starts by resetting both SRST and TRST, then reading the ManID, sending command 0x9 (DCSR?), sending 0x2, and getting the right response, sending command 0x7f (Bypass?), again with the right response. Then SRST is asserted on it's own, and xscale_deassert_reset() calls jtag_add_runtest(2030, TAP_IDLE), and then xscale_write_dscr(target, 1, 0). What is seen on the USB trace and logic trace is toggling of TCK, then a TAP transition of 2B is sent, to do IDLE -> IRSHIFT, but then the write of command 0x9 (DCSR?) returns not 1 as expected, but 0x7f. This implies that the TAP is not in the correct state at that point. This must be localised to src/jtag/usbprog.c, as other adapters work. I wonder if the fact that 2030 transitions of TCK end with the TCK low, interacts badly with the way the "write tms chain" instruction works on the USBprog? It takes TCK low then high, to do each transition, but if TCK is already low at the end of the runtest, one of the transitions would be lost, and the 2B would instead end up as 15, and we'd end up in DRSHIFT, not IRSHIFT. This would be consistent with the read out of 0x7F. Thoughts? What state should TCK be in "normally" - between operations? I'm a little reticent about just putting in a change and trying it without some feedback, in case I damage my target. My proposed change would be raising TCK at the end of usbprog_runtest(), so the next L-H transition of TCK inside the tms-chain function in the firmware has the desired effect. -- Peter Denison _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
