Hobby Components Altera USB Blaster frequently causing bsod during flashing

[renegadeandy]

Hi all,

I have this USB Blaster : https://hobbycomponents.com/featured/273-altera-fpga-cpld-usb-programmer-usb-blaster-compatible

Very frequently when I click the start button for flashing from Quartus Prime 18.1 I get a BSOD. Sometimes….it works, a lot of the time, it does not.

Any suggestions on what to do to stabilise this? I use the Quartus Prime 18.1 provided USB Blaster x86 64bit driver

[Deleted User]

It’s a common problem caused by “cheap” USB Blasters.

From what I can tell, these have timing issues on initialisation, which (under Linux) cause the JTAG daemon to segfault, and under Windows to crash.

From hearsay an older Version of Quartus (14?) could help resolve the issue, but on Linux I wasn’t able to reproduce that. Aside from that, it’s a case of “you get what you pay for”.

I’ve had moderate success quickly pulling the plug on the device and replugging it while the connection is initialising, but that’s more or less a luck based solution.

[renegadeandy]

Suggestions on a non ‘cheap’ model I should purchase if that’s the case?

[Morpheus_79]

I can confirm the BSOD issue with (some of) the cheap Chinese USB Blaster clones and newer Quartus Prime versions. The last version working for me with such a USB blaster clone is v13.1.
Someone informed me, that it’s related to the microcontroller inside the clones. There are some with an STM32F101 – those will crash. And there are some with a PIC18F14k50 – those won’t crash. Sadly they are indistinguishable from the outside, since they are using the same casing.

In the end it’s kind of a ‘hit and miss’ with those clones. So to be on the safe side you’ll have to buy an official Intel/ALTERA one – like this:

https://www.mouser.com/ProductDetail/Intel-Altera/PL-USB-BLASTER-RCN?qs=jblrfmjbeiFezz56mIHRCg%3d%3d

The (cheaper but newer) one from Terasic should work too, since both are recommended by Intel for the Cyclone FPGA family:

https://www.mouser.com/ProductDetail/Terasic-Technologies/P0302?qs=ePbE9GiMmvVJztTDlxPoAw%3d%3d

But i’ve read about some very rare compatibility issues inside Quartus Prime with those too… even though the Terasic one is an official product with an ALTERA sanctioned design.

[Deleted User]

I actually have one of the Terasic Blasters you’ve posted, @Morpheus_79. Sadly, it’s not working much better than the cheap USB Blaster I’m using. I believe there are some deeper down issues, but I’m still investigating.

Both devices are segfaulting jtagd on Linux with the current Quartus software.

Time to strace it and see if that shows up anything.

[marqs]

If you’re only updating bitstream on the device, it’s possible to convert .sof to .svf and use e.g. OpenOCD to handle the programming.

[Deleted User]

Thanks, @marqs.

I’ve done a bit of research. I can get a connection to the JTAG chain occasionally, with both of these devices:

USB Blaster with STMF103C8T6
Terasic USB Blaster with Altera 5M160ZE64C5N

Starting jtagd as root with an strace -f allowed me to trace through the behavior:

Often, the jtagd gets stuck in a loop which eventually segfaults. This happens with the quartus software or when using jtagconfig:

ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = -1 EAGAIN (Resource temporarily unavailable)
select(7, NULL, [6], NULL, {tv_sec=5, tv_usec=0}) = 1 (out [6], left {tv_sec=4, tv_usec=999874})
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = 0
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = 0
ioctl(6, USBDEVFS_SUBMITURB, 0x125ed40) = 0
ioctl(6, USBDEVFS_SUBMITURB, 0x125ef50) = 0
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = -1 EAGAIN (Resource temporarily unavailable)
select(7, NULL, [6], NULL, {tv_sec=5, tv_usec=0}) = 1 (out [6], left {tv_sec=4, tv_usec=999869})
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = 0
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = 0
ioctl(6, USBDEVFS_SUBMITURB, 0x125ef98) = 0
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = -1 EAGAIN (Resource temporarily unavailable)
select(7, NULL, [6], NULL, {tv_sec=5, tv_usec=0}) = 1 (out [6], left {tv_sec=4, tv_usec=999856})
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3cad8) = 0

The eventual segfault:

ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3dab8) = -1 EAGAIN (Resource temporarily unavailable)
select(7, NULL, [6], NULL, {tv_sec=5, tv_usec=0}) = 1 (out [6], left {tv_sec=4, tv_usec=999873})
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3dab8) = 0
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3dab8) = -1 EAGAIN (Resource temporarily unavailable)
select(7, NULL, [6], NULL, {tv_sec=5, tv_usec=0}) = 1 (out [6], left {tv_sec=4, tv_usec=999318})
ioctl(6, USBDEVFS_REAPURBNDELAY, 0x7fff1cc3dab8) = 0
writev(5, [{iov_base="\0\3", iov_len=2}, {iov_base="\0\0\0\4", iov_len=4}], 2) = 6
select(6, [3 5], NULL, NULL, {tv_sec=1073, tv_usec=741823}) = 1 (in [5], left {tv_sec=1073, tv_usec=741756})
recvfrom(5, "\0\37", 2, 0, NULL, NULL)  = 2
recvfrom(5, "\251\0\0 \0\22\0\1\0\0\0\0\23JTAG Chain Debugger", 32, 0, NULL, NULL) = 32
writev(5, [{iov_base="\0\7", iov_len=2}, {iov_base="\0\0\0\10\1\0\0\0", iov_len=8}], 2) = 10
select(6, [3 5], NULL, NULL, {tv_sec=1073, tv_usec=741823}) = 1 (in [5], left {tv_sec=1073, tv_usec=741821})
recvfrom(5, "\0\7", 2, 0, NULL, NULL)   = 2
recvfrom(5, "\243\0\0\10\0\22\0\1", 8, 0, NULL, NULL) = 8
writev(5, [{iov_base="\0\3", iov_len=2}, {iov_base="\0\0\0\4", iov_len=4}], 2) = 6
select(6, [3 5], NULL, NULL, {tv_sec=1073, tv_usec=741823}) = 1 (in [5], left {tv_sec=1073, tv_usec=741821})
recvfrom(5, "\0\33", 2, 0, NULL, NULL)  = 2
recvfrom(5, "\301\0\0\f\1\0\0\0\0\0\3\350\311\0\0\20\1\0\0\0\0\0\0\5\0\0\0\1", 28, 0, NULL, NULL) = 28
recvfrom(5, "@\0", 2, 0, NULL, NULL)    = 2
recvfrom(5, "\0", 1, 0, NULL, NULL)     = 1
recvfrom(5, "P\0", 2, 0, NULL, NULL)    = 2
recvfrom(5, "\377", 1, 0, NULL, NULL)   = 1
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x40127a014} ---
+++ killed by SIGSEGV (core dumped) +++

Steadily plugging the device in and back out will eventually get a recognition off of the device:

geiger@loki:~$ jtagconfig
1) USB-Blaster [1-1.2]
  Unable to read device chain - JTAG chain broken

geiger@loki:~$ jtagconfig 
1) USB-Blaster [1-1.2]
  Unable to read device chain - JTAG chain broken

geiger@loki:~$ jtagconfig 
1) USB-Blaster [1-1.2]
  Unable to read device chain - JTAG chain broken

geiger@loki:~$ jtagconfig 
1) USB-Blaster [1-1.2]
  020F20DD   10CL016(Y|Z)/EP3C16/EP4CE15

Once this occurs, one can actually attach different JTAG chains to it. As long as the device stays initialized, it can be used to push the bitstream.

Important here: The OSSCs in questions don’t play a role in this situation. The devices seem to hang on initialization with the JTAG daemon. One can cause them to hang or work without having the OSSC connected, and then reattach different OSSCs after the initialization works.

I’ve gathered quite a lot of different straces for this from jtagd and will gladly open up a bug/issue with the Quartus team if someone might point me to the right direction. 😉

also @marqs: Did you see my Pull Request on GITHUB? Having that merged would make assembly tutorials a bit easier. 😉

[marqs]

The reliability issue with usb blaster sounds familiar even though I never got it to segfault. For me the solution was related to libudev, see this. I saw the pcb pull request, will take a better look on the weekend.

[renegadeandy]

Any updates on this @marqs? Please bare in mind I am using windows here…

[marqs]

Being Altera/Intel’s primary supported platform, I wouldn’t except such issue with Windows. Bad drivers are still bad drivers, so I’d try OpenOCD route if there are any problems with Quartus or the drivers shipped with it. You can use other JTAG programmers with OpenOCD as well, but keep in mind that you can’t use any Altera-specific features (e.g. SignalTap) with it.

[Author]

Posts