Uh, upon reading the USB Blaster protocol docs more closely (sorry for not catching this earlier), allowing the user to set pin 6 (nCS) interferes with the smarter byte-oriented mode of the protocol. From UrJTAG mediawiki: "Load shift register with byte from host Do 8 times (i.e. for each bit of the byte; implemented in shift.a51) if nCS=1, set carry bit from TDO, else set carry bit from DATAOUT (Active Serial mode) Rotate shift register through carry bit"
The current implementation of the driver is unaffected because it uses bitbang mode. However, pin 6 will become unavailable for xRST once the driver is modified to use the smarter mode. I will add a comment to this effect in the code. Should I add something in openocd.texi as well? On Tue, Dec 22, 2009 at 12:11 AM, Catalin Patulea <[email protected]> wrote: > All right, we've got: > > - usb_blaster command that can toggle the GPIO pins > - documentation for said command > - usage example for hooking it up as SRST (can you sanity-check the > example? I added a wait, then set it back to 0, but perhaps that's not > the best approach) > > > On Mon, Dec 21, 2009 at 3:38 AM, David Brownell <[email protected]> wrote: >> On Monday 21 December 2009, Ųyvind Harboe wrote: >>> You can't debug XScale without for one. Perhaps, eventually, you can >>> limp along without it, but I would *definitely* prefer a dongle that >>> supported >>> srst and trst. >> >> So with thise one, you'd rig some kind of adapter and then >> use a customized [looks it up] jtag_init method that >> understands how to trigger those two signals. >> >> I know that I was completely unable to get a PXA255 to even >> start up with OpenOCD without a custom jtag_init... >> >> >> Remember most TI chips use JTAG adapters that don't include >> SRST at all. I'm sure it's a complete coincidence that the >> first few generations of Stellaris chips ended up needing >> to write chip registers to reset the chips, instead of SRST; >> there's no way that was a factor in TI buying Luminary. ;) >> >> - Dave >> >> > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
