That first link was where I read about it, I couldn’t find it in my bookmarks I didn’t mean to give the impression I had worked this out by myself… its all down to some very clever people and their hard work.
I guess the UrJtag code would also be a good start, still haven’t got my blaster behaving with that, (works fine with Quartus II) but I don’t think there is anything wrong with UrJtags code, its far more likely that my blaster clone has a slow voltage buffer, and that Quartus uses delays between enabling the output and communication.
Btw, I tried my blaster with openOCD earlier. I got a TCK of 500Hz. Seemed to communicate well though, with no errors in reading IDcodes. I’m sure together we can get this ironed out and running smooth
I just posted a patch to the mailing list, which fixes the speed issue (at least for bit-bang mode, byte shift mode is still broken). I successfully used the blaster to communicate with an LPC1758 (Cortex-M3) target. “Halt” no longer takes 15 seconds to execute :), also GDB seemed to be able to use the blaster through OpenOCD to control the target.
I read your explaination, and it makes perfect sense to me I really had no clue as to why it was so slow… I shall test it asap with my DIY blaster clone.
I skimmed over the original code, and although I’m essentially a beginner in C, I couldn’t see any code that implemented byte shift mode - but I did only check the ‘blaster.c’ file.
When I wrote my VB.NET code to use byte shift mode a year ago, it was tightly coupled with an SVF file parser - not a modular snippet of code, so I am completely in the dark about just ‘how’ to create a patch to attempt to get byte-shift working. That is, it read an SVF file line, calculated the maximum number of bytes to be sent, sent those in byte shift mode, and sent the rest of the bits as bit-bang. Interestingly, the same technique one uses to send odd numbers of bits using a microcontroller’s SPI port, at high speed.
I have ordered an FPGA board, which comes with a clone USB blaster, the manufacturer claims it has been fully tested to be compliant with QuartusII, at full speed. So that gives me a ‘better’ bit of hardware to tinker with.
Apologies for leaving this thread hanging, work kicked off, and as always, customers want things far too quickly Feedback for the patch is on its way!
I skimmed over the original code, and although I’m essentially a beginner in C, I couldn’t see any code that implemented byte shift mode - but I did only check the ‘blaster.c’ file.
Well, the functionality is not yet in the OpenOCD codebase, you have to clone the GIT repository of OpenOCD and then apply the patch (for 'usb_blaster.c') provided in my post to the mailing list.
I didn’t mean to give the impression I had worked this out by myself… its all down to some very clever people and their hard work.
Feedback for the patch is on its way!