Lattice Diamond is making me sad

[jeremy]

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:

Code: [Select]

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:

Code: [Select]

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?

[ve7xen]

Does your user have write permission on the correct /dev node (either the tty or I think there is a special FTDI device interface)?

[jeremy]

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.

[Harvs]

Have you tried it on a Windows PC just to make sure the hardware is OK?

[jeremy]

Yep, just checked it then. Works fine under windows.

[poorchava]

Then it's not diamond which is making you sad - it's Linux.

[jeremy]

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

[andersm]

Is the Lattice software expecting FTDI's own Linux drivers?

[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

[jeremy]

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!    My friend, I owe you a beer.

[mikeselectricstuff]

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
 

[jeremy]

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.

[jeremy]

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:

Code: [Select]

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.

[mikeselectricstuff]

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?

[peepo]

I am having significant issues trying to program MachXO3 using ubuntu:

https://www.eevblog.com/forum/microcontrollers/lattice-diamond-program-ftdi-issue/

comments appreciated

[pix3l]

@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]

@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

[pix3l]

When I open the .xcf file from my project, I get an error saying "MachXO2-2000ZE not supported"

[mikeselectricstuff]

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

[pix3l]

Yes I have the latest version (18.1) and no, it does not let me select any MachXO2 device...

[mikeselectricstuff]

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.

[pix3l]

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!

[Brane212]

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 ?

[ale500]

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) ?

[Brane212]

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