EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: jeremy on May 09, 2014, 12:08:46 am
-
Hi all,
I've purchased one of the MachXO2 breakout boards that mikeselectricstuff is always raving about. The Lattice Diamond software is actually quite good I think; it is fairly intuitive, and I managed to work out how to synthesise and pinmap a really basic design in about 2 minutes.
Unfortunately the programmer is being painful. I've tried installing on Ubuntu 14.04 which is technically unsupported, and I got everything working (as in, no library errors). Unfortunately the jtag server just can't seem to do anything properly:
ERROR: pgr_program failed.
Failed to Open FTDI USB port. Make sure to select the right cable type.
If you have not installed the FTDI Windows USB Driver, follow the instructions in the Programmer Help topic:
"Installing/Uninstalling Parallel Port Driver and USB Driver".
If you have installed the driver, if you recently plugged in the cable, please wait a few seconds and try again.
This will give the operating system time to recognize the cable.
And in the device programmer log I get:
System Information:
-----------------------------------------------------
Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Error communicating with FTUSB cable.
JTAG_OpenEx function: Device not opened.
So I decided to try installing it on CentOS which is 100% binary compatible with RHEL (which is a supported platform). CentOS is now even coordinated by Red Hat as a free version of RHEL. Unfortunately I got the exact same errors :(
I've tried using wireshark to dump the communication between the JTAG server and Diamond, and the server is responding to a command from the IDE with 2020: Command not found and then the connection is terminated. I'm not seeing any errors on the command line, nothing in dmesg, and using strace just shows the JTAG server sending a few bytes and going back to sleep.
I've tried to find out how to contact Lattice support, but I'm not that hopeful anything will come of it. Can anyone think of what I can do here?
-
Does your user have write permission on the correct /dev node (either the tty or I think there is a special FTDI device interface)?
-
Yep, added a udev rule for it. Diamond can detect the cable (which is not possible if the udev rule is missing), it just can't communicate with it. I have also tried running diamond as root.
-
Have you tried it on a Windows PC just to make sure the hardware is OK?
-
Yep, just checked it then. Works fine under windows.
-
Then it's not diamond which is making you sad - it's Linux.
-
Then it's not diamond which is making you sad - it's Linux.
While I appreciate the tongue in cheek humor, I can program it fine using urJTAG on linux, but I have to do a bunch of silly steps in diamond and then another program to get the bitstream as an SVF. I was hoping to avoid this, but I guess I don't have much of a choice now :palm: The only piece which doesn't work is "JTAGLServer" which is provided as binary-only by lattice, so it's not really fair to blame linux :-//
The command line sucks a bit too much for me to handle on windows, so I like to do my development on Linux. Altera and Xilinx work fine...
-
Is the Lattice software expecting FTDI's own Linux drivers?
-
Yep, I struggled with this for a long time. There are several things you need to do:
1. Dig out the online help that talks about Linux installation. There's some useful stuff there.
2. Download the latest FTDI drivers, something like libftd2xx1.1.12.tar.gz, and install.
3. Make sure you rmmod ftdi_sio, so you don't pick up the standard driver.
4. Upgrade to Diamond 3.1 to avoid the problem where it fails to program after a few goes.
Once I sorted out the above, it all just worked.
Rolfe
-
Yep, I struggled with this for a long time. There are several things you need to do:
1. Dig out the online help that talks about Linux installation. There's some useful stuff there.
2. Download the latest FTDI drivers, something like libftd2xx1.1.12.tar.gz, and install.
3. Make sure you rmmod ftdi_sio, so you don't pick up the standard driver.
4. Upgrade to Diamond 3.1 to avoid the problem where it fails to program after a few goes.
Once I sorted out the above, it all just worked.
Rolfe
HOORAY! Once I removed the ftdi_sio driver, it worked! ;D My friend, I owe you a beer.
-
After having some nasty problems with the programmer software in Diamond 2.1, I use their older ISPVM software for programming - I'd hope the original issues have been fixed in 3.x, but as I also found that ISPVM was quite a lot faster for the devices I was using at the time I stuck with it.
But sounds like this is a Linux/FTDI issue so probably wouldn't make a difference
4. Upgrade to Diamond 3.1 to avoid the problem where it fails to program after a few goes.
Maybe they fixed that issue, but could be worth checkingISPVM to compare speeds.
From memory, programming the XO2-7000 device on the devboard takes about 5 secs in SRAM mode and 30 secs to program the flash using ISPVM
-
After having some nasty problems with the programmer software in Diamond 2.1, I use their older ISPVM software for programming - I'd hope the original issues have been fixed in 3.x, but as I also found that ISPVM was quite a lot faster for the devices I was using at the time I stuck with it.
But sounds like this is a Linux/FTDI issue so probably wouldn't make a difference
4. Upgrade to Diamond 3.1 to avoid the problem where it fails to program after a few goes.
Maybe they fixed that issue, but could be worth checkingISPVM to compare speeds.
From memory, programming the XO2-7000 device on the devboard takes about 5 secs in SRAM mode and 30 secs to program the flash using ISPVM
Interesting. I will have to try it out and see how speedy it is. I just got my board working under Ubuntu 14.04 and the erase/program/verify time for the 7000HE on flash was 1 minute and 28 seconds using diamond.
For the record (in case anyone ever googles this), this is definitely an FTDI/Lattice issue. The kernel attaches the ftdi_sio driver for all FTDI devices that get plugged in by default. The software is supposed to tell it if it needs to use it for something else, and then it is released. But for some crazy reason they don't call usb_deatch_kernel_driver_np() in their FTDI d2xx driver. No idea why, because *everyone* else does this (libftdi, urJtag, etc) and it is well documented in libusb which is the foundation of the d2xx driver anyway. :-//
Thanks all for your assistance.
-
And once again, for historical purposes:
You can force the kernel to always unload the ftdi_sio for just the lattice device and give access to a non-superuser using these udev rules:
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666"
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", ATTRS{product}=="Lattice FTUSB Interface Cable", RUN+="/bin/sh -c 'echo $kernel > /sys/bus/usb/drivers/ftdi_sio/unbind'"
Just put the rules in /etc/udev/rules.d/98-lattice.rules or wherever your distribution hides the udev rules.
-
Just did a speed comparison between the Diamond 3.1 internal programmer and the older ISPVM standalone util.
SRAM : diamond 11 secs, ISPVM 4 secs
Flash : Diamond 40 secs ISPVM 30 secs
Diamond seems to always hang around for about 5 secs before doing anything - FAIL.
And despite being more "integrated" you still can't set it up to automatically program after a compile.
When will FPGA software come out of the stone age?
-
I am having significant issues trying to program MachXO3 using ubuntu:
https://www.eevblog.com/forum/microcontrollers/lattice-diamond-program-ftdi-issue/ (https://www.eevblog.com/forum/microcontrollers/lattice-diamond-program-ftdi-issue/)
comments appreciated
-
@mikeselectricstuff: could you tell me how you got ISPVM working with the XO2? I've spent numerous hours but can not get it to work..
-
@mikeselectricstuff: could you tell me how you got ISPVM working with the XO2? I've spent numerous hours but can not get it to work..
What exactly is the problem?
I just run it (having set the right cable type) & it works. The only issue I've ever had with Lattice programming is theor USB cable usually needs about 22pf on the clock line - seen this on both XO2 and the old EC FPGAs
-
When I open the .xcf file from my project, I get an error saying "MachXO2-2000ZE not supported"
-
When I open the .xcf file from my project, I get an error saying "MachXO2-2000ZE not supported"
Assuming you have the latest version, and it lets you select that device, but gives the error when loading, then I suggest you raise a support ticket with Lattice
-
Yes I have the latest version (18.1) and no, it does not let me select any MachXO2 device...
-
Unless they've changed something and not updated the version number, something's not right - My 18.1 install (Win7) allows selection of XO2 parts.
-
Hi Mike,
I redownloaded the installer from their website and this installer was named "ispVMSystemV18.1.1.exe". So apparently they also have minor versions which they "conveniently" don't state in the about tab of the tool. After installing this version, I went to Options > Device Database Installation, which allowed me to add support for the XO2-family. For completeness sake: the XO2 was not in the Device Database Installation menu of the other 18.1 version that I had.
Anyway, let's get streaming some bits!
-
Hi to all,
thanks for this thread. It saved my bacon. I have tried programming the board for bazzilion times and always failed miserably through FTDI, while Lattice ISP programming calbe worked.
It turned out to be same reason as with cups printing- I needed to remove kernel module, led generic USB layer show USB device and leave it accessible to the program, which accesses it with libftdi.
Thanks again.
But I have one more question:
I have two such boards. Originally both were with XO27000HE chip, but I managed to let magic smoke out of one, so I replaced it. BUt because Farnell didn't have HE version, I used HC instead and adapted VCC from 1.2V to 3.3V. Basically I bricked two Vccx testpoints together and so now I have 3.3V for I/O and core.
New chip seem to be soldered on correctly, but I can't program it through FTDI ( haven't checked ISP cable yet).
When trying to program basic demo ( blinks LEDs), it fails with:
Device#1 LCMXO2-7000HC: Failed to verify the ID
(Expected: 0x012BD043 Read: 0xFFFFFFFE).
ERROR - Check configuration setup: Unsuccessful.
ERROR: pgr_program failed.
ERROR - Programming failed.
I suspect FTDI's EEPROM might be the possible issue- that it expects HE version.
I noticved that those boards tend to carry different chips- early ones were with XO2-1200HE
Do they have to be tweaked (EEPROM) or should this just work and I screwed something else ?
-
I have both boards, one with a 1200-ZE and one with the 7000HE, they are great ! both have 2 regulators on board. I think you may have destroyed some pads during desoldering/soldering or you may have gotten some bridges/short-circuits between the pins. It would be good if you could check the connections between the FTDI chip and the fpga, there are some holes on the board (J1). Did you remove the old 1.2 V regulator ? or just short-circuited both outputs (1.2 & 3.3) ?
-
I didn't bother at first to do it the right way, so I just shorted bot regulators.
After that, I have removed the R56 ( which is bridge for VCCcore) and connect the FPGA-side of it to 3.3V.
Anyway, it works now. I managed somehow to cut DI line in a stupid way. After patching, whole thing works fine now.
This thread is worth pinning-up, though. That problem with ftdi_io is guaranteed to trip so many others....
-
OK, so I had to install diamond on linux recently and had to spend a good evening to get it up and running. I've seen other posts of people struggling with it so I decided to write a small guide on this topic, since none of the instructions worked for me. In my case I'm using XO3 board, diamond 3.7 on debian.
- Step 1: getting diamond + license
You have to register on their website to obtain the license. That might require a dozen of fake email addresses, since their stupid authentication system is living it's own life. When you fill in your "company" don't write "Unaffiliated" as suggested on the website - that will most likely result in unactivated account and you will keep getting "page not found" errors. To obtain a license you need to fill in your MAC address - I usually generate a random address and spoof it when I need to. Also, you have to renew the license every 6 months. Honestly, that's just a pain in the ass which is why I've been looking towards other vendors for quite a while.
- Step 2: installing diamond
In case your distribution doesn't support rpm-packages you can still install it without any problems. However, don't use alien on debian and it's derivatives - you'll waste lots of time and it won't work properly. Simply unpack the rpm package (put it in ~/local/diamond for example) and then unpack .tar archives in each subfolder (./bin/bin.tar, ./cae_library/cae_library.tar, etc). Now you should be able to run ./bin/lin64/diamond. If it complains about missing libraries then install those separately.
- Step 3: installing the license
MAC address in the license file has to match the address of eth0 interface. To spoof MAC-address run:
# ip link set dev eth0 down
# ip link set dev eth0 address XX:XX:XX:XX:XX:XX
I do that on every machine where I use diamond. Great idea, Lattice. Thanks for making my life so much easier.
- Step 4: getting the programmer to work
At this point if you attach the programmer and run diamond, it will crash with a segfault and complain about usb write permissions. To get the programmer working we need to set the appropriate permissions and also unbind the ftdi_sio driver. However, in my case XO3 board has a FT2232H chip which provides a dual interface. If you look at dmesg output you should see something like
[71334.912360] usb 8-2: Product: Lattice XO3L Starter Kit
[71334.912363] usb 8-2: Manufacturer: Lattice
[71334.915149] ftdi_sio 8-2:1.0: FTDI USB Serial Device converter detected
...
[71334.918138] ftdi_sio 8-2:1.1: FTDI USB Serial Device converter detected
If you try to unbind ftdi_sio from device 8-2 it will not work - you have to specify device 8-2:1.0. In this case we only need to unbind the first interface, since it's used for programming.
Here is a complete udev rule:
# Lattice FTDI programmer
SUBSYSTEM == "usb", DRIVER == "usb", \
ATTRS{idVendor} == "0403", ATTRS{idProduct} == "6010", \
MODE := "0666", RUN += "/bin/sh -c 'basename %p:1.0 > /sys/bus/usb/drivers/ftdi_sio/unbind'"
Place it under /etc/udev/rules.d/49-lattice.rules and run udevadm trigger afterwards.
If everything works properly, you should have similar dmesg output after attaching the board:
[71334.915526] usb 8-2: FTDI USB Serial Device converter now attached to ttyUSB0
[71334.918138] ftdi_sio 8-2:1.1: FTDI USB Serial Device converter detected
...
[71334.927683] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[71334.927699] ftdi_sio 8-2:1.0: device disconnected
-
Couple more remarks about Diamond:
1. Check file owners. When you find and untar all those tarwhatevers, you'l find they have undefined owners and possibly permissions.
This can causevarious problems later, during usage, when programs call each other.
2. Same problem with libraries. Depending on your distro, it might happen that Diamond needs library that you don't have or that has wrong version and/or missing feature.
You can see that it has some libraries (libQtsomething ) but this just burries basic problem one level deeper- those libraries then just depend on some other libs on your system.
I usually copy libQtxxx from my system folder into Diamond/libs and if needed, I compile them specially for this purpose. There muste be other solutions, but I never bothered.
3. network card name. For some reason, Diamond checks JUST interfaces named ethX. If you have on your system NIC that either gets kernel's basic name like enp0sx or udev renames it to something like lan or wlan, you are f**ed. You have to correct change it to ethX.
4. As said before, at least for the time being, you have to remove or deactivate ftd_sio kernel module ( or compile kernel without it, if its built-in), if you plan to use FTDI-based programmers that are onboard.
-
I managed to get Diamond working on Linux, thanks for the tips!
However, for some reason it is almost an order of magnitude slower than on Windows. I'm using the "pgrcmd" to program devices from the command line using an xcf file created with Diamond. On Windows, CRAM program & verify takes less than 10s whereas on Linux it is more than one minute! Does anyone know if there is a way to make this faster? I need to program the NVCRAM of a few hundred devices and waiting 1 minute isn't really practical. All our work is on Linux, so it would be annoying to need a Windows PC just for this step.
-
Diamond is indeed slower under linux. Programming doesn't take that long for me, however the programmer takes about 10 seconds before it starts doing anything (I use the GUI thing from within diamond).
I think your best option is to follow Mike's advice and use ISPVM software.
Latest version for linux is 17.9, although 18.1 runs ok under wine.
http://files.latticesemi.com/ispVM/ispVMSystemV18.1.1.zip
http://files.latticesemi.com/ispVM/ispvm_v17_9_linux.tar.gz
Both versions did not support XO3, however you can add missing database files (Database/xpga/xo3) from diamond programmer.
This is as far as I got with ISPVM, since for some reason it refused to detect FTDI cable. I might give it another shot and revisit this post later.
-
Yep, I struggled with this for a long time. There are several things you need to do:
1. Dig out the online help that talks about Linux installation. There's some useful stuff there.
2. Download the latest FTDI drivers, something like libftd2xx1.1.12.tar.gz, and install.
3. Make sure you rmmod ftdi_sio, so you don't pick up the standard driver.
4. Upgrade to Diamond 3.1 to avoid the problem where it fails to program after a few goes.
Once I sorted out the above, it all just worked.
Rolfe
HOORAY! Once I removed the ftdi_sio driver, it worked! ;D My friend, I owe you a beer.
Actually, you don't have to remove the driver - which will also prevent any other FTDI adapters from working.
Just detach it like this (modify for your device, of course):
https://lwn.net/Articles/143397/
That can be automated by a small script. There is even a ready made utility for this somewhere on Github.
-
I just installed Lattice Diamond 3.9 on Archlinux, and I kept getting crashes *after* doing the whole udev dance.
Turns out that their libftcjtag (which seems to be a libusb derivative) has a bug in their EventDestroy() function which leads to a segfault in libpthread's __lll_unlock_elision. The bug is a double pthread_mutex_unlock(), which leads to a segfault on modern Intel processors which support the xstart/xend transactional memory instructions.
All Event*() functions leave the mutex unlocked upon exit, yet EventDestroy() calls pthread_mutex_unlock():
0000000000023c8b <EventDestroy@@Base>:
23c8b: 55 push %rbp
23c8c: 48 89 e5 mov %rsp,%rbp
23c8f: 48 83 ec 10 sub $0x10,%rsp
23c93: 48 89 7d f8 mov %rdi,-0x8(%rbp)
23c97: 48 8b 45 f8 mov -0x8(%rbp),%rax
23c9b: 48 89 c7 mov %rax,%rdi
23c9e: e8 ad d7 fe ff callq 11450 <pthread_mutex_unlock@plt>
23ca3: 48 8b 45 f8 mov -0x8(%rbp),%rax
23ca7: 48 83 c0 28 add $0x28,%rax
23cab: 48 89 c7 mov %rax,%rdi
23cae: e8 fd bc fe ff callq f9b0 <pthread_cond_destroy@plt>
23cb3: 48 8b 45 f8 mov -0x8(%rbp),%rax
23cb7: 48 89 c7 mov %rax,%rdi
23cba: e8 61 d6 fe ff callq 11320 <pthread_mutex_destroy@plt>
23cbf: c9 leaveq
23cc0: c3 retq
together with:
http://repo.or.cz/glibc.git/blob/HEAD:/sysdeps/unix/sysv/linux/x86/elision-unlock.c (http://repo.or.cz/glibc.git/blob/HEAD:/sysdeps/unix/sysv/linux/x86/elision-unlock.c):
23 int
24 __lll_unlock_elision(int *lock, int private)
25 {
26 /* When the lock was free we're in a transaction.
27 When you crash here you unlocked a free lock. */
28 if (*lock == 0)
29 _xend();
30 else
31 lll_unlock ((*lock), private);
32 return 0;
33 }
does exactly what the comment says :)
zsh: segmentation fault (core dumped) /usr/local/diamond/3.9_x64/bin/lin64/diamond
#0 0x00007ffff620c6c0 in __lll_unlock_elision () from /usr/lib/libpthread.so.0
#1 0x00007fffd1cb5ca3 in EventDestroy () from /usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so.1
#2 0x00007fffd1cb00f2 in FT_Close () from /usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so.1
Fix:
Using the offset of the call to pthread_mutex_unlock() identified in the objdump of EventDestroy():
printf "\x90\x90\x90\x90\x90"| sudo dd of=/usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so bs=1 seek=$((0x23c9e)) conv=notrunc
Win!
Edit: turns out that you also need to either patch the same bug out of cableservermain, or you just nuke it alltogether:
ln -fs $(which false) /usr/local/diamond/3.9_x64/bin/lin64/cableserver
-
Using the offset of the call to pthread_mutex_unlock() identified in the objdump of EventDestroy():
printf "\x90\x90\x90\x90\x90"| sudo dd of=/usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so bs=1 seek=$((0x23c9e)) conv=notrunc
Win!
That's a pretty hardcore method of patching binaries :scared:
I think I will stick with my hex editor.