Custom Lattice MachXO2 1200HC Board

[iMo]

Who is asking you to provide a PID/VID??
Diamond has asked? I doubt..
Take a cheapo FT232H board (no EEPROM on it, no EEPROM programming needed) and simply use it.

[soFPG]

Who is asking you to provide a PID/VID??

https://www.eevblog.com/forum/microcontrollers/custom-lattice-machxo2-1200hc-board/msg1448869/#msg1448869

you might need to reprogram the PID/VID

Take a cheapo FT232H board (no EEPROM on it, no EEPROM programming needed)

I have one! And it doesn't work!

and simply use it.

What do you want me to do?

I attached a picture of the PCB in its current form. I don't see any short circuits whatsoever.

[iMo]

You do not need to reprogram pid/vid. The ft232h is connected and properly recognized by the diamond programmer.
What about your jtagen? Is your jtag enabled?

[soFPG]

What about your jtagen? Is your jtag enabled?

There is the pull-up which pulls JTAGENB high. How can I check if JTAG is enabled? I don't even get to speak to the FPGA how could it tell me if JTAG is working.

[iMo]

Is your wiring like this?

Code: [Select]

FT232H PROGRAMMER             YOUR_BOARD
==========================================
ADBUS0 - TCK ------------------- TCK
ADBUS1 - TDI ------------------- TDI
ADBUS2 - TDO ------------------- TDO
ADBUS3 - TMS ------------------- TMS

         GND ------------------- GND
                                 +3.3V (Mach)
.
At least you have to see in the Diamond Programmer (I cannot go further on as I do not have Mach handy):

PS: the 220ohm resistors with your LEDs - I would recommend higher values, ie. 1kohm..

[soFPG]

Is your wiring like this?

Yes, exactly like that.

PS: the 220ohm resistors with your LEDs - I would recommend higher values, ie. 1kohm..

Why?

At least you have to see in the Diamond Programmer (I cannot go further on as I do not have Mach handy)

I do see that.

[iMo]

Why?

To save planet's energy resources
PS: also mind the sink/source current capabilities of an output pin may differ..

[soFPG]

Do I have to do any of the things described at page page 3 http://www.latticesemi.com/en/Support/AnswerDatabase/2/5/9/~/media/BE8110AA25534DD89AC3A70A13D09F91.ashx ?

I don't do anything with PROGRAMN and DONE pins. I am also not sure if the MachXO2 has an INITN pin...

I just removed the pullup on JTAGENB - didn't help anything. I am wondering what I am doing wrong - I just copied the TinyFPGA A2 PCB and that one seems to work otherwise it would not been sold.

After Lattice Diamond prints the error message to its console, the LED I marked in the picture turns on and stays on. I don't know what that means though.

[SiliconWizard]

Have you looked at the TCK signal on an oscilloscope (while Diamond is trying to identify the FPGA)?

As I said, FT232H chips are not explicitely supported by FTDI's FTCJTAG library, which Lattice most likely uses. Some people claim to have used an FT232H with success for this, I have never tried. But wouldn't be surprised if there were various potential issues. I've taken a quick look at the FTCJTAG source code, and can tell you that the FT232H is indeed NOT explicitely handled. What really happens though when using one would take quite some time to figure out from the source code.

To rule this problem out, you should really try an FT2232H breakout board with your design and see what you get.

If some people here have tried and are certain an FT232H works with Lattice tools, it may also be that your CJMCU_FT232H board doesn't contain a genuine FTDI part. Most of those boards seem to be chinese clones sold at prices barely higher than the FT232H itself and I wouldn't be extremely surprised if some of them weren't genuine.

[iMo]

I've got the same FT232H board.
Recap based on your outputs:
1. the FT232H board has been recognized and connected to the Diamond Programmer
2. the message

Device#1 LCMXO2-1200HC: Failed to verify the ID
(Expected: 0x012BA043 Read: 0xFFFFFFFF).

means the jtag has read FFs off the Mach chip (the ID is the Mach's ID)
3. that may lead to following issues:
a. wrong wiring (jtag and gnd) from FT to Mach, DO NOT USE LONG CABLEs, max 15cm
b. Mach is not powered properly (check voltages, gnds, capacitors, shorts, bad contacts, and qfn soldering)
c. Mach is not configured for jtag (even the technical note says the vanilla chip is jtag ready)
- here double check the settings in Diamond IDE (not in Diamond Programmer), ie programn, ispEN signal, etc.
- the tech note mentions a signal "ispEN" which "can be used" for setting the JTAGENB pin such it actually enables jtag programming - it could be you may need to wire the JTAGENB with a pin on the FT (AD4-AD7), or, disable the ispEN usage in Diamond IDE/Programmer (I have not found the ispEN setting in the Diamond Programmer). The JTAGENB must be pulled to a specific signal level to enable jtag (double check whether it is L or H).

Lattice parallel port or USB download cables provide an output called ispEN. The ispEN signal can be attached to the JTAGENB input to control the availability of the JTAG port.

- as daveshah has indicated above a small capacitor might be needed at the TCK signal
4. You may check the FT board functionality simply by using it as an USB_Serial dongle - the AD0 and AD1 are used as TX/RX, and it works fine.

PS: here you may see how your FT232H board works with the lattice analyzer over JTAG:
https://www.eevblog.com/forum/microcontrollers/lattice-radiant-for-ice40up-fpga-series/msg1446562/#msg1446562

It also works with DiamProg with ice40 chips. The popular UPduino v2 has got the FT232H directly on pcb, and it works (I am a happy user).
https://www.eevblog.com/forum/microcontrollers/8$-ice40-developer-board/msg1416081/#msg1416081

And while the UPduinos are supported directly by Lattice http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/GnarlyGreyUPDuinoBoard.aspx
the FT232H is supported as well

[SiliconWizard]

Regarding the Upduino 2 (I've ordered one a few days ago), the FT232H is using SPI and not JTAG as far as I have seen.

Anyway, soFPG should really take a look at the TCK signal on a scope to confirm that his FT232H at least seems to be working properly in JTAG mode.

[soFPG]

Have you looked at the TCK signal on an oscilloscope (while Diamond is trying to identify the FPGA)?

Indeed I have - it looks like this (attached)

To rule this problem out, you should really try an FT2232H breakout board with your design and see what you get.

So something like this one? https://www.aliexpress.com/item/FT2232HL-development-board-learning-board-FT2232H-MINI-FT4232H-UM232H-development-board/32584795803.html?spm=2114.search0104.3.53.2fa5566burkYjT&ws_ab_test=searchweb0_0,searchweb201602_5_10320_10152_10321_10065_10709_10151_5711320_10344_10068_10342_10547_10343_10322_10340_10341_10548_10193_10697_10194_10696_10084_5722520_10083_10618_10304_10307_10710_10302_5711220_10180_5722620_5722920_10059_10184_308_5722720_5722820_100031_10319_10103_441_10624_10623_10622_10186_10621_10620,searchweb201603_25,ppcSwitch_5&algo_expid=92bcd60f-d81d-44c6-a9d9-9f5a5a795bce-8&algo_pvid=92bcd60f-d81d-44c6-a9d9-9f5a5a795bce&priceBeautifyAB=0

wrong wiring (jtag and gnd) from FT to Mach

I checked those. I also attached a screenshot from this CSV file: http://www.latticesemi.com/view_document?document_id=51687
JTAG pins are: 1, 29, 30, 32 - exactly the same in my schematic

You may check the FT board functionality simply by using it as an USB_Serial dongle - the AD0 and AD1 are used as TX/RX, and it works fine.

It does work - I already used it for that purpose.

I also followed this video: https://youtu.be/SmdEP_ZsBgM?t=20m24s which is very straightforward - he didn't set up anything at all besides detecting the jtag device and flashing the previously synthesized .jed - file.

The JTAGENB must be pulled to a specific signal level to enable jtag (double check whether it is L or H).

I read somewhere that it needs to be pulled high - I have that resistor in my schematic but seems to have no effect (doesn't matter if it is soldered or not).

[SiliconWizard]

From your capture, the JTAG mode seems to be working. I wouldn't know whether it's correctly working though. The TCK signal seems to be stretched in weird ways. It may be normal but we can see that there are parts where TCK is clocked at much higher speeds. Might be interesting to zoom in on those parts.

Anyway. TDO is stuck at '1'. There may be various reasons why, including an incorrect data stream sent to the FPGA, which then wouldn't recognize the JTAG commands.
Of course, another trivial reason would be that it's not on the right pin of the FPGA (but apparently you double-checked), or that TDO is shorted to another pin or to Vdd.

[soFPG]

I zoomed into the part where TCK is clocking at a higher speed.

Of course, another trivial reason would be that it's not on the right pin of the FPGA (but apparently you double-checked), or that TDO is shorted to another pin or to Vdd.

This is just what comes out of the FT232H, I didn't capture if the FPGA actually sends something back (but I doubt).

or that TDO is shorted to another pin or to Vdd.

I thought I checked every pin correctly - but it looks like TCK is shorted to 3.3V (but also to the TCK pin). I don't know why that is though. There is a adjacent via connecting to 3.3V (and also a 3.3V pin). I guess I will re-heat my board...

Edit: TCK is not even connected to GND as it should be (by a pulldown). 
What the heck

[SiliconWizard]

Of course, another trivial reason would be that it's not on the right pin of the FPGA (but apparently you double-checked), or that TDO is shorted to another pin or to Vdd.

This is just what comes out of the FT232H, I didn't capture if the FPGA actually sends something back (but I doubt).

Well, the short may be on the FT232H board itself.

[ale500]

Here some captures of a FT2232H talking to a MachXO2-7000ZE (The MachXO2 breackout board). P1 is the start of the transacktion with a very slow TCK, P2 is zooming onto that lat peak on the right of P1 and P3 is when it sees some transitions on TDO. I used as trigger "detect 2 rising flanks of TDO", my logic analyzer has only 2048 points of memory (2048 transitions) only.

[soFPG]

I just tried to resolder the QFN-32 FPGA but as soon as a solder it with my hotairgun I get short circuits
No matter how much flux I use it always ends in a short circuit 
Cuild this be due to decoupling capacitors?
Another problem is that soldering the FPGA once the printed text on top gets almost unreadable - after soldering two or more times I can't read anything. Bad quality I would say.
I soldered QFN-24 once before and it worked on the first try.

[SiliconWizard]

I hate QFNs.

Did you try sucking out solder with a solder wick all around your QFN package?

[soFPG]

Did you try sucking out solder with a solder wick all around your QFN package?

Not yet because if I take a look at the solder pads (without FPGA on it) there is no short-circuit at all.

But shouldn't be a short-circuit a "normal" case because of the decoupling capacitors (which basically connect GND and Vcc)? If they are charged there should be a current flow, shouldn't it? I am not an electrical engineering student so I possibly get this wrong.

[ale500]

I feel your pain soldering those QFN packages . I bought some QFN-48 packaged iCE chips . In the end I decided to get some gnarlygrey's UPDUinos and be done with it. Not perfect but a workable solution. And TQFP-packaged MachXO2's.

What I saw is that people use aluminum foil to protect the components around the work zone, you cut a part the size of the QFN package so you don't blow hot air over the nearby components.

[soFPG]

So it is out of the ordinary that capacitors produce a short circuit signal with a continuity tester?
Therefore this means the short circuit comes from unintentionally connected solder?

[iMo]

Do not panic. The issues you encounter are normal. Even the experts mess with such issues frequently..
All will work when you clean up the board's issues.. 

QFNs are easier to solder than the 0.5mm flatpacks or BGAs, imho.

You must apply a LOT of solder flux (the peach jam like stuff) otherwise you get shorts (the board must be over-flooded by the flux). The chip must swim in the flux when hot-air soldered.
I do not know whether your package has got thermal pad from the bottom, if yes then do NOT put a lot of tin on the thermal pad otherwise the pins will not reach the pads. Use a SMALL drop of tin there (like a 1mm diameter ball of tin).

Capacitors - large multi-layers ceramics capacitors may show "short" for a fraction of a second (as the capacitor is charging itself during the measurement) but after that you must measure >10MegaOhm. Better switch your multi-meter into Ohms and measure the resistance.

With QFNs, after they are soldered in, you may resolder the pins at the four edges with a thin solder tip and a LOT of flux. The chip will not desolder itself and you remove the shorts. Also I use a copper wick to remove shorts off the adjacent pins at the qfn's sides.

The markings on the package - you must to remove the flux with isopropyl or similar stuff. The markings are laser engraved into the epoxy package, when they are full of flux they disappear.

I always solder qfn or bga as the first device on the pcb, then I do measure with the ohmmeter resistance between the tracks (all reasonable combinations) to test such everything is ok.
When you read between the tracks:
~0 ohm - there is a short somewhere
~kiloohms - the tracks are connected to the chip
>10Mohm - no connection.

PS: when watching the photo of your pcb above - you use a lot of tin there (capacitors/resistors). 1/10th of that amount would be ok.

Hint: first apply a SMALL amount of tin on the 1st pad. Use a lot of flux. Then put the smd capacitor/resistor on the place. Still a lot of flux there (the component must swim in the flux). With the clean tip do solder the 1st pad. With a SMALL amount of tin on the tip and still LOT of flux there do solder the 2nd pad. Do it fast such the component does not jump off the place. With enough flux and the right tip temperature it takes a fraction of a second.

From the form of the tin blobs it seems you do not use enough solder flux - the components must swim in the flux. From the surface of the blobs I can read - the temperature of your tip is too high.
This is how it should look like (hand soldered) after cleaning the board off the flux (do use an isopropyl alcohol bath and girl/boy_friend's toothbrush):

[soFPG]

Is it possible that the plane underneath the FPGA isn't connected to GND but to Vcc?
I tried a fresh, new board from OSH-Park and I still get short circuits no matter what I do.

[iMo]

GND – Ground. Dedicated pins. It is recommended that all GNDs are tied together.
For QFN 48 package, the exposed die pad is the device ground

BTW, is the routing picture above the actual one for the pcb you've got from Opark?
I see there several tracks from A to B, where the A and B are connected to GND.. The track is surrounded by GND..
Is that ok?
It must not be an problem provided A and B shall be GND (it seems your CAD messed something), however..
Perhaps you've got 3 pcbs, - try to measure the 3rd pcb - the pad's vs. GND/VCC - with an ohmmeter before you solder something on it.

[soFPG]

I see there several tracks from A to B, where the A and B are connected to GND.. The track is surrounded by GND..

Could you please mark the positions you are referring to on the PCB?

Edit: Is the tinyFPGA A2 PCB available on Osh-Park? Are the Gerber-Files available?

Oh yeah, they are: https://oshpark.com/shared_projects/2xu90fiY

The GND plane of the FPGA looks a lot smaller than mine - that could be a potential problem.