Custom Lattice MachXO2 1200HC Board

[soFPG]

Hi,

I would like to re-create this A2-Board (https://www.cnx-software.com/2017/07/24/tinyfpga-is-a-breakout-board-for-lattice-semi-machxo2-fpga/) for the MachXO2 1200HC FPGA with a few extras.
One of my questions is, why the creator of the A2-Board didn't use a pull-up resistor for the JTAGENB pin? The MachXO2 Programming and Configuration Usage Guide (http://www.latticesemi.com/view_document?document_id=39085) on page 19 tells that there should be a pull-up resistor to enable the JTAG interface.

In the pages before the pin PROGRAMMN and INIT were mentioned but as it seems they don't play any role in respect to JTAG programming functionality because the A2-Board doesn't use them (here is the schematic: https://github.com/tinyfpga/TinyFPGA-A-Series/blob/master/board/TinyFPGA-A.pdf).

I am also wondering if such an amount of capacitors is necessary?

[iMo]

why the creator of the A2-Board didn't use a pull-up resistor for the JTAGENB pin?

Because the A2 board shall operate with JTAG disabled as the default mode (thus the JTAG pins are used as standard IOs).

I am also wondering if such an amount of capacitors is necessary?

The A2 board is well designed as the decoupling and routing is concerned. I would stay with the ferrite bead and all capacitors. Also do not fragment the solid bottom ground plane too much..

Capacitors and decoupling [Edited]:
==========================
1. a single capacitor cannot cover entire freq spectra!
The best practice is to use 3 capacitors in parallel, ie. 1nF || 100nF || 10uF, mind the 1:100 ratio (it is rarely done that way)

2. the 3 caps shall be placed such the 1nF is the closest to the Vcc pin, then 100nF, then 10uF

3. a good practice is to use 2 vias at the GND side of each decoupling capacitor (ie. when GND plane is at the bottom pcb side).

[soFPG]

Because the A2 board shall operate with JTAG disabled as the default mode (thus the JTAG pins are used as standard IOs).

So if I only want to use JTAG for programming it would be good advice to use this pull-up resistor on JTAGENB?

I am wondering if this Jtag programmer from china: https://www.ebay.com/itm/USB-Download-Cable-Jtag-SPI-Programmer-for-LATTICE-FPGA-CPLD-1000-2000-4000/301286854526 would do the job?

Am I right that TRST, INIT and PROG aren't used? Are the two GND pins and the one VCC pin inputs (e.g. I have to supply power) or outputs (power is supplied by those pins)?

The best practice is to use 3 capacitors in parallel, ie. 1n||100n||10u, mind the 1:100 ratio (it is rarely done that way)

Okay, then I do it that way.

This is my schematic at the moment, is there anything (horribly) wrong?

[ThomasDK]

The best practice is to use 3 capacitors in parallel, ie. 1n||100n||10u, mind the 1:100 ratio (it is rarely done that way)

Okay, then I do it that way.

This is my schematic at the moment, is there anything (horribly) wrong?

You missed the point:
Three capacitors per VCC pin! That is why it is rarely done that way, even though it is best practice.

An often used approach is to share the bigger capacitors between multiple pins.
For example 1x10uF per 4 pins, 1x100nF per 2 pins and 1n on every pin.

[iMo]

Exactly, look at the A2 board, there are maybe 6 Vcc pins decoupled with 1 or 2 caps, each Vcc/Vccio pin decoupled separately.

You may not use 3 caps per Vcc pin, I would copy the A2 (copy it 1:1 and add the 3.3volt regulator as in your schematics with the cap at its input). There is a ferrite bead in A2 as well.

You may place the pads for the JTAGENB resistor, you may not populate it when not required.

Btw: the 3 caps shall be placed such the 1n is the closest to the Vcc pin, then 100n, then 10u

PS: I did a similar DIL32 iCE40LP384 board in past, and I put 22ohm resistors in each signal line (to suppress the excessive ringing with longer cables). I would not do it again (a lot of work with soldering them in)..

Programming: the cheapo FT232H boards work with Diamond/Radiant usually, but I cannot guarantee the Mach likes them too

[soFPG]

Thanks a lot for your answers!

Programming: the cheapo FT232H boards work with Diamond/Radiant usually, but I cannot guarantee the Mach likes them too

I guess that the FT232H utilizes SPI/I²C to program the chip. The Programming and Configuration Usage Guide on page 6 claims that only JTAG offers full memory space accessibility so I would rather stick with the jtag tool.

Are FPGAs generally more sensitive in regards to capacitors? I never used 1nF caps for my µC boards and they work fine, but they all have only one VCC pin.

You may place the pads for the JTAGENB resistor, you may not populate it when not required.

Good idea, thanks!

There is a ferrite bead in A2 as well.

Okay, ahm, why do I need this? Wikipedia tells me that it is used to suppress high frequency noise but where would that noise come from?

I am sorry I don't have a lot of experience in PCB design and I don't have an electronics background but I like to design and create things myself. A few years ago I started with software development and now I want to learn more about the actual hardware.

[daveshah]

An FT232H can program a MachXO2 using JTAG too, you might need to reprogram the PID/VID, but I've always got by fine with a FTDI MPSSE cable for MachXO2 and iCE40 programming. The only gotcha is a slight timing issue I've sometimes noticed, solvable by adding a small capacitor (circa 18 or 22pF, whatever you have around) from TCK to ground.

[soFPG]

So something like this (https://www.ebay.com/itm/High-speed-CJMCU-FT232H-Multifunction-USB-to-JTAG-UART-FIFO-SPI-I2C-module/162736978843) would be appropriate? How do I re-program this chip and how would I know which pins of the ftdi-board are used for jtag?

[mikeselectricstuff]

The jtagen pin needs to be explicitly enabled in the config, to allow the jtag pins to be used as i/o, so if the jtag pins are dedicated to jtag, that pin isn't used.

[soFPG]

so if the jtag pins are dedicated to jtag, that pin isn't used.

But wouldn't the jtagen-pin allow the use of the jtag-pins as jtag-pins (and not standard I/O) by a pull-up in the first place?

[iMo]

So something like this ... would be appropriate? How do I re-program this chip and how would I know which pins of the ftdi-board are used for jtag?

That board works as a programmer under Diamond programmer with iCE40xx (SPI mode), and with the Reveal Analyzer under Radiant (JTAG). Haven't tried with Mach under Diamond but 99.9% it will work - the Diamond programmer does recognize it. The programming software sets the mode as required.

The JTAG pins are AD0-AD3 on that board, there is the datasheet from FTDI describing all the modes and pin mappings for the particular mode. Most probably there will be the JTAGENB related signal used as well, it could be one from the AD4-AD7.

PS: that board works as Serial/USB converter as well. The pins AD0 and AD1 are used. WinXX installs the driver for you automatically and you get a COMxx port available.

[mikeselectricstuff]

so if the jtag pins are dedicated to jtag, that pin isn't used.

But wouldn't the jtagen-pin allow the use of the jtag-pins as jtag-pins (and not standard I/O) by a pull-up in the first place?

It's a configuration setting in the flash. In the default factory state, JTAG pins are always JTAG and JTAGEN has no effect.
If you then enable JTAGEN in the configuration data, the JTAGEN pin muxes the JTAG pins between JTAG and I/O

[iMo]

Okay, ahm, why do I need this? Wikipedia tells me that it is used to suppress high frequency noise but where would that noise come from?

The noise comes from the Mach FPGA. The ferrite bead suppresses EMI which may spread out (off the Vcc power rail).
Also it suppresses the noise coming into your board from your power supply or other modules/boards..
The FPGAs are pretty fast devices creating EMI up to GHz.

PS: do not use "inductor" rated in uHenrys. Use "ferrite bead" rated in ohms (30-50ohm is ok). In ohms as it indicates a broadband impedance.

[soFPG]

Is this good enough?

I am wondering how the designer of the A1 board did the pcb layout, especially at that size. Seems almost impossible to me to do it as clean as he did.

[iMo]

The ferrite bead is not wired properly.
You have to create ie. "3.3E" (External- wired to your pin headers) and the internal "3.3V".
The FB has to be wired in between. See an example below..

PS: why the 5V at the JTAG header? The Mach is 3.3V io chip..

[soFPG]

You have to create ie. "3.3E" (External- wired to your pin headers) and the internal "3.3V".

I use external 5.0V, those will be converted to 3.3V by the voltage regulator.

why the 5V at the JTAG header? The Mach is 3.3V io chip..

I would like to have the JTAG connector and the 5.0V and GND input in the same place later on my PCB layout.

Like this:

[iMo]

You have to create ie. "3.3E" (External- wired to your pin headers) and the internal "3.3V".

I use external 5.0V, those will be converted to 3.3V by the voltage regulator.

Have a look at the schematics with 3.3E and 3.3V above.
We talk about the 3.3V rail which has to be split into 3.3E and 3.3V (and FB in between).

[soFPG]

Oh, okay my bad, I missunderstood.

So the ferrite bead suppresses high frequency noise from the voltage regulator?

[iMo]

The FB helps with suppressing the HF noise:
1. from Mach to 3.3E pin headers (and to following external circuitry)
2. from 3.3E pin headers to Mach (from the external circuitry).
Mind there are 3.3V and 3.3E rails in my schematics above.

[soFPG]

Today all parts came together (FPGA, Board, resistors etc.), so I soldered the board.

You may blame me for not using a ferrite bead but I consulted a person with phd in electrical engineering and it seems ferrite beads are mostly used to keep high frequency radiation low to pass specific test, not to keep the device functional.

Yeah, but somehow my board isn't working

Instead of 4.7kOhms I had to use 2.7kOhms I had lying around because the chinese seller delivered 100Ohm instead of the ordered 4.7k, but I think that won't make a significant difference? 

I downloaded Lattice Diamond, created a short VHDL file which just turns Pin 17 on, flashed my FT232H to a Lattice USB JTAG device (which gets recognized by Lattice Diamond):

Code: [Select]

INFO - Cable Auto Detection Activated.

INFO - No Lattice HW-DLN-3C (parallel) cable detected.

INFO - No Lattice HW-USBN-2A cable detected.

INFO - Board with FTDI USB Host Chip detected.

INFO - Detected HW-USBN-2B (FTDI) cable at port FTUSB-0.

but if I try to upload the code to the FPGA I get this error message:

Code: [Select]

Starting: "pgr_project save "D:/Programme/Lattice Diamond/Projects/Proj1/impl1/impl1.xcf""

Starting: "pgr_program run"

INFO - Check configuration setup: Start.

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

ERROR - Check configuration setup: Unsuccessful.

ERROR: pgr_program failed.

ERROR - Programming failed.

I use pins ADBUS0 - ADBUS3 (TCK, TDI, TDO, TMS) from FT232H. I also attached the config file.

I attached my schematic and routing. Could this really not be working just because of a missing ferrite bead?


Edit: I just took a look in the FT232H data sheet (Page 9 : http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf). The template file for the Lattice Programmer uses 245 FIFO-Mode instead of Serial RS232.
Which pins are responsible for JTAG in this mode? Instead of TCK/TDI etc. they are now called D0, D1, ..., RXF, TXE,RD. Which do I have to use?

[SiliconWizard]

I still don't know why you put 5V on the jtag connector. (It could be unsafe if you ever use this voltage pin to get the voltage reference for a standard JTAG adapter.)

As others have said, pulling up JTAGENB is optional if you don't intend to use this functionality (JTAG disable, which must be programmed).

Also, your FTDI programming file (XML) specifies a VID of 6010 and a port B - this file is just for a FT2232H and not a FT232H! You have managed to fool Lattice Diamond which "detects" it, but fooling FTDI's own libraries will be a little more difficult.

The correct VID for the FT232H is 6014 and it only has port A. The FT232H does support JTAG *but* the FTDI JTAG library only seems to support FT2232H and FT4232H chips - not the FT232H, and most likely, Lattice has used FTDI's library (which seems confirmed by the presence of the file 'ftcjtag.dll' among Lattice executables). (See: http://www.ftdichip.com/Support/SoftwareExamples/MPSSE/FTCJTAG.htm )

So if you're not using an FT2232H, you may be out of luck. I have an FT2232H-based adapter and it does work. Never tried with an FT232H. But I suspect it won't work.
Since FTDI provides the source code for the FTCJTAG library, you may be able to modify it to be able to support the FT232H, rebuild the DLL and replace the original one. Good luck!
(Buying an FT2232H module will certainly be much less hassle.)

[iMo]

The fact the device ID has not been recognized does not necessarily mean the FT232H cannot program it.
I use the FT232H with Diamond Programer in SPI mode for iCE stuff and with Radiant Analyzer in JTAG mode.
The FT232H is properly detected

Code: [Select]

INFO - Detected HW-USBN-2B (FTDI) cable at port FTUSB-0.now you have to learn how to connect it to your board. There could be a dozen of reasons it does not work straight with your new board.
This indicates wiring issues:

Code: [Select]

(Expected: 0x012BA043 Read: 0xFFFFFFFF)Double check the wiring and read the tutorials. The Mach02 is using JTAG for programming so it will work.
I would definitely not start to mess with USB vids and xml config files 
Here is the FT232H wiring for the jtag (from the FT232H datasheet):

 

[soFPG]

I still don't know why you put 5V on the jtag connector. (It could be unsafe if you ever use this voltage pin to get the voltage reference for a standard JTAG adapter.)

This is not part of the JTAG-connector. I use loose wires for connection. The 5V and GND pins are powering the whole board.

As others have said, pulling up JTAGENB is optional if you don't intend to use this functionality (JTAG disable, which must be programmed).

But as far as I understand, the Mach XO2 is programmed via JTAG - so how would disabling JTAG functionality be beneficial?

Also, your FTDI programming file (XML) specifies a VID of 6010 and a port B - this file is just for a FT2232H and not a FT232H!

But as you can also see - it defines a Port A as well! Maybe I have to remove Port B to get it working...I think only one port is needed? FT232H has one MPSSE unit, FT2232H has two (as far as I know).

Double check the wiring

What I did:

ADBUS0 - TCK
ADBUS1 - TDI
ADBUS2 - TDO
ADBUS3 - TMS

I don't know why they are called D0-D7 in 245 FIFO-Mode though.

in JTAG mode with radiant analyzer.

So it should work with MachXO2 FPGAs and Diamond as well?

I would definitely not start to mess with USB vids and xml config files

What do you mean? Without any E²PROM flashing Lattice Diamond didn't recognize the FTDI chip as a valid programming tool. So I guess that procedure was mandatory.

[iMo]

Without any E²PROM flashing Lattice Diamond didn't recognize the FTDI chip as a valid programming tool.

Never heard about.. That procedure is definately not mandatory. Take the FT232H and use it. That is all. Diamond has recognized it as channel 0 of the FT2232.
Read above post from daveshah.
PS: I've attached above the table with FT232H jtag wiring..

[soFPG]

Read above post from daveshah.

So which PID/VID should I use? 

PS: I've attached above the table with FT232H jtag wiring..

Thanks for your help - I connected the pins as I wrote in my last post.

Edit: I just completely erased the EEPROM of my FT232H and Lattice Diamond still detects a "HW-USBN-2B (FTDI)" cable at port "FTUSB-0"  (But still same error message)

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

[iMo]

Black circles.
It is not a problem electrically (it is actually as you did fragment the GND plane - not good for fast circuits).
Your router did not include the tracks into the GND plane, only the A and B vias and the track will act as an antenna.
Most probably you forgot to name the vias 'GND'..
If you do then all the excessive tracks will disappear (will be included into the GND plane) and you get a nice not fragmented GND plane..

[iMo]

When the vias were called 'GND' then the vias would be incorporated into the GND plane like this:

[iMo]

Back to the major issue:

I tried a fresh, new board from OSH-Park and I still get short circuits no matter what I do.

Where you see the shorts?

[soFPG]

I don't see any shorts I just measure them with my continuity tester between 3V3 and GND (only FPGA soldered to the board - no caps or resistors).
Maybe my pinname assignment is wrong (I created the MachXO2-footprint myself) - but I think I also double checked that.

[David Chamberlain]

Perhaps you routed the grounds as traces first and then added the ground fills. Just delete those ground traces and drop vias to the ground plane from each topside ground pad then refill the fill.

Does your router have a Design Rule Checker? It will find shorts and other issues.

[iMo]

Maybe my pinname assignment is wrong

Double check that again, and also double check your chip has been positioned properly during soldering (because I miss the usual PIN1 silk mark on the PCB).

[soFPG]

Does your router have a Design Rule Checker? It will find shorts and other issues.

It has - no shorts only silk-screen issues (I don't think they add anything to this problem).

(because I miss the usual PIN1 silk mark on the PCB).

It somehow is directly placed on a via - that's probably the reason why it is missing on the actual PCB from OSH-Park.

Perhaps you routed the grounds as traces first and then added the ground fills. Just delete those ground traces and drop vias to the ground plane from each topside ground pad then refill the fill.

I actually created the GND plane first but a few pieces didn't get any GND connection so I had to create traces / vias to get them connected to the plane. So you say the badly designed GND could be a potential problem?

and also double check your chip has been positioned properly during soldering

I also did that.

[iMo]

So you say the badly designed GND could be a potential problem?

For the purposes of checking the JTAG programming and running a blinking LED alike demos, not a problem.
The UPduino v1 does not have any GND plane/fill and it works.

For purposes of a mass production of your board I would highly recommend to fix it.

Still the Q is what are the other issues with your JTAG signals integrity..

a) are the JTAG signals routed at the Mach's JTAG pins properly?
b) are there correct voltages at the Vxx pins?
c) are all gnds routed at respective pins?
d) what is the board's current consumption (no clock applied) in the 5V rail?

[soFPG]

The short-circuit signal does not come from my soldering but from the FPGA. I checked VCC and GND inputs (QFN-Pads) and they are somehow connected (continuity tester is beeping).

a) are the JTAG signals routed at the Mach's JTAG pins properly?

I think so. I attached a picture of pin to signal name mapping and they are equal to mine. Because I testet the QFN pads directly and VCC and GND pins matched up with my schematic I guess my pin mapping is correct.

b) are there correct voltages at the Vxx pins?

Yes

c) are all gnds routed at respective pins?

Yes

d) what is the board's current consumption (no clock applied) in the 5V rail?

How do I check that?

[iMo]

As I wrote above do NOT use the continuity tester but the OHMmeter. The 'ohm' values are important in understanding the issues..

Vcc and GND is of course connected inside the FPGA. There are ESD protection diodes at each pin (2-4pieces/pin) connected with anodes to GND (lower side diode) and with cathodes to Vcc (higher side diode).

[soFPG]

As I wrote above do NOT use the continuity tester but the OHMmeter. The 'ohm' values are important in understanding the issues..

Oh, okay. There is just a single '1' if I connect GND and 3V3 - I guess that means infinity?

[iMo]

Test your ohmmeter - shorting the leads - 0.000ohm, 4k7 resistor - 4700 or 4.700, open leads "0.L" or "0L", or "1", for example.

[soFPG]

The 220Ohm resistors for LEDs are measured correctly as well as shorting resistance. But the TCK pulldown is only 60Ohm even though it is a 2.7kOhm resistor (2701 marking)

[iMo]

    d) what is the board's current consumption (no clock applied) in the 5V rail?
How do I check that?

+5V_power------> +Ampermeter Ampermeter- ----> +5V_board board_GND -----> GND_power

When measuring Ampers always start from the highest range. After the measurement always switch to Voltmeter (otherwise you may blow the protection fuse inside).

[soFPG]

d) what is the board's current consumption (no clock applied) in the 5V rail?

9.34 mA

[iMo]

That is much more I would expect. Does an LED lite ON when powered?
What is your voltage regulator type?
Hopefully you do not apply +5V directly on the chip's Vcc (you must have voltage regulator from 5V to 3.3V wired in).

PS: according to the datasheet the static current of your chip is 3.5mA.
That would mean the voltage regulator's current is ~5.8mA (provided the LED does not lite).

[iMo]

In 2013 Lattice indicated an intention to include FT232H into DProgrammer (re MachX02)
https://www.mikrocontroller.net/topic/300043#3236988
As I wrote JTAG over the FT232H works here with Radiant Analyzer (a part of Radiant IDE for iCE40UP).
Radiant is a 2018 product.
The other discussions I've seen indicate the flashing the eeprom with FTxxxx settings does not help with 232H either. Could you check whether your Mach IDE includes the Analyser?

PS: while digging in the Lattice's knowledge base I've found following hints:

... You can try to increase TCK pulse width through programmer, you can change this value from 1-30 in Diamond programmer at RHS of Diamond Programmer 3.8 from "TCK Divider Setting (0-30X)" settings.

h) Have you provided proper pull-up and pull-down on JTAG pins?
- The TCK of the JTAG port must be pulled down using an external 4.7K resistor and the TDI/TDO/TMS must be pulled HIGH...

You may try to add the 3x 1k-3k3 pull-ups at those TDI/TDO/TMS.

Finally I've found the JTAG and ispEN, PROGRAMN, TRST, TCK clock, etc. settings in the Diamond Programmer -> Download Debugger - Cable and I/O Port Setup (or Options too)

[soFPG]

Does an LED lite ON when powered?

No, I don't use a power LED even though it would be nice to have one, but I forgot to implement it.

What is your voltage regulator type?

HT7133 (https://img.ozdisan.com/ETicaret_Dosya/354460_2643812.pdf)

That would mean the voltage regulator's current is ~5.8mA

The datasheet I linked above does mention power consumption, but it is max. 5µA, so basically 1000 times lower.

As I wrote JTAG over the FT232H works here with Radiant Analyzer (a part of Radiant IDE for iCE40UP).
Radiant is a 2018 product.
The other discussions I've seen indicate the flashing the eeprom with FTxxxx settings does not help with 232H either. Could you check whether your Mach IDE includes the Analyser?

I don't think that the FT232H is the problem - it is properly recognized by the IDE and it produces a JTAG signal.

Lattice Radiant only supports iCE40 Ultra plus (http://www.latticesemi.com/latticeradiant). Also Lattice Radiant and Lattice Diamond are two separate products - I don't think one of it is integrated in the other one.

The Diamond Help file is talking about a "Reveal Analyzer" to trace signal data from the FPGA. I don't see a Radiant Analyzer in the Tool-Section.

You can try to increase TCK pulse width through programmer, you can change this value from 1-30 in Diamond programmer at RHS of Diamond Programmer 3.8 from "TCK Divider Setting (0-30X)" settings.

I already tried that option - didn't help.

The TCK of the JTAG port must be pulled down using an external 4.7K resistor

I use an 2.7K resistor but that shouldn't matter too much (I guess)?

TDI/TDO/TMS must be pulled HIGH

They don't say that this should be done with an external resistor so I guess this is part of the JTAG device?

Finally I've found the JTAG settings in the Diamond Programmer -> Download Debugger - Cable and I/O Port Setup (or Options too)

Are you referring to this menu?

Edit: Yes, you are.

[iMo]

Quote

    What is your voltage regulator type?

HT7133 (https://img.ozdisan.com/ETicaret_Dosya/354460_2643812.pdf)

Quote

    That would mean the voltage regulator's current is ~5.8mA

The datasheet I linked above does mention power consumption, but it is max. 5µA, so basically 1000 times lower.

Hmm, while reading the datasheet it is 30mA reg only (no info on abs max current). The 5uA is for no load. Your load is at least 3.5mA. But still it must be much less than 5.8mA.
What could be an issue is the 30mA output current only. It is not much, frankly. The UPduino is a low power iCE40UP and it uses LM1117 800mA regs. There are transients at the power-up (in-rush currents into capacitors, etc)) thus the proper power-up sequence of the fpga could be in danger..

When you lit ON your three LEDS it is + 15mA.
When the fpga will run at 100MHz it is + 30mA easily
In total 9.3+15+30mA.

Programming current is 22mA.

[soFPG]

I also have an AMS1117 here but unfortunately the Vin and Vout pins are reversed

http://www.advanced-monolithic.com/pdf/ds1117.pdf

thus the proper power-up sequence of the fpga could be in danger..

I don't know how fast the FPGA boots up and my voltage meter is rather slow in updating measurements but the current consumption climbs from 8.4mA to 9.3mA and never goes above that.

When you lit ON your three LEDS it is + 15mA.
When the fpga will run at 100MHz it is + 30mA easily
In total 9.3+15+30mA.

Programming current is 22mA.

I guess I underrated the power consumption
(But I also used the HT7133 on a custom ESP8266 board, which draws around 150mA while transmitting data via WiFi).

[iMo]

You must rethink the voltage regulator's current ratings. I would definitely not go below 100mA for the MACH fpga only.
It may work, but it would not be a good engineering practice to put a 30mA regulator (as per datasheet header info) onto a pcb which may consume 50mA when blinking the leds, or 22mA when programming the fpga..

MachX02 power consumption estimator: search for "TN1198 - Power Estimation and Management for MachXO2 Devices"

[soFPG]

I just desoldered the voltage regulator and used the 3.3V from a USB/UART converter - didn't help.

[iMo]

Reveal Debug: The Lattice Reveal debug tool is an embed-able logic analyzer tool. It allows you to analyze the logic inside the MachXO2 in the same fashion as an external logic analyzer permits analysis of board level logic. Reveal access is only available via the MachXO2 JTAG port.

Try to run the RD, whether it recognizes the FT232H.
The actual debugging will not work as you have to insert a piece of verilog into your design.

Also you have to confirm the JTAG pins are ok, to move forward.

[soFPG]

Try to run the RD, whether it recognizes the FT232H.

It does recognize the FT232H but it is unable to detect the debug device (it sends a JTAG signal to the FPGA - and that's not working of course).

[iMo]

Yes, in case of RevealDeb the JTAG device is "soft" and created by a chunk of verilog source added to your design.. It uses user defined JTAG pins.
PS: in Radiant IDE you create the soft JTAG and LA by the "Reveal Inserter" and then you run the Reveal Analyzer

[soFPG]

Yes, in case of RevealDeb the JTAG device is "soft" and created by a chunk of verilog source added to your design

How would that help me if I am not even able to transmit my own design to the FPGA?

[SiliconWizard]

d) what is the board's current consumption (no clock applied) in the 5V rail?

9.34 mA

I'm not surprised. I guess the MachXO2 1200 should only draw its static current when blank, which is claimed to be 3.49 mA for the 1200HC (see datasheet). (The ZE series have much lower static current.)
Add to that the relatively high quiescent current of the AMS1117 regulator. 9.34 mA sounds about right.

[soFPG]

Add to that the relatively high quiescent current of the AMS1117 regulator. 9.34 mA sounds about right.

I am using a HT7133 which is much more low-power than the AMS1117.

[SiliconWizard]

Add to that the relatively high quiescent current of the AMS1117 regulator. 9.34 mA sounds about right.

I am using a HT7133 which is much more low-power than the AMS1117.

Oh, right. I missed that.
Then its 20 mA min - 30 mA typ. max output current seems on the low side though. A 1200HC will typically draw 18.8 mA during programming (see datasheet).
It also has a peak start-up current that may exceed your regulator's capability. The datasheet suggests to use Diamond's power calculator to estimate it. I just checked on one of my designs (with a 7000HE) and it gives 68 mA for VCC and 15 mA for VCCIO!


(Additionally, if you targeted such low power, you should have chosen the 1200ZE instead...)

The highish average current you're measuring may indicate that the MachXO2 is caught in an endless start-up loop (desperately trying to start up). Looking at VCC on an oscilloscope may help check whether it's really a power supply issue.

Can you try powering it from an external voltage source?

[soFPG]

Can you try powering it from an external voltage source?

I tried the 3.3V output from a typical USB/UART converter (CH430). It does not have a voltage regulator on it (at least I can't see it) so I guess voltage dividers are used. The limit should be the USB power limitation (which is at least 500mA).

Looking at VCC on an oscilloscope may help check whether it's really a power supply issue.

Good idea - I will try that.

[SiliconWizard]

Can you try powering it from an external voltage source?

I tried the 3.3V output from a typical USB/UART converter (CH430). It does not have a voltage regulator on it (at least I can't see it) so I guess voltage dividers are used. The limit should be the USB power limitation (which is at least 500mA).

It's most likely the 3.3V internal reference of the CH340, which probably has a VERY limited max output current.

[iMo]

Of course CH340 cannot be used for powering the fpga board, as its capability is comparable with the regulator he used before. I indicated above 100mA for the fpga only is a minimum.
OP has to wire his spare 1117 and try with that.
The 9.5mA seems to be still too much for a 3.5mA idle fpga and a low power regulator with ~uA quiescent current (no load). We discussed this topic earlier, OP has to replace the regulator and measure again.

A friend of mine has issued a ticket re FT232H and MachX02, as he plans some activity with the combo. We will see what Lat. support says. Again, Lattice KB explicitly states the JTAG signals must have pullup and pulldowns (also discussed earlier). Interestingly, the L. programming guide says the Mach's JTAG (except TCK) has got internal pullups.

A pity we do not have a regular Mach user with FT232H around who may help with testing..

[soFPG]

OP has to wire his spare 1117 and try with that.

As I already said - the pinout of a AMS1117 and a HT7133 are not equal (Vin and Vout are reversed). But I will try to power my PCB with an adjustable power supply.

Lattice KB explicitly states the JTAG signals must have pullup and pulldowns (also discussed earlier). Interestingly, the L. programming guide says the Mach's JTAG (except TCK) has got internal pullups.

The "MachXOJTAGProgrammingandConfigurationUsersGuide" only explicitly mentions a pulldown for TCK but no pullups for the other JTAG pins.

Thank you very much for being so patient with me! 

Edit: Now I see why TDO is on an all time high level - it is the output pin for data the FPGA transmits to the FT232H board.

[iMo]

As I already said - the pinout of a AMS1117 and a HT7133 are not equal (Vin and Vout are reversed).

For the experimental purposes you may consider to solder provisorisch the 1117 in with help of a short piece of wire

[David Chamberlain]

A pity we do not have a regular Mach user with FT232H around who may help with testing..

Ive got a machxo2 breakout board, it has the ftdi chip on it but  7000HE.

What would you like tested?

[iMo]

@DavidCh: It must be FT232H..

[soFPG]

I powered the board with 3.3V from a DC power supply and it also didn't work 

[iMo]

A friend of mine has got the answer from the Lat. tech. supp.:

..Theoretically, it should work if it can meet the MachXO2 hardware requirements..
..Please refer to TN1208 (MachXO2 Hardware Checklist) and the manufacturer datasheet of FT232H for more info..

In the TN1208 p.2:

Note: Erased device have all programming and configuration ports enabled by default. When the device is erase[d?] ensure SN and ProgramN are not driven low.

If I were you I would put a pullup on the SN and ProgramN (pullups always against +3.3V) and I'd try again. The checklist in the TN1208 states "external pullups" on the ProgramN and SN (as well as a 4k7 "external pulldown" on the TCK) see the Table 2.

Another hint: after you connect the FTDI in the Diomond Programmer (while wired to Mach), reset the Mach (power off/on of the Mach only) before you start the programming process.

PS: are your capacitor's values ok?