Knock-off USB Blaster in Linux issues?

[Artlav]

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?

[Rasz]

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 openocd
quick google gives me this as an example code that can talk to usb blaster using userspace usb library https://github.com/swetland/jtag

edit: doh, im such a dork 
read first half and assumed it didnt work at all

[AndyC_772]

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?

[Artlav]

What target are you programming? Is it an EPCS4?

EPCS4, 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.

[Artlav]

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.

[MickM]

Hi;
  It seems that you have solved the problem.
Use good quality short shielded USB cables

Mick M.

[Artlav]

It seems that you have solved the problem.

I 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.

[diyaudio]

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?

I've had the same dam issue on windows

[FivePoint03]

It seems that you have solved the problem.
Use good quality short shielded USB cables

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.

Aren'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.

[MickM]

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.

[Artlav]

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...

Are you sure that Windows is running as fast?

Not really.
It seem to take about as long to program, but i don't know where to look at any solid numbers.

Aren't USB extension cables explicitly non-compliant with USB?

Huh?
Never heard of that before.
AFAIK there is a maximum cable length in the standard.

[AndyC_772]

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'.

[Macbeth]

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

[Whales]

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.html
It looks like you are not the first to suffer this problem with programmers   See 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.

[Rasz]

I found a nice workaround - a USB hub.

powered hub? maybe whack a big electrolytic cap on the stabiliser

[FivePoint03]

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...

Are you sure that Windows is running as fast?

Not really.
It seem to take about as long to program, but i don't know where to look at any solid numbers.

Aren't USB extension cables explicitly non-compliant with USB?

Huh?
Never heard of that before.
AFAIK there is a maximum cable length in the standard.

Universal Serial Bus Specification, Revision 2.0, April 27 2000:-
6.4.4 Prohibited Cable Assemblies
Extension cable assembly
A cable assembly that provides a Series “A” plug with a series “A” receptacle