Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to write to flash on CrossLink-NX evaluation board #85

Open
shreekumar3d opened this issue May 7, 2021 · 15 comments
Open

Unable to write to flash on CrossLink-NX evaluation board #85

shreekumar3d opened this issue May 7, 2021 · 15 comments

Comments

@shreekumar3d
Copy link

I am unable to write to flash on my Lattice CrossLink-NX evaluation board. I have used this earlier on the Lattice ECP5 board - it works for me there.

Here is the what I see -- any idea what might be going wrong ?

$ ./build/openFPGALoader  -b crosslinknx_evn -f  /media/shkumar/Windows/Users/shkumar/my_designs/blinky/impl_1/blinky_impl_1.bit
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Enable configuration: DONE
SRAM erase: DONE
Open file DONE
Parse file DONE
Detail: 
Jedec ID          : 00
memory type       : 00
memory capacity   : 00
Detail: 
Jedec ID          : 00
memory type       : 00
memory capacity   : 00
timeout: 0 0 1000
0
wait: Error
write en: Error
Erasing: [==================================================] 100.000000%
Fail
Refresh: DONE
@shreekumar3d
Copy link
Author

I investigated this issue a bit. Adding a 1 second sleep before DisableISC() allows the flashing procedure to finish completely (see below)

diff --git a/src/lattice.cpp b/src/lattice.cpp
index 6dd6428..48e4fa6 100644
--- a/src/lattice.cpp
+++ b/src/lattice.cpp
@@ -492,6 +492,7 @@ bool Lattice::program_flash(unsigned int offset)
                printSuccess("DONE");
        }
 
+       sleep(1);
        DisableISC();
 
        if (_file_extension == "jed")

Regarding how/why this works - I need to explain how I am managing the flashing process. The CrossLink-NX evaluation board has a button SW5 - connected to PROGRAMN. To flash the board, I first push this button. Then run openFPGALoader. Then I release the button.

According to CrossLink-NX sysCONFIG Usage Guide (FPGA-TN-02099) :

For slave port configuration or programming, if the PROGRAMN pin is persisted in user function mode,
it has to be driven high before the ISC_DISABLE command is issued.

I take this to mean, "do not issue the ISC_DISABLE command when the PROGRAMN pin is high". My 1 second delay tries to ensure this. And it works well for now, for me at-least...

Holding down the PROGRAMN pin is required for this board for writing to SRAM as well (default -m option). If anybody else is using openFPGALoader with CrossLink-NX, it would help if you can chime in with your experiences as well.

@trabucayre
Copy link
Owner

It's really interesting because I have this board (with the ES version) and never used PROGRAMN button (loading a bitstream in flash or write in Flash works well without manual intervention).
I fact according to the FGPA-TN-02099 p15:

If the device is currently being programmed via JTAG, PROGRAMN is ignored until the JTAG mode programming
sequence is complete.

I must reproduce your setup to check this status
Thanks

@shreekumar3d
Copy link
Author

Actually I stumbled upon the sleep workaround quite by accident. Then I realized there is a potential explanation for it (given above).

I have a board with the ES2 version of the chip : 8BG400CES2.

Lattice Radiant's "programmer" tool doesn't work either without SW5/PROGRAMN.

If you look at the schematic of the CrossLink-NX evaluation board, you will see that there is a DNM resistor (R173) that can potentially be used to connect PROGRAMN to the JTAG interface of the FT2232H. This connection option does not exist in the ECP5 EVN.... Not saying this is relevant, but something I noticed in my study.

@trabucayre
Copy link
Owner

It's weird. Okay your device is an ES2 but theorically the JTAG take control to the FPGA without anything (it's at least true for all FPGA including my ES).
Have you tried to use openFPGALoader without using PROGRAMN ?
I regret that there is no errata...

@shreekumar3d
Copy link
Author

I started off using openFPGALoader without PROGRAMN. It doesn't work at all for flash memory. For RAM, the behaviour is inconsistent. Sometimes it works first time after DC power is applied to the board. In the subsequent invocations, the tool says "pass", but the bitstream doesn't change. That's weird too...

The only consistent behaviour I've been able to get until now is using PROGRAMN.

Note that this is not just with openFPGALoader. The official tool from Lattice behaves exactly the same way too for RAM and flash. I don't see any difference really.

@trabucayre
Copy link
Owner

I've tried to use PROGRAMN with mine but unable to reproduce your issue, it's simply works. I've spend some time to re-read datasheet...
I hesitate to buy a new board to check this behavior, but it's expensive and I'm not sure to have one with ES2.. But if you said this issue exist with radiant programmer I suspect a silicon bug.

My problem with your workaround is: without a way to use this one only with ES2, it will slow down all

@shreekumar3d
Copy link
Author

shreekumar3d commented May 10, 2021

Thanks a lot for looking at this.

No need to buy a new board for now I think. I tested two boards - both showed the same behaviour. I will contact the official Lattice support & see what solution they suggest for their programmer.

We got six more boards for a project - but access to them is off limits at this time due to COVID related restrictions...

For now, this is a workaround that I need to ensure my development & workflow stays on Linux. Once a solution is properly identified, then it can be implemented in a better way I think.

@trabucayre
Copy link
Owner

True. For sure when stable device will be available I will bought a new one, ESx seems really unstable (again I regret no errata available).

It's a good idea to ask vendor for that, maybe answer will help to find the correct way to fix this.

Maybe the solution will be available when official devices will be publicly availables (with less issues)...

@siliconwitch
Copy link

siliconwitch commented Oct 18, 2021

Update: I figured it out 🙂 The Makefile of that example has an error:

Instead of DEVICE=LIFCL-40-9BG400CES, it should be DEVICE=LIFCL-40-8BG400 in order to use the CrossLink-NX VIP Board.

Programming to SRAM works fine out of the box. To program the flash, you need to click SW4 and then start the programming.


I'm having a similar problem with the CrossLink-NX VIP board. Specifically trying to flash this example. According to the schematic, the FT2232 configuration is pretty similar to the CrossLink EVN so I assume there's nothing special I need to address. The chip is detected and the SRAM seemed to program fine. Or at least, the tool would report a success.

The board however would do nothing. CDONE (D10) just stays lit green. Never blinks or shows any activity during programming.

Trying to load to flash would result in an error until I did the trick of holding PROGRAMN (SW4) just before programming. Now it seems to have loaded the flash, but the FPGA refuses to configure. Every time I get this:

openFPGALoader -f blinky.bit -v --verify
write to flash
No cable or board specified: using direct ft2232 interface
Jtag frequency : requested 6.00MHz   -> real 6.00MHz
found 1 devices
index 0:
	idcode 0x10f1043
	manufacturer lattice
	family CrosslinkNX
	model  LIFCL-40
	irlength 8
File type : bit
IDCode : 110f1043
displayReadReg
	Config Target Selection : 0
	SPIm Fail1
	ID ERR
	EXEC Error
	ID Error
Enable configuration: DONE
SRAM erase: DONE
Open file DONE
Parse file DONE
c2 20 18 c2 read c22018c2
Detail:
Jedec ID          : c2
memory type       : 20
memory capacity   : 18
EDID + CFD length : c2
EDID              : 1820
CFD               : c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18
c2 20 18 c2 read c22018c2
Detail:
Jedec ID          : c2
memory type       : 20
memory capacity   : 18
EDID + CFD length : c2
EDID              : 1820
CFD               : c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18 c2 20 18
RDSR : 00
WIP  : 0
WEL  : 0
BP   : 0
TB   : 0
SRWD : 0
RDSR : 00
WIP  : 0
WEL  : 0
BP   : 0
TB   : 0
SRWD : 0
Erasing: [==================================================] 100.00%
Done
Writing: [==================================================] 100.00%
Done
Verifying write (May take time)
Read flash : [==================================================] 100.00%
Done
Refresh: FAIL
displayReadReg
	Config Target Selection : 0
	SPIm Fail1
	ID ERR
	EXEC Error
	ID Error
Error: Failed to program FPGA: std::exception

I assume the flash is correctly programming, however I can't get the FPGA to run. The INITN led (D9) stays on all the time.

Trying to program only SRAM again also results in an error

openFPGALoader blinky.bit -v --verify
write to ram
No cable or board specified: using direct ft2232 interface
Jtag frequency : requested 6.00MHz   -> real 6.00MHz
found 1 devices
index 0:
	idcode 0x10f1043
	manufacturer lattice
	family CrosslinkNX
	model  LIFCL-40
	irlength 8
File type : bit
Open file DONE
Parse file DONE
IDCode : 110f1043
displayReadReg
	Config Target Selection : 0
	SPIm Fail1
	ID ERR
	EXEC Error
	ID Error
Enable configuration: DONE
SRAM erase: DONE
Loading: [==================================================] 100.00%
Fail
displayReadReg
	Config Target Selection : 0
	JTAG Active
	OTP
	ISC Enable
	Write Enable
	Read Enable
	Std PreAmble
	SPIm Fail1
	ID ERR
	EXEC Error
	ID Error
Error: Failed to program FPGA: std::exception

Is there some way to erase the flash and get the board back into its factory state?

I assumed my bit file was likely broken but trying lattices example .bit file, also results in the same behavior.

@trabucayre
Copy link
Owner

The interesting point in dumps are about ID error: this is a common error when bitstream is not targeted for the flashed FPGA... Could you confirm you have one board with an ES flavour? prjoxyde examples are targeted for this one.
After flash being erased it's not possible to revert to original bitstream or you need to get original .bit.
with latest radiant I'm no more able to produce a bitstream compatible with my board (ES), and I think It's really required for me to bought new one with more recent LIFC device.

@siliconwitch
Copy link

Yep, I managed to get it working in the end. This is the board I have. It's strange because the chip is an ES according to the marking, but the example doesn't work if I set the device to LIFCL-40-8BG400CES. If I set it as LIFCL-40-8BG400 everything works fine.

tempImagePIFHAb

@trabucayre
Copy link
Owner

it's not an ES but an ES2. This why PROGRAMN must be manually driven... This workaround is not required with my ES device...
ES2 is maybe included into LIFCL-40-8BG400? I assume @gatecat may provides more information to this topic.
It's required for me to have access to ES2 or stable devices.

@siliconwitch
Copy link

Got it 🙂 I posted the issue on prjoxide and its being addressed here. Cheers for the insight!

@trabucayre
Copy link
Owner

This one show, again, an issue with matching between device idcode and bitstream idcode. I must extract from .bit this information and check match. Displaying status is clear when you know what you need to search...

@siluks-plumerai
Copy link

Ive just tested sram and flash writing with Crosslink-NX VVML board It works great!

slawek@solo:~/git/github/openFPGALoader/build$ openFPGALoader -b crosslinknx_evn ~/git/plumerai/lai/hw/syn/CROSSLINK_NX_VVML/impl_1/CROSSLINK_NX_VVML_impl_1.bit
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
slawek@solo:~/git/github/openFPGALoader/build$ openFPGALoader -b crosslinknx_evn -f ~/git/plumerai/lai/hw/syn/CROSSLINK_NX_VVML/impl_1/CROSSLINK_NX_VVML_impl_1.bit
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Open file DONE
Parse file DONE
Enable configuration: DONE
SRAM erase: DONE
Detail:
Jedec ID          : c2
memory type       : 20
memory capacity   : 18
EDID + CFD length : c2
EDID              : 1820
CFD               :
flash chip unknown: use basic protection detection
Erasing: [==================================================] 100.00%
Done
Writing: [==================================================] 100.00%
Done
Refresh: DONE

In order to avoid problems with PROGRAMN follwing constrains was added to .pdc:

ldc_set_sysconfig {JTAG_PORT=ENABLE CONFIGIO_VOLTAGE_BANK0=1.8 MASTER_SPI_PORT=SERIAL BOOTMODE=SINGLE CONFIG_IOSLEW=FAST}
ldc_set_vcc -bank 0 1.8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants