[SOLVED] Lattice FPGA: issue solved after re-flashing the same binary

[flote21]

Hello!
I am wondering about the issue described on the title of this thread.
I am using a crosslink-nx from Lattice to adapt video Interfaces. And during the serial production of the PCBA, 10% of the units are not working as expected.
In normal working, the FPGA should drive an RGB display, displaying a clear bar test pattern:

However the issued PCBAs are having the following behavior:

The issue looks to have a high depending on the temperature changes, because after some minutes of working, it starts to work fine displaying the clear color test pattern showed in the first picture. However the issue is always happening at low temperatures (typically below 0 degrees).

Finally after checking and measuring the correct shapes of all the RGB interface signals, i have decided Re-flashing the SPI memory flash of the FPGA and it solved all the issues in all of the problematics PCBAs.

Does anyone has any idea about what could happen? I woule appreciate whatever hint or tip to continue investigating this topic.

Thanks in advance.

Greetings.

 

[dick_freebird]

Might be a programming link integrity (BER) problem? Or for a
nonvolatile-config device, some issue with programming V, I
leading to marginal write quality and maybe then, temperature
read marginality?

 

[D.A.(Tony)Stewart]

Did you use the vendor tools for JTAG? If not , why not?

e.g.

AMD Customer Community

support.xilinx.com

Some users have issues with EOL ISE.

Xilinx ISE 14.7 - IMPACT is a disaster - Page 1

Xilinx ISE 14.7 - IMPACT is a disaster - Page 1

www.eevblog.com

 

[flote21]

Hello!
Thanks a lot for your replies. But theoretically the process is done in the right way:
- We are using the official hardware from Lattice. Not third vendors tools.
- The issued bit file has been read it and compare it with a proper working bit file and they match!
- The issued Lattice FPGA power up as the good ones driving the Done LED to ON and indicating the proper working of the loaded bit file.

 

[D.A.(Tony)Stewart]

if your cable connection is suboptimal, there may be excessive ringing. Adding 25 to 50 Ohms in series with the Tx drivers will improve damping and will prevent this signal margin loss and may be the cause of your flash errors if it drives at maximum serial rate.

The other possibility is CM Vdd+Vss noise with target and burner operating from separate SMPS and a shared 0V. SMPS transformer CM leakage ripple noise has been known to exist with shared signal grounds floating causing common mode noise. Check for PE ground connections or CM choke on lines which should reduce these effects if present. e.g. a laptop with a charger disconnected is better than with charger on, while a tower with PE grounded 0V should divert leakage to PE gnd.

 

[FvM]

Are you using quality SPI flash from reliable distributor?
Did you repeat the test often enough to be sure that the problem is gone after reflashing? Could be also a design problem occuring only occasionally due to random initialization of PLL clock phase or similar.

 

[flote21]

Hello!
thanks for your quick replies.
I am wondering that if the issue is coming from the flashing process, the Lattice flashing tools should drive an error once the bit file is verifyed after the flashing correct? However, the software tool always report the a correct flashing of the bit file and I was not able to reproduce the flashing issue in my lab. I am flashing 100 times the same FPGA and I habe been always getting a correct working of the FPGA. Do you think that the it could be a bug on the software flashing tool and it is not reporting the flashing errors?
Thanks in advance.

 

[flote21]

The issue has been solved. A wrong FPGA version was used in production. Thanks for your support.