windows can't recognize my lattice machxo2 board

[i1ya]

Hi,
I purchased a MACHXO2 - 1200ze evaluation board a few days ago.
I started with designing and programming simple projects as blinking leds, which worked perfectly.
After that at the same day I tried to synthesize and program a greater project. The synthezition process passed without any errors and xcf file was produced.
At the next step I tried to program the device (I use diamond 3.1).
The programming process took for more than 30 minutes and wasn't finished so I quit the program  and restarted my computer.
Then when I tried again to connect the device and program, the device wasn't recognized at all by windows. Not at the device manager an not in devices and printers.
 And when I tried to program again an error was showed:

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.




ERROR: pgr_program failed.




ERROR - Programming failed.

Although the drivers of the FTDI are installed and it worked before.  I chose cable: HW-USBN-2B (FTDI) and port: FTUSB-0.
I tried it on different computers (with drivers installed) and the same error was produced.
I also tried different USB slots in my computer, replaced the USB cable with another, made reset to the computer and nothing helped.
At the next day I asked my friend who purchased the same board a year ago.
I programmed the simple blinking led project, and it worked fine (the led actually blinked).
Then I tried to program the bigger project. The same thing happend: it took a lot of time to download and then I quit the program.
After that I tried to program again even that simple blinking led project, and the same error message showed.
Actuallty the devise wasn't recognized at all. Now both kits don't work.

Did anyone encounter such a problem? I'm lost and can't progress with my project

[Monkeh]

It appears you were the victim of the [now famous] FTDI driver with trojan malware that "bricks" clone FTDI devices.  See this thread:

https://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/

In the thread, there is a Linux script that will recover your bricked device, and put it into a condition where the FTDI trojan malware will not bother it.

That's a very quickly jumped to conclusion, now isn't it?

[ataradov]

That's a very quickly jumped to conclusion, now isn't it?

That was my first instinct as well even without fully reading the question. See how FTDI in just one dick move put themselves into this position. You never know, but now if something goes wrong with FTDI, that  is going to be the first though for quite some time.

[mc]

Going by the fact the board in question uses a genuine FTDI FT2232H parallel chip, I'd doubt it's been bricked by the driver.

And combined with the fact the board did work initially, makes me suspect that something the OP did caused the problem.

[hans]

In both cases it sounds like the OP re-enumerated the USB device in someway (rebooting or replugging), which makes the FTDI reload its EEPROM configuration which at that time may be bricked.

I would seriously consider debugging the FTDI issue first. Because there is a report that the a genuine(supposedly) FT2232H would have been bricked by the driver:
https://twitter.com/marcan42/status/525291106104115201

If possible startup a native Linux OS (Ubuntu live CD/disk will do) and run the "sudo lsusb" in a terminal to show a list of all (enumerated) USB devices. If there is any device that has the ID "0403:0000" then a recent (withdrawn) FTDI driver is the cause. If so, it can be fixed: http://www.reddit.com/r/arduino/comments/2k0i7x/watch_that_windows_update_ftdi_drivers_are/clgviyl (or search around in the "big thread" - there is a Python script for detecting and fixing it too)
(tip: downgrade your FTDI drivers too)

Alternatively, if the PID is 0 but you don't want the "soft fix" you could remove the EEPROM chip from the board. I'm not sure though if there is any custom EEPROM configuration for that board that is being used. The "preventive measure" also disables the EEPROM functionality by corrupting the checksum.

If none of this is the case, I recommended taking a very good look at your FPGA project itself.

[mikeselectricstuff]

There can be issues if there is another FTDI device plugged in.