-
So I've been using a dev board up until now and I'm designing a standalone with a lattice ICE40HX4k.
I've found plenty of documentation about how the fpga is programmed from the eeprom, compatibility, and all that jazz. Great!
The problem is I haven't found anything on how to get the bitstream onto the eeprom. I'm guessing this is a more universal thing and I'm not googling the right thing. Mostly I just need to figure out how to wire the header as it seams diamond programmer does the heavy lifting for me.
There are some SPI looking pins on my programmer but I'm not sure if these can just be hooked up and programmed from the diamond programmer interface. I have an ispDownload cable and I am using a supported eeprom from the list. -
Ah yes, I meant to say flash, even the memory I have picked out is FLASH
So if I'm using this
http://i.ebayimg.com/images/i/111284428437-0-1/s-l1000.jpg
I should just be able to wire up sdo, sdi, and tck and be able to program the flash then?
(assuming I have vcc, gnd, wp, hold, and cs configured correctly or course) -
You could use an ICE40 dev board schematic for guidance e.g. http://www.latticesemi.com/view_document?document_id=50946
-
That's what I thought to do at first but my ICE40HX8K dev board wires them up to the FTDI chip, so I have no idea what it's doing there.
However looking at the one you posted it looks like they're just broken out to a header. So it looks like all you have to do is wire up the pins. I'll probably have to control creset_b manually.
What I can do though is break out the pins on my dev board and see if I can program the spi flash through my cable directly. I'll post back if that works. -
That's what I thought to do at first but my ICE40HX8K dev board wires them up to the FTDI chip, so I have no idea what it's doing there.
Are you sure you're not looking at a configuration EEPROM for the FTDI chip? -
No, the pins coming off the FTDI are GPIOs, the SPI flash is configured the same across lattice devices. I just don't want to have to include an FTDI chip and usb port on my pcbs to program the board. I've read through all of their programming cable documentation and I've wired up how they say to configure it and set up diamond correctly as far as I can tell. I've tried reinstalling the drivers and still nothing.
The worst part is I get no support from lattice since I'm not a big company looking to buy a bunch of parts. They have an automated email server that tells you they're not going to answer if you email their tech support address.
I've also been able to program a MACHX02 chip before just fine, so I know the programmer is good. The only reason I still feel like sticking with it is because a $7 FPGA with a PLL is a pretty good deal. But I'm getting very close to just switching over to xilinx. -
Are you using your own PCBs now or the dev board? If it's a dev board, which?
What have you connected to what exactly? -
Ok, so I'm trying to program the flash on the devboard. My devboard is a Lattice ice40HX8K breakout board.
http://www.latticesemi.com/Products/DevelopmentBoardsAndKits/iCE40HX8KBreakoutBoard.aspx
1. I broke out the CRESET_B, CDONE, and SCK pins since they aren't broken out already.
2. I did not remove the jumper resistors between these signals and the FTDI chip, I assumed this would be alright as I followed a schematic for the iceBlink dev board that has an ice40HX1K with all of the programming pins sharing the bus with the FTDI chip.
3. I am powering the board through the USB port, just no D+ and D- on the usb connection.
4. I left the jumpers for SPI configuration on and broke out the pins for TDI, TDO, and SS.
These are the connections I've made from the HW-USBN-2A
Required for ICE40
programmer <-> dev board
-------------------------------
TDI <-> flash mosi
TDO <-> flash miso
NOTE: Normally it's TDO Programmer to SDI flash but I verified that this is correct by pulling the TDO pin high and low and seeing the check ID function report 0xFF and 0x00 accordingly
(I have also swapped them around during all of my testing just to be on the safe side
)
TCK <-> sck - I've tried multiple division levels by configuring this pin with diamond
PROG <-> SS/CS pin - I also checked the PROGRAMN box in lattice Diamond
TRST <-> CRESET_B - This is set to LOW in the custom IO configuration in order to hold the FPGA in reset so it doesn't generate it's own SCK
INITN - CDONE - I checked the box in the custom IO for this pin as well
VCC - VCC - 3.3v generated by the dev board and hooked up to the programmers vref pin
GND - GND
I came to this configuration by reading through the Lattice programming cable user guide UG48 https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjs7bqxtKjVAhUqjlQKHVkWBqUQFggoMAA&url=http%3A%2F%2Fwww.latticesemi.com%2F~%2Fmedia%2FLatticeSemi%2FDocuments%2FUserManuals%2FMQ%2FProgrammingCableUsersGuide.pdf%3Fdocument_id%3D143&usg=AFQjCNEb6UEFHBtfwoe1NbPibiwHfM5rIQ
I did try a couple variations on these connections but I never got anything except Diamond reporting "CHECK_ID Failed, Expected h16, Actual hFF. Which doesn't exactly tell me what's wrong.
I suppose 1 more thing I could try is holding the FTDI chip in RESET or disconnecting the jumper resistors, but I doubt that would do it. -
Excellent - thanks for the detailed information (and yes looking at the Lattice programming cable datasheet you have TDI and TDO the correct way around).
It sounds like the most likely culprit is the FTDI chip.
According to this app note (page 9) when in suspend mode (which is what it will enter if nobody talks to it over USB), the "Pull down I/O Pins in USB Suspend" parameter will determine the state of the outputs. If enabled, the pins will be tri-stated with a weak pulldown (good), or disabled the chip will drive the outputs (bad).
The datasheet (page 75), shows that the parameter is determined by an EEPROM flag, with the default being disabled.
FTDI produce a Windows utility to check (and modify) the contents of the EEPROM, but if you have means to hold the FT2232H in suspend mode, that is an easy fix too, and this guarantees the pins will be tristated with a weak pulldown (as described in the app note linked above).
Do you have access to an oscilloscope/logic analyser, as that would help you to figure out what is happening very quickly! -
Looks like you were correct Josh, the culprit was indeed the FTDI chip. I pulled the 0 ohm resistors R1 - R6 off the dev board and it's programming just fine now with the clone cable. My connections are as follows
Required for ICE40
Remove jumper resistors to tdi chip
programmer side - board side
TDI - flash mosi (pin 3 of J6 on dev board)
TDO - flash miso (pin 2 of J6 on dev board)
TCK - sck
PROG - SS/CS pin (pin 2 of J7 on dev board)
TRST - CRESET_B
VCC - VCC
GND - GND
jumpers can stay on
TRST and PROG must be disconnected when power cycling to program fpga
TDI and TDO are labeled as what to connect to on the clone programming
cable so TDI connects to MOSI and TDO connects to MISO
INIT and TMS are not required to be connected
So my workflow will still require moving a jumper and power cycling to program the board but that's ok with me. Thanks for doing the digging on that Josh.