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.

[CM800]

Okay, I've tried:

20cm - fail
1m - fail

the whole god damn 100m roll - success (steel sheet core fyi)

It seems to always fail when the frequency is changed, no success at least so far.

[daveshah]

OK, this is interesting...

Next step to try then is some capacitance to ground then (but less than 2.2nF). With a MachXO2, Diamond Programmer, and a MPSSE cable I found 18pF worked but I suspect you may need a bit more than that.

I think the problem might be related to noise on the clock line causing spurious clocks but I'm not completely sure.

[CM800]

Okay,

With a low pass filter stile setup ( clk in >> --- RES --- CAP2GND --- >> out )

i can go up to 330pf (and any values under it) with SRAM mode operationally. with the 270R resistor.

trying to remove the resistor at any capacitor value stops operation.

[daveshah]

You should be able to get away with more capacitance if you decrease the clock frequency again.

What is happening during flash programming with the RC filter?

[CM800]

You should be able to get away with more capacitance if you decrease the clock frequency again.

I have yet to have any success with any programming frequency change in any resistor / cap combination so far.

I hasten to keep playing with it as with no sucesses, it adds more time to any combination tests. I feel like we are fighting in the dark here.

What is happening during flash programming with the RC filter?

With 550pf I get a different flash ID and it gets stuck on the first erase:



Compared with the standard one with just a resistor:

[daveshah]

Yeah, never tried the frequency change myself so can't say for sure that it works at all.

I have seen that some Upduino boards have used recycled flash memory chips (confirmed on one site by the presence of Cisco strings in the flash). It could be that the one on your board has software write protect enabled, which is causing writes to fail.

Can you try replacing iceprog.c with this one:
 https://github.com/daveshah1/icestorm/blob/unbrick/iceprog/iceprog.c
rebuilding iceprog, and running "sudo iceprog -p", then trying a write again (keeping the resistor and a low value capacitor)?

[CM800]

Well... What do you know... It works! (FLASH)

With that version, the 50pf Cap and resistor, it works

if I remove the 50pf it fails (or if I tweak it / at random fail)  it seems right on the edge. I'll try values either side too.

If I try slightly above or below 50pf, amazingly it doesn't work. I've tried 47pf even (and 100pf) with failure.

Sticking with 50pf and going down to 100R it works still.


50pf & 270R : WORKS
anything else & 270R : FAILS

50pf & 100R : WORKS
100pf & 100R : FAILS
30pf & 100R : FAILS

[daveshah]

OK, good to know. Trying a shorter cable, if you haven't already, may also be a good idea (but keep a bit of capacitance to ground).

[CM800]

OK, good to know. Trying a shorter cable, if you haven't already, may also be a good idea (but keep a bit of capacitance to ground).

Updated my previous post with some more numbers.

Amazingly high precision of setting needed.

What has changed in your file as opposed to the 'stock' version?

[daveshah]

The only thing changed in that file is a new -p option to disable write protection. After running that file once with -p, both should have the same results.

[CM800]

The only thing changed in that file is a new -p option to disable write protection. After running that file once with -p, both should have the same results.

Okay,

It seems really inconsistent with programming times, or outright failure. Trimming the cable sounds like a good idea.

I would love to make this thing more reliable / certain.

[daveshah]

My personal setup, which has always worked reliably, has been an unmodified MPSSE cable with the pins going straight to headers on the Upduino, except for the clock where I added 20cm of extra wire. This has always worked 100% reliable for me.

[CM800]

My personal setup, which has always worked reliably, has been an unmodified MPSSE cable with the pins going straight to headers on the Upduino, except for the clock where I added 20cm of extra wire. This has always worked 100% reliable for me.

Thanks for the Info Dave,

I really appreciate your help this evening! nice to finally get these damn things running.

[daveshah]

No worries! Glad to see something working in the end

[iMo]

I programmed upduino v1 with the cheapo ft232h board (no eeprom on the board), no messing with the FT_prog, under win7 and Diamond programmer. 20cm flying leads, no capacitor needed. Worked ok.
Also have a look at the upduino v2 schematics - there is the ft232h sitting on the board, also no capacitor needed.
When messing with the capacitor, mind its capacitance matters a lot.
100pF-2200pF is way too much, imho, when adding the 100ohm in series even 50pF seems to be toooo high.
The C or RC slows down the edges (such it "delays" the signal).
The delay is approximately

Code: [Select]

t=0.7*R*C [seconds, ohms, farads]where R is a series combination of the FT232H's pin output's "resistive impedance" and the additional resistor you are adding in series. The impedance of a cmos output is typically something like 100-200ohm. Thus you may calculate the delay (and double-check by watching the oscilloscope). IMHO when a delay is really needed (as Dave is indicating) a few nanoseconds (5-10ns) would be enough (based on the above equation aprox. 20-30pF without the additional 100ohm resistor).

PS: the Diamond Programmer configures the FT232H for the MPSSE (for programming) automatically. When the FTDI VCP driver is installed, the inserting the FT232H into the USB plug configures it as the USB/UART adapter by default. In Win7 you do not need the d2xx drivers installed, VCP is enough for iCE40 programming and USB/UART.

[daveshah]

I think it is a particular issue with the MPSSE cable, and I'm not sure whether it is actually a case of a delay being needed; or rather noise being induced on the clock line and causing false pulses which any extra capacitance from a added capacitor or bit of wire filters out.

[CM800]

For sake of not opening up another thread, does anyone know any examples of RAM / Multiplier use with the icestorm?

[daveshah]

For the UltraPlus 1Mbit SPRAM, have a look at https://github.com/daveshah1/micropython-icevision/blob/master/ports/icevision/rtl/up_spram.v

For the regular 120kBit of block RAM, follow any generic verilog ram example and Yosys will infer block RAM.

For the multipliers, have a look at https://github.com/daveshah1/icestorm/blob/99857b1505fa6c651ad9cd4177d8fc68d3e3851c/examples/up5k_mac16/mac16.v

[iMo]

Forth System on Chip: SPRAM+BRAM+MUL16x16 in the icestorm (as well as in IceCube2 and Radiant):
https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB
https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB/tree/master/icestorm%20version