custom FPGA dev board not working

[golf32]

I've designed a custom FPGA development board for the LCMXO2-2000HC-4TG100C FPGA. I can get the chip to be recognized by JTAG, but it will not program. I have attached the schematic. Note that I messed up the labeling of the JTAG pins but I have that sorted out, and have added pullups on TMS, TDI, and TDO and a pulldown on TCK. I also have not populated the button on programn I am using an FTDI C232HM cable for programming.

From looking at datasheets and reference designs, it appears all I need for programming is the JTAG pins exposed. There is mention of INITN, DONE, PROGRAMN, and JTAGEN pins for programming in some datasheets but none of the reference designs do anything with them.

I've attached the log file which lattice diamond spits out when it fails. There are a couple different error messages but mostly it's "Failed in Function READ_ID" or "Failed in Function CHECK_STATUS". It appears that some data is coming back from the FPGA but not the correct data.

Thanks for any suggestions.

[ataradov]

I don't see anything wrong with the schematic. For reference here is my version of a simple breakout board for the same FPGA that is known to be functional https://github.com/ataradov/breakout-boards/tree/master/lcmxo2-2000hc

What do you mean by "recognized by JTAG"?

Double check that you are not mixing up TDI and TDO on the JTAG side. They are confusing.

The first thing I would do in cases like this is put a scope on what you think is TDO, power cycle the board and clock a number of pulses into the TCK pin. TDO should clock out the IDCODE for the device. This would confirm that your JTAG is working and labeling is correct.

And then see that the same happens under the JTAG cable control.

[golf32]

I don't see anything wrong with the schematic. For reference here is my version of a simple breakout board for the same FPGA that is known to be functional https://github.com/ataradov/breakout-boards/tree/master/lcmxo2-2000hc

What do you mean by "recognized by JTAG"?

Double check that you are not mixing up TDI and TDO on the JTAG side. They are confusing.

The first thing I would do in cases like this is put a scope on what you think is TDO, power cycle the board and clock a number of pulses into the TCK pin. TDO should clock out the IDCODE for the device. This would confirm that your JTAG is working and labeling is correct.

And then see that the same happens under the JTAG cable control.

By recognized by JTAG I mean that when I do a JTAG scan it finds the part, although it can't find the specific package and requests to confirm that it's an XO2-2000
(error message: WARNING - Scan found MachXO2 on row 1 but cannot identify the package. Please manually select the correct device before proceeding.)

I tried pulsing it manually but couldn't get anything to work. When I connect the programmer I can see it exchange a lot of data. Photo attached.

I tried again this time and it did something for about a second and got a new error:

Code: [Select]

---------------------------------------------
Device 1 LCMXO2-2000HC:
    Operation: FLASH Erase,Program,Verify
    File Date/time: 02/12/22 15:59:40
---------------------------------------------

Connected to Lattice Cable Server.
Board with FTDI USB Host Chip detected.

Check configuration setup: Start.
JTAG Chain Verification. No Errors.
Check configuration setup: Successful.
Device1 LCMXO2-2000HC: FLASH Erase,Program,Verify

Number of Loop = 131/1500

Total erase time: 1310 ms.

--------------Row2--------------:
HDR  0
TDR  0
SDR 128   TDI(00000000000000000000000000000000)
Expected  TDO(00620000000200000044EEFFC00C1251)
Received  TDO(00620000000200000044EEFFC00E0928)
Bits Error 0018: Expected: 0 Received: 1
Bits Error 0013: Expected: 1 Received: 0
Bits Error 0012: Expected: 0 Received: 1
Bits Error 0010: Expected: 1 Received: 0
Bits Error 0009: Expected: 0 Received: 1
Bits Error 0007: Expected: 1 Received: 0
Bits Error 0006: Expected: 0 Received: 1
Bits Error 0005: Expected: 1 Received: 0
Bits Error 0004: Expected: 0 Received: 1
Bits Error 0001: Expected: 1 Received: 0

"Failed in Function VERIFY /see log file for more details/ "
Execution time: 00 min : 04 sec
Process Operation Failed.
Elapsed time: 00 min : 04 sec
Operation: unsuccessful.
I suppose now somehow it is actually connecting to the chip and has downloaded some data, but not it's failing to verify. If I run it a couple times the "number of loop" is different but the expected vs received is always the same. I love errors that randomly change!

[ataradov]

I don't know what Diamond is doing for programming. I would do the IDCODE experiment. Get an Arduino or whatever programmable board you like. Then pulse TCK and read TDO pins. It should clock out the IDCODE value. This will only happen on a first power up, so you need to power cycle the board between the experiments.

Although the last log suggests that device sends out something like the data that was expected. So, I would also drop the clock frequency way low, to something like 100 kHz.

[golf32]

It seems that getting the IDCODE is slightly harder than pulsing the TCK line. The exact procedure is detailed here: https://www2.lauterbach.com/pdf/training_jtag.pdf

I followed this and got the ID code! TDO reads the code.

You can set a TCK clock divider in lattice diamond and I have set it to it's maximum value (30). That seems to decrease the number of random error I get, and so it fails on verification basically every time now.

[ataradov]

It is not. You can issue the command, but after the rest, shift register is loaded with IDCODE by default. This is the first test I do when working with a new device over JTAG, it never failed.

Check the actual frequency you get and then check signal integrity on the lines.

[golf32]

with the 30x divider I'm getting a clock frequency of 970kHz. Signal seems to be fine: sharp edges, no ringing, etc. Signal integrity is the only thing I can think of at this point, but 1MHz should be fine on a bread board with flying leads etc, and the signal looks fine.

The only other thing I can think of is damage in soldering. It took a lot of rework and heat and was not a smoother process. I think that's a longshot though.

[ataradov]

It is also possible that there are some issues supporting this specific FTDI cable. Or FTDI IC is fake. I would look at data change timing compared to the clock. There may be some setup/hold time issues.

1 MHz is pretty slow, it should work.

[golf32]

Just checked timing parameters, everything looks good. No reason to suspect cable isn't genuine, purchased straight from digikey.

I'm going to try programming via I2C and SPI. I already tried I2C to no avail, but I will try again.

[golf32]

I figured it out!

I stumbled across this post: https://www.eevblog.com/forum/microcontrollers/lattice-cpld-fails-to-verify/ which had the same issue that I did. They suggested to add an 18pf capacitor across TCK and ground. I actually saw this earlier and never tried it, but I had an 18pf capacitor already on my breadboard and decided to try. Lo and behold, it worked! I managed to flash the board and everything works! The datasheet doesn't mention anything about rise time specs for JTAG, but the FTDI cable must be too fast or something.

Now I can get to the real work of refreshing myself on VHDL...

edit: spoke too soon. I got it to flash a simple AND gate, but now when I try to re-flash I get the same errors as before...

[ataradov]

The only reason I can see this work is that setup time is incorrect, and adding the capacitance delays the edge of the clock signal relative to the data. I don't think it is related to the rise time.

[golf32]

It seems to be highly dependent on the capacitance. It worked when it was on top of my oscilloscope, but not on my desk. 18pF made it error sometimes, while 36pF made it error out every time. I made it work again on my desk by wrapping my hand around the wires  . I guess it works for now, but I will definitely re-design this board with more thought put into JTAG signal integrity.

[james_s]

Maybe there's something wrong with your layout? Too long traces? Proximity to other signals? Inadequate decoupling on the power rails? This sort of "random" behavior is a common symptom of that.

[golf32]

The routing is not great, it runs across the board (~1.5'') and jumps layers, but it's only a 1MHz signal on a 4 layer board.

Decoupling/power supply is designed with lattice app note.

My prime suspect is that the JTAG signals go through long flying dupont cables and a breadboard.

[ataradov]

Can you capture scope traces of the JTAG pins relative to TCK? It is really not that sensitive, unless your flying leads are 50" long or something like that.

[golf32]

I measured about ~500ns of setup/hold time relative to TCK edge before I got it working.

[ataradov]

That should be plenty. It is hard to tell what's going on then.

I personally used a cheap clone of HW-USB-2A (like this https://www.aliexpress.com/item/1005003143843450.html) and it worked without any issues at all. It is based around an unmarked chip, which looks like cy7c68013a in pinout and package type.

[golf32]

If I ever re-design this board I'll buy one of those and add in the proper connector. In the mean time, I'll just have to remember to hold the cable.

[Cerebus]

My prime suspect is that the JTAG signals go through long flying dupont cables and a breadboard.

I've had that do nasty things to me before when I've played fast and loose with routing test and jtag/debug signals over a loose mess of dupont cables or similar. When in doubt make sure you've got got good grounds (signal returns), low loop area, and make sure that the connectors are actually making contact, those little pins and solderless breadboards are not always happy bedfellow. Sometimes a small inline terminating resistor can help to make a marginal signal into a solid one, 100 is often a good starting value.

[Cerebus]

Double check that you are not mixing up TDI and TDO on the JTAG side. They are confusing.

I know exactly what you mean. Does a label that says 'TDO' on a programmer mean that is it intended to be connected to the pin labelled 'TDO' on the chip, or does it mean that this is the signal that comes out of the programmer and should be connected to 'TDI' on the chip?

I've got into the habit of adding an extra 'out', or 'in', or an arrow, or a similar clarifying label to, or next to, the names of signals like that to emphasise the physical direction of the signal relative to each chip, after double checking it with the data sheet, just to try and avoid that confusion. I still end up scratching my head sometimes...

[james_s]

The routing is not great, it runs across the board (~1.5'') and jumps layers, but it's only a 1MHz signal on a 4 layer board.

Decoupling/power supply is designed with lattice app note.

My prime suspect is that the JTAG signals go through long flying dupont cables and a breadboard.

As in a solderless breadboard? If you're running MHz signals through one of those I'm not surprised you're having issues. Try cleaning up that side of things and making the connections as short and direct as you can.