Daniel Glöckner <[email protected]> writes: > 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 Yep.
...zip... A very good description, very precise. That maybe would deserve to be included somewhere as a documentation reference for true Altera USB Blaster. > The question is: Is there any reason why we send 0x00 instead of 0x0E? No. I hadn't thought of a proper value yet. > 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. The idea of "turn off" was to not perturbate the state of the board. Either we were in byte-shift mode, and it doesn't matter (partly, for the remaining bytes) what is sent. Or we're in bitbang mode, and tristating the output shouldn't imply any action on the board. I was thinking that in this "0x00" sequence, the first byte taken in bitbang mode would tristate the outputs. That might be an error though, and we might decide there is a better approach. > 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. We might send something else that 0x00. Rather than 0x2e/0x2f, I would send something like (computed PIN6 | computed PIN8 | TMS=1 | TCK=x), alternating x between 0 and 1. > Maybe we can defer initialization? I don't understand that part, would you enlighten me ? > 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? Ah, that's because the cheap clone based on Cypress chips doesn't honor the setup packet to empty the FIFOs. I had decided to use something that would work for both the true Altera USB-Blaster and for the cheap clones. Now, we can differentiate in the configuration file between clones and true Altera chips, and choose the specific Altera command to empty the FIFOs. Or find a way with the 4096 write to do it for both the clones and the originals. I'd rather have something common for both of them, but if you convince me that this regression is unbearable, we'll patch to have the original behavior back. And it's good to have at least a tester with an original Altera device :) Cheers. -- Robert ------------------------------------------------------------------------------ "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
