Hi, I've recently had the opportunity to get my hands on a genuine Altera USB Blaster revision C. Because my board needs "usb_blaster_pin pin6 s", I noticed an issue with the initialization of the USB Blaster.
Initialzation is currently implemented as follows: - Configure FT245 for FIFO mode - Send 4096 0x00 bytes - Reset JTAG state machine by sending 12 bytes that clock out 5 TMS=1 When the CPLD is in bit banging mode (as is usually the case), the first 0x00 byte sets all pins to low and disables the output driver. Disabling the output drivers is a few nanoseconds slower than changing a pin from high to low, so I see a spike towards GND on my reset line when that byte is sent over USB. The spike is too short to have an effect on the board. When the 4096 0x00 bytes are processed and the TMS=1 is to be generated, all I see is several microseconds of low level on all pins, resetting my board. This is due to the level shifter circuit of the USB Blaster: USB Blaster rev C is FT245 <-> CPLD <-> 2x MAX3378 <-> 74LVC244A <-> resistors <-> JTAG Turning off the LED also tri-states the two MAX3378 and the 74LVC244A. In the MAX3378 data sheet there is an "EXITING THREE-STATE OUTPUT MODE" diagram that wants to tell us that it takes about 4 micoseconds to turn the drivers back on. The 74LVC244A is much faster and forwards its inputs after about 25 nanoseconds. So until the MAX3378 have recovered, the 74LVC244A inputs are floating. Usually there is still some charge on the gates of the 74LVC244A inputs, left from before we turned off the MAX3378. So the byte turning off the LED determines what we see on the JTAG pins for 4 microseconds when we turn the LED back on. The question is: Is there any reason why we send 0x00 instead of 0x0E? Why do we turn off the drivers at all? If I understand it correctly, the 4096 bytes are sent to exit from byte-shift mode in case the last session left the device in that state. But then the command to disable the drivers is not recognized until we haved exited byte-shift mode. We might as well send alternating 0x2e/0x2f to reset the state machine as soon as we are back into bit banging mode. If we knew how to access TRST at that point, we could avoid filling DR/IR with junk. Maybe we can defer initialization? The pre-April 14 code didn't send those 4096 bytes. It generated setup USB packets that told the FT245 to discard all data in its FIFOs. Why has that part of the initialization been removed? Best regards, Daniel ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
