FT232HL config

[CM800]

I accidently brought a C232HD USB to UART converter.

It uses the same chip as the USB to MPSSE (FT232HL) and I can connect to it using the FT_PROG program.

Is there a way to reprogram the cable to act as USB to MPSSE from USB to UART?

From the two manuals, it seems like the schematic is the same, what configs do I need to change on it? (I could just try, but don't wish to break it)

[daveshah]

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

[CM800]

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

Hi Dave,

Trying to go the other way around.

I suspected that was the case, its the port A hardware setting I'm a little mixed up on.

http://puu.sh/As2If/86e8374abf.png

There seem to be a few options, which would you suggest?

I don't have the correct cable so as to compair settings. I suspect its the FT1248 I need?

I plan to use this to play with one of those UPduinos.

[daveshah]

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.

[CM800]

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.

Yes, your cable was the one I meant to buy. Unfortunately I brain-farted at 1AM when I ordered it. Checking it would be great thanks!

I'm using Windows, and planned to use the genuine Lattice software. Is there any advantages to the iceprog / icestorm software over it?

[daveshah]

The main advantages of icestorm/iceprog are:
 - super fast compile times, great for experiments (2 seconds from Verilog to programmed FPGA SRAM on a decent PC)
 - lightweight and no license hassle
 - support on GitHub and IRC listens to individual users unlike Lattice's official channels (Clifford and I have both fixed issues within 24 hours)
 - better Verilog synthesis, particularly memory inference, than Synplify/LSE in many cases
 - can run on embedded systems, so your hardware can build its own bitstreams on the fly in response to user customisation

The downsides are:
 - Verilog only, no useful VHDL support
 - 20-30% worse and less predictable timing (hopefully this will be fixed soonish with a new place and route tool)

[daveshah]

Here's my config in FT_PROG. This is most certainly not how the MPSSE cable ships out of the box, but I think this worked with Diamond on Windows back when I was doing the MachXO2 stuff.

[CM800]

Thanks for your help Dave! 

I've ended up installing a linux virtual box, got quite far, right up to the point of trying to program the upduino.

I keep getting an issue about it not finding the programmer, however I can clearly see it is there using lsusb:



Any ideas on what to try next?

[daveshah]

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

[CM800]

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

Thanks Dave, that sorted it out for good, I gave sudo ago and found it to work too.

looking through the instructions, it asks me to short JP1 (have done)

and wire up the blue wire (reset pin 'D7') to the reset pin on the UPduino board.

Initially nothing happened, I suspected the reset output wasn't working, so when I unplugged it, it progressed through erase etc. But after programming it 'finds difference between flash and file'


I've tried this but it's coming back with the following error:



I have tried with and without shorting it.

[daveshah]

Normally flash ID should not be all 0xFF, this indicates a communication problem. A few things to note:
 - use the grey wire for chip select
 - make sure MOSI and MISO are the right way around (try swapping them if needed)
 - add a small amount of capacitance between the clock line and ground (I've found this to be needed for fully reliable programming with one of these cables).

[CM800]

Hi Dave,

Alright then,

I've changed the CS pin to the gray wire. I had been following the pin given in the FTDI chip manual rather then the UPDuino manual.

I've checked and switched over MOSI and MISO around (first time was 'right')

I tried putting 2n2f between the clock and gnd, but it seemed to just pause the effort from any progress.

My current feedback is as so:





Reading the UPDuino manual, which way should I be focusing on setting it up? (I've tried both)

Code: [Select]

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

[daveshah]

That flash ID now looks correct. Try either a much smaller capacitor on the clock line (around 18pF), or alternatively physically extending the clock line or adding series resistance of about 100ohm to it.

[daveshah]

You can set it up for both SRAM or SPI flash programming. SRAM is a bit quicker, but is lost after power off. If you wire it for SRAM, you also need to enable SRAM programming in iceprog by putting "-S" before the filename on the command line.

[CM800]

Okay,

I've tried 100 Ohm, if I go for SRAM (turn the MISO MOSI lines around) then upload with the -S marker, it works! I got the LED to color shift.

However, the FLASH doesn't seem to work.

[daveshah]

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.

[CM800]

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.

Sure is!

I have the 1.8m long cable on the unit. I hope that isn't the reason... I spent a few hours soldering some jumper DSUB 15 pin connectors on it in the middle.

Curious how its fine for the FPGA SRAM, but not the flash...

[daveshah]

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.

[CM800]

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.

Considering the time to rewire the whole cable, how significant would it be to find the variable and try slow it down? (Recompile)

[daveshah]

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.

[rmacintosh]

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.

[CM800]

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.

This cable could be recent... hard to tell. I only just brought it.

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.

Okay, I've changed it as suggested, no change to the situation it seems?



No longer works with SRAM...

[daveshah]

1MHz still might be a bit high, I've found signal integrity to be a bit of an issue with SPI programming at the best of times. One thing to try would be to increase the divider even more, say 0x50. Another thing would be to experiment more with series resistance or capacitance to ground in the clock line.

[CM800]

Okay, so:

SRAM Tests:

0 Ohm, default frequency: No Programming
240 Ohm, default frequency: Programming

0 Ohm, (0x0001) frequency: No Programming
240 Ohm, (0x0001) frequency: No Programming

0 Ohm, 1MHz (0x0005) frequency: No Programming
240 Ohm, 1MHz (0x0005) frequency: No Programming

0 Ohm, (0x0010) frequency: No Programming
240 Ohm, (0x0010) frequency: No Programming

0 Ohm, (0x0050) frequency: No Programming
240 Ohm, (0x0050) frequency: No Programming

I don't know how many different combinations I should try before deciding we need to try a different route or... not sure.

[daveshah]

Hmm, this is very odd. Next thing to try would be replacing the 240ohm resistor with 20-30cm of extra wire on the clock, at the original and 1MHz frequencies.