On Ubuntu releases post-16.04, I've always had a difficult or impossible time getting devices to program (MAX10-lite, DE2i-150, DE10-standard, etc). I've gone through all of the standard things (USB cables, ports, different machines, etc) and finally I decided that with Quartus 18.1.1 and Ubuntu 19.04 I figured I'd try to track down the root issue.
I figured it out, or at least a way to make it work.
If you run "quartus_pgm -l" you get a list of ports. What I've found is that whatever device is enumerated as 1 won't work, but the others works as expected. If I swap the devices to different ports, the broken JTAG chain error stays with the logical port, not the device.
Since it's less verbose, I'll demonstrate with the output of jtagconfig. I kill jtagd between the tests because it gets a bit confused about the device swap otherwise:
mstock@peach:~/projects/soc$ jtagconfig --enum 1) USB-Blaster [1-13.2] Unable to read device chain - JTAG chain broken 2) USB-Blaster [1-13.4.1] 031050DD 10M50DA(.|ES)/10M50DC mstock@peach:~/projects/soc$ ps agux | grep jtag mstock 4916 1.4 0.0 35156 3468 ? S 12:46 0:01 jtagd --user-start --config /home/mstock/.jtagd.conf mstock 4966 0.0 0.0 8856 908 pts/0 S+ 12:48 0:00 grep --color=auto jtag mstock@peach:~/projects/soc$ kill 4916 mstock@peach:~/projects/soc$ jtagconfig --enum 1) USB-Blaster [1-13.2] Unable to read device chain - JTAG chain broken 2) USB-Blaster [1-13.4.1] 028040DD EP4CGX150
Is anyone running Ubuntu 19.04 and not having any issues at all, or conversely, can any folks who have had issues with this confirm that this "fix" works?
I can submit a bug report to Intel if I can get some confirmation I'm not nuts.
I should also note that this is true even when I totally swap around USB ports - via a hub, direct to the host, etc. Whichever is enumerated at the top doesn't work, and the other one is fine.
Just would like to know, how you tried to specifies the port to which you attached new programming by using command below?
jtagconfig --add <type> <port> [<name>]
Also, have you tried to program without checking with "jtagconfig" command? Is it working fine?
Thanks for the questions. I didn't use jtagconfig --add at all, since these are auto-recognized USB ports. If that is something I should try, let me know what invocation you suggest.
With regards to programming, yes. The only reason I used jtagconfig is to demonstrate the enumeration behaviors. When I try to program, the connection times out with the JTAG chain broken error.
I've been doing additional tests with additional boards, and I *don't* seem to have this issue with the DE10-Standard board from Terasic. I don't have any other boards to test against, but so far DE2i-150 and MAX10-lite have this odd behavior, DE10-Standard does not. I have a standalone Blaster but currently nothing to connect it to for testing. It's possible that it's some subtle interaction between the USB drivers on Linux and the specific way some of the boards are configured/Blaster firmware, but I really don't know.
It seems like it is driver related on Linux or software on the host machine that is conflicting with with USB Blaster. Can you try to install the blaster drive again on linux by following the guide below?
Also, can you try with USB Blaster II and have the TCK frequency set to 6MHz?
It's been a while since I looked at this, but your timing is good as I just picked it up again a couple of days ago.
There is no driver for the USB Blaster on Linux, however I can confirm that this isn't a permissions issue - I have full write access to the ports.
The dev boards I'm using have an integrated USB Blaster on them, and so I am not using an external programmer. That said, if you are willing to send me a Blaster II I can test it. I am not going to purchase a $250 programmer as a random test.
One other note - it appears that this is tied to changes in behavior in the Quartus programmer itself. I have installed an older release of Quartus (15.1 in particular), and programming the DE2i-150 and DE10-lite boards using that appears to work much more reliably. I still intend to do the compilation on 19.1, but I can fire up the older programmer and hopefully script the whole process.
So you are saying that in Quartus v15.1, the JTAG Chain broken issue is no longer there. But in Quartus v19.1, the JTAG Chain broken issue is existed for DE2i-150 and DE10-lite?
Just would like to check, have you tried to compile the design in v19.1 before program using v19.1?
Yes, this is compiling in 19.1. The issue isn't in the generation of the pof/sof files, it's in the programming. Something changed between the older programmer releases and the newer. Specifically, it appears to be the jtagd process. If the jtagd process (which does the actual communications with USB) is running from the 19.1, the 15.1 or 13.0 programmers will connect but fail. If I kill that jtagd (or simply don't load it up on 19.1) and have the 15.1 or 13.0 release jtagd run, everything works as expected. I have not tried to run the 15.1 jtagd by hand and test 19.1, but I intend to give that a try later.