From memory the trick is change the driver in FT_PROG from "D2xx" to "VCP" and the port A hardware type from whatever it is set to (FIFO perhaps) to "UART".
Looks like from this document: http://www.ftdichip.com/Support/Documents/AppNotes/AN_180_FT232H%20MPSSE%20Example%20-%20USB%20Current%20Meter%20using%20the%20SPI%20interface.pdf
Hardware type should be "245 FIFO" and driver set to "D2xx" for MPSSE mode. I don't know if any other settings matter.
I have a MPSSE cable of the same type at home I could check this evening, but I've messed around with the EEPROM before (setting it from MPSSE to UART and back to MPSSE again and changing the VIDs/PIDs) and I have no idea if my EEPROM config would actually work on Windows.
If you are using iceprog on Linux, none of this should matter however.
This is because most Linux distributions do not have the permissions set correctly for USB device access.
The best solution is to follow the udev rule instructions at:
http://www.clifford.at/icestorm/
And make sure your user is in the "plugdev" group by doing "sudo useradd -g plugdev <user>".
The other workaround for a quick test is just to run iceprog as root, by running "sudo iceprog ...".
• UPDuino Pins
o Note – If you want to program SRAM directly you need to treat FLASH_MISO as MOSI and FLASH_MOSI and MISO so that you program the FPGA directly in slave mode. Basically, just swap the MISO and MOSI pins around.
o J1 jumper must be shorted for SPI flash operation
o JP1 jumper needs to be connected to CRESET (pin closest to FPGA is CRESET, pin furthest away is GND)
Awesome! Great to see that SRAM programming works.
The unreliable flash is probably a signal integrity issue between the MPSSE cable and the Upduino, given the ID looks correct but verification is failing. I would try experimenting with the series resistance and seeing what happens.
1.8m seems a bit long for SPI - I suspect it's more luck than anything that SRAM programming works. It would be possible to slow things down, but that's not implemented in iceprog at the moment because no-one has needed it before (but it could be added easily enough). Diamond Programmer may already allow setting the SPI clock speed, I'm not sure.
I've been bitten pretty hard before by the FT232H for not reading their errata.
For the FT232H errata section 3.1.1 when EEPROM hardware config is set to 245 FIFO and the application switches to MPSSE the MPSSE protocol can corrupt due to glitches on the rd/wr lines.
Apparently fixed in silicon revB of this chip.
http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_130_FT232H%20Errata%20Technical%20Note.pdf
Something to check if all else fails.
Should take no time at all. The two 0x00s set the clock divider in iceprog.c at lines 771-772 (https://github.com/cliffordwolf/icestorm/blob/master/iceprog/iceprog.c#L771).
The first value is the LSB of the divider and the second the MSB.
The default, 0x0000 is 6MHz. Increasing it to say 0x0005 would give 1MHz, etc. Try increasing it, recompiling iceprog using make, and see what happens.