Hang on "Enable configuration:" programming ECP5 not alone on a JTAG chain

[sergachev]

I have a board with 2 FPGAs on the JTAG chain:

./openFPGALoader --detect
write to ram
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
index 0:
	idcode 0x1112043
	manufacturer lattice
	family ECP5
	model  LFE5U-45
	irlength 8
index 1:
	idcode 0x3636093
	manufacturer xilinx
	family artix a7 200t
	model  xc7a200
	irlength 6

If I try to program ECP5 like that openFPGALoader hangs on "Enable configuration:" :

./openFPGALoader --index-chain 0 -m ~/projects/litex-template-acorn/build/gateware/litex_m2_baseboard.bit
write to ram
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Open file: DONE
Parse file: DONE
Enable configuration: 

At the same time it can program the artix:

./openFPGALoader --index-chain 1 -m ~/projects/litepcie_acorn/build/sqrl_acorn_platform/gateware/sqrl_acorn_platform.bit 
write to ram
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Open file DONE
Parse file DONE
load program
Flash SRAM: [==================================================] 100.00%
Done

And if I physically disconnect the artix from the chain it works fine with ECP5:

./openFPGALoader --index-chain 0 -m ~/projects/litex-template-acorn/build/gateware/litex_m2_baseboard.bit
write to ram
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Open file: DONE
Parse file: DONE
Enable configuration: DONE
SRAM erase: DONE
Loading: [==================================================] 100.00%
Done
Disable configuration: DONE

Lattice Diamond Programmer works in both configurations.

[trabucayre]

Hi!
What is the frequency used by Diamond to program? Maybe slowest. Could you try with --freq 3e6 for instance?
Have you pullup resistors? Do you use Dupont cables ?
Need to try to reproduce your issue. If your able to talk with the artix it's seems to show the chain is working. Could you try to invert devices (if it's possible)?

[trabucayre]

After re-reading this issue I have seen that you use litex-acorn-baseboard. It's true?
I suppose @enjoy-digital has tested this board to configure both FPGAs.
If you conifrm this is this board or something similar maybe I can try to base connection between device on this board (Not sure to be able to mimic exactly).

[enjoy-digital]

Hi @trabucayre,

@sergachev is indeed using the litex-acorn-baseboard and designed it. The FPGA configuration is working when JTAG is directly connected to each FPGA and the issue only happens when chaining the JTAG. When chained, Diamond is able to correctly configure the Lattice ECP5 and Vivado the Artix7, so the hardware/chain seems to be OK.

[trabucayre]

Ok. it's more clear about board!
Have to see why it's not working in software side. I have, when I've added the jtag chain support, tested with colorlight + a spartan7, but I have to redo these tests with the acorn instead of spartan7.

[trabucayre]

The strange thing in fact is: programming the artix works, it's only when programming lattice in the full chain...

[sergachev]

Hi!

Apart from what @enjoy-digital already answered:

• lowering the frequency does not help
• inverting the chain is not trivial on this board, can do later with other boards
• TCK has 4k7 pull-down, other ones have pulls inside ECP5 (following FPGA-TN-02039-2.0)
• no dupont cables, but there is a 5 cm molex cable from base board to acorn

[trabucayre]

In fact now your setup is more clear to me. Previous questions are about common sources of issues but in this case it no more make sense, and if diamond works the problem is not about hardware.
I will try ASAP (this week-end if it's possible) to build a similar setup with hardware I have and to trying to locate source of problem.

[trabucayre]

Just a small question: have you tested with openOCD? It's works? Its just to see if this issue is specific to openFPGALoader or is common all non proprietary tools.

[sergachev]

I tested with OpenOCD too and it also fails somewhere with 2 devices on the chain (flash programming of Artix for sure, but maybe something else too). Will be able to test again in a week.

[trabucayre]

It's really interesting! If both fails there is maybe something particular done by diamond.
Unfortunately my tries with not correct hardware (prototype board) has fails... I'm unable to detect, in this particular setup, both devices...

[sergachev]

I'm back to tests with this board; latest openFPGALoader still fails the same way.
The only way I found to program ECP5 with OpenOCD is to use an .svf file generated by LiteX and its OpenOCDJTAGProgrammer - that works only when ECP5 is alone and fails like that when Artix is in the chain:

95%    Error: tdo check error at line 14
Error:     READ = 0x0003dce
Error:     WANT = 0x81112043
Error:     MASK = 0xffffffff
Time used: 0m3s871ms 
svf file programmed failed

I'm no expert in SVF files but suspect that it needs to generated in a way that it's aware of both FPGAs to work correctly. I'm using this config for OpenOCD which at least detects both chips successfully and throws no warnings.

[trabucayre]

It's really weird.
For openFPGALoader case I'm (quite) sure to no have bug in jtag chain handling: I have fixed that when added zynqMP where there is 3 devices (internally to chip) and PL is second one.

I assume openOCD works as openFPGALoader: it know jtag chain topology and there is no need to have something about this aspect in the SVF file.
Have you specified which device is the target?

Maybe checking signals between probe and EPC5, between FPGAs, and between artix and probe?

The most strange this is lattice is able to deal with this chain, maybe there is a specific configuratiion when ECP5 is not alone...

Do you know public availabilty for the board? It's generaly more easy to find something when the hardware is near computer :-)

[sergachev]

Have you specified which device is the target?

Sure - see --index-chain x in the commands in the 1st message.

Maybe checking signals between probe and EPC5, between FPGAs, and between artix and probe?

What exactly would you check? The chain overall does work, both devices are detected, Artix gets configured.

Do you know public availabilty for the board? It's generaly more easy to find something when the hardware is near computer :-)

Totally understandable, but unfortunately no info. I should try to chain such 2 devices using off-the-shelf boards as promised already though.

[trabucayre]

Have you specified which device is the target?

Sure - see --index-chain x in the commands in the 1st message.
True. But for openOCD you do equivalent selection? It's just because one tool unable to program, mean a bug somewhere, when two have same issue and not the official tool, it's may a deepest problem... (or undocumented feature)

Maybe checking signals between probe and EPC5, between FPGAs, and between artix and probe?

What exactly would you check? The chain overall does work, both devices are detected, Artix gets configured.
Detection step is more or less stupid, you send a serie of bits and you read tdo, but when you adress specifically a device in a chain you have to correctly align bits. The idea here is to check if this requirement is true, and if artix propagates correctly tdi to tdo when in bypass...

Do you know public availabilty for the board? It's generaly more easy to find something when the hardware is near computer :-)

Totally understandable, but unfortunately no info. I should try to chain such 2 devices using off-the-shelf boards as promised already though.
Okay... I have tried myself too but I need to redo that. Unfortunately this setup is based on fly wire with a risk of unstable system...

[trabucayre]

Hi.
I'have doing some tries with boards I have:

• colorlight 5a75b (pulls ?)
• spartanEdge (no pulls)
• orangeCrab (tck: pulldown)

scheme	results
TDI -> orangeCrab -> spartanEdge -> TDO	Nothing is seen (corruption)
TDI -> spartanEdge -> orangeCrab -> TDO	Everything is okay: able to load bitstream in both FPGA
TDI -> colorlight -> spartanEdge -> TDO	communication is unstable (sometime both devices are detected, sometime corruption) and unable to program devices
TDI -> spartanEdge -> orangeCrab -> TDO	Nothing is seen (corruption)

This is interesting because second scheme shows this issue is not related to a bug into algorithm. Cables in my setup adds 1 to 3 ns due to the length but seems not relevant too.

I have to try with diamond but unfortunately, this tool is unable to see my JTAG probe :-/

I have added --invert-read-edge to sample TDO on neg edge instead of positive I'm not sure it is relevant in this case.

[michaeltraxler]

We have the same problem here, with different boards and different lattice chips in a chain.
They work well with the lattice programmer.
The example shown below is a chain of two MachXO3.
With openFPGALoader I can program and verify the second device in the chain!
For the first device the program stops with: Enable configuration:

Here the command line:
% openFPGALoader --busdev-num 003:002 --freq 1E6 --verify --index-chain 0 ~/shared/dirich4_thresholds_20210526.jed --verbose-level 1

The output is:

No cable or board specified: using direct ft2232 interface
Jtag frequency : requested 1.00MHz   -> real 1.00MHz
found 2 devices
index 0:
	idcode 0x12b4043
	manufacturer lattice
	family MachXO3LF
	model  LCMX03LF-4300E
	irlength 8
index 1:
	idcode 0x12b4043
	manufacturer lattice
	family MachXO3LF
	model  LCMX03LF-4300E
	irlength 8
File type : jed
IDCode : 612b4043
displayReadReg
	TRAN Mode
	Config Target Selection : 4
	SDM Enable
	No err
Open file DONE
end
theorical checksum 3eff -> 3eff
array size 2164
Parse file DONE
feabits :
0220 <-> 544
	Boot Mode       : Single Boot from Configuration Flash
	Master Mode SPI : disable
	I2c port        : enable
	Slave SPI port  : disable
	JTAG port       : enable
	DONE            : disable
	INITN           : disable
	PROGRAMN        : disable
	My_ASSP         : disable
Pin Count  : 81
Fuse Count : 835328
area[0]    0 276992 2164 ffffbdcd
...
...
00000000000000000000000000000000000000000000000000000000000000000000000000000000000 END CONFIG DATA
area[2] 833920 1408 11 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 TAG DATA
Enable configuration: ^C

which I stopped with Ctrl-C.

With debug level 3 I see that the following is repeated endlessly:

2
writeTDI move to EXIT1_xx and send last bit 1
writeTMS 1 1
writeTMS 3 1
writeTMS 4 1
writeTDI len : 8 8 1 0
writeTDI read/write 8 bit
writeTDI last_bit ff size 7
writeTDI len : 8 7 0 7
writeTDI read/write 7 bit
writeTDI last_bit f0 size 6
writeTDI move to EXIT1_xx and send last bit 81
writeTMS 1 1
writeTMS 5 1
writeTDI len : 1 1 0 1
writeTDI read/write 1 bit
writeTDI last_bit ff size 0
writeTDI len : 8 7 0 7
writeTDI read/write 7 bit
writeTDI last_bit 0 size 6

--invert-read-edge doesn't change the behaviour.
Also the same behaviour with all frequencies from 1kHz to 15MHz.
I'm happy to debug the issue.
openFPGALoader gives such a big benefit for our work (we have to program 4 thousand of these FPGAs), so that a bit overhead to debug this issue is fine with us :-)

[trabucayre]

Thanks for this information.
I have to find a way to have (physical) access to a couple of machXO3 with JTAG headers instead of onboard usb<->jtag to find why openFPGALoader works with second device but fails with the first...