Knock-off USB Blaster in Linux issues? - Page 1
Forum section: electronics / general

author: Artlav
author_rank: Frequent Contributor
timestamp: March 09, 2016, 07:50:05 pm
content: Several years ago i got an Altera "USB Blaster" programmer, which turned out to be not-genuine.It worked great since then, on commercial, home-made and China-produced FPGA boards.But there is a catch - it only does so under Windows.I've recently moved my dev environment to Linux, and while Quartus and the rest works nicely, the programmer - not so much.I tried every version of Quartus from 12 up, and in every one of them the programmer works intermittently in Active serial mode - it would erase the flash, but then fail at a random spot during the programming with a "Can't access JTAG chain" error.The only difference between 12.0 and 15.1 is that in 12.0 it takes less than a second to restart, so i can spam it a few times to get it to work, while in 15.1 it takes 10-20 seconds to start and fail.So, the question is - have anyone encountered any such problems, either with knock-off Altera programmers, with Linux, or with both at once?Bonus question: As knock-offs go, how bad is this one?

author: Rasz
author_rank: Super Contributor
timestamp: March 10, 2016, 12:59:57 am
content: real thing had EPM7064 afair, no big difference if its programmed to do the same (fancy shift register)start lower down the stack, is it visible in dmesg as a plugged usb device? correct vid/pid? next try something simple like openocdquick google gives me this as an example code that can talk to usb blaster using userspace usb libraryhttps://github.com/swetland/jtagedit: doh, im such a dorkread first half and assumed it didnt work at all

author: AndyC_772
author_rank: Super Contributor
timestamp: March 10, 2016, 07:31:35 am
content: I have it on good authority that there are compatibility issues between some USB Blaster clones and newer CPLDs. If you hadn't mentioned Active Serial mode, I might have suggested it was a compatibility issue with the target device.What target are you programming? Is it an EPCS4?

author: Artlav
author_rank: Frequent Contributor
timestamp: March 10, 2016, 10:49:12 am
content: Quote from: AndyC_772 on March 10, 2016, 07:31:35 amEPCS4, with a Cyclone IV FPGA connected to it.Funny thing is, i fired up Windows in VirtualBox with the USB port patched thru to it, and it worked just fine.So whatever it is, it's related to Linux drivers or programmer.

author: Artlav
author_rank: Frequent Contributor
timestamp: March 10, 2016, 03:02:34 pm
content: One more thing i noticed - the USB wire length seem to matter as well.If it's plugged straight into the port, it works every time.If plugged with a short extension cord, it acts up occasionally.If plugged with a 2 meter cord, it acts up every time.Oddly enough, on Windows it works every time regardless of cord length.Which makes me wonder - is there some sort of a speed setting somewhere, perhaps?Or maybe the Windows drivers can handle occasional transfer error?Weird.

author: MickM
author_rank: Regular Contributor
timestamp: March 10, 2016, 11:36:24 pm
content: Hi;It seems that you have solved the problem.Use good quality short shielded USB cablesMick M.

author: Artlav
author_rank: Frequent Contributor
timestamp: March 11, 2016, 04:02:05 pm
content: Quote from: MickM on March 10, 2016, 11:36:24 pmI don't think so.It's an uncomfortable hack, not a full solution.Pretty much any USB extension cable makes the thing act up, so the quailty of the cables does not seem to matter much.And in the end it works fine on Windows, so whatever it is is software, i guess.

author: diyaudio
author_rank: Frequent Contributor
timestamp: March 11, 2016, 06:33:44 pm
content: Quote from: Artlav on March 09, 2016, 07:50:05 pmI've had the same dam issue on windows

author: FivePoint03
author_rank: Regular Contributor
timestamp: March 11, 2016, 06:47:01 pm
content: Quote from: MickM on March 10, 2016, 11:36:24 pmQuote from: Artlav on March 11, 2016, 04:02:05 pmAren't USB extension cables explicitly non-compliant with USB? Some devices are very fussy on cables, it's easy to understand why.The cable might not be the root cause but if it's making things worse I'd be getting good quality cables for sure.

author: MickM
author_rank: Regular Contributor
timestamp: March 11, 2016, 07:01:59 pm
content: Hi;USB-2 speeds definitely need good cables.Are you sure that Windows is running as fast?Long cables may talk to a scanner or printer, but not a hard drive.I have found that Linux will try to push hardware to as much speed as possible.This will expose flaky hardware and connections, as you have found.It is harder on hardware than windows.Mick M.

author: Artlav
author_rank: Frequent Contributor
timestamp: March 11, 2016, 07:32:55 pm
content: It gets weirder.I found a nice workaround - a USB hub.So, a 2 meter cable is plugged into the port. Connected straight to it the thing does not work at all, barely getting past chip erase.Now, plug a hub into this 2m wire, plug the programmer into the hub, and voila - it works each time every time!I guess the hub acts as a repeater or something like that?Weird.Anyway, that solves the problem for me.I also looked at the parameters for the console version of the quartus_pgm - there are a few of them, but none seem to be any sort of rate setting.So, whatever the software difference is, it's not at the surface...Quote from: MickM on March 11, 2016, 07:01:59 pmNot really.It seem to take about as long to program, but i don't know where to look at any solid numbers.Quote from: FivePoint03 on March 11, 2016, 06:47:01 pmHuh?Never heard of that before.AFAIK there is a maximum cable length in the standard.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 11, 2016, 08:42:31 pm
content: It sounds like the sort of problem I'd expect if there's some option to configure the timings differently at the physical layer.CAN bus is like this; most people know it can run at different baud rates, but fewer people know the exact bit timings and sample times can be programmed too, to best suit the cable length and topology on a per-installation basis.A hub will, of course, regenerate the timing of the interface locally, so having a hub attached via a short cable may well act as a workaround if not a good 'fix'.

author: Macbeth
author_rank: Super Contributor
timestamp: March 11, 2016, 10:11:18 pm
content: I had the opposite problem, my old USB Blaster stopped working in Windows, but was OK (ish) in Linux (it seemed to be really slow to work with Quartus)My newer knock-off works much better in both environments.https://www.eevblog.com/forum/microcontrollers/beginner-fpga-dev-board/msg822319/#msg822319

author: Whales
author_rank: Super Contributor
timestamp: March 12, 2016, 12:54:52 am
content: I searched for 'change usb port speed linux' and this was the first result:http://lists.en.qi-hardware.com/pipermail/discussion/2011-August/008508.htmlIt looks like you are not the first to suffer this problem with programmersSee if you can identify the device and hub id (a useful tool is 'lsusb', otherwise use dmesg as they suggest) and then change the speed.

author: Rasz
author_rank: Super Contributor
timestamp: March 12, 2016, 01:20:41 am
content: Quote from: Artlav on March 11, 2016, 07:32:55 pmpowered hub? maybe whack a big electrolytic cap on the stabiliser

author: FivePoint03
author_rank: Regular Contributor
timestamp: March 12, 2016, 09:03:48 pm
content: Quote from: Artlav on March 11, 2016, 07:32:55 pmUniversal Serial Bus Specification, Revision 2.0, April 27 2000:-6.4.4 Prohibited Cable AssembliesExtension cable assemblyA cable assembly that provides a Series “A” plug with a series “A” receptacle