openFPGALoader

[kimstik]

after a small series of transactions ftdi_write_data always fails https://github.com/trabucayre/openFPGALoader/issues/32

[diodep]

I currently doesn't have much time to locate the issue for about one year. But you can still paste verbose log on this thread, I may try to fix it at sometime when I'm free.

[ric96]

Okay looks like running openfpgaloader slows thing enough in verbose mode to not fail write but CRC fails

This is the error from tangnano with and without verbose:

[sahaj@athena examples]$ make blinky-tangnano-prog
openFPGALoader -b tangnano blinky-tangnano.fs
write to ram
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Parse file Parse blinky-tangnano.fs: 
Done
DONE
Jtag frequency : requested 2.50MHz   -> real 2.00MHz  
erase SRAM Done
Flash SRAM: [==================================================] 100.00%
Done
SRAM Flash: Success
[sahaj@athena examples]$ nano Makefile 
[sahaj@athena examples]$ make blinky-tangnano-prog
openFPGALoader -b tangnano -f blinky-tangnano.fs
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Parse file Parse blinky-tangnano.fs: 
Done
DONE
Jtag frequency : requested 2.50MHz   -> real 2.00MHz  
erase SRAM Done
erase Flash Done
write Flash: [===============                                   ] 29.07%write error: -1 instead of 2
writeTMS: error
write error: -1 instead of 64
write_data error in mpsse_store
write error: -1 instead of 64
writeTMS: error
write error: -1 instead of 64
write error: -1 instead of 64
write_data error in mpsse_store
write error: -1 instead of 64
write error: -1 instead of 64
write_data error in mpsse_store
write error: -1 instead of 64
write error: -1 instead of 64
write_data error in mpsse_store
write error: -1 instead of 64
write error: -1 instead of 64
write_data error in mpsse_store
write error: -1 instead of 64
write error: -1 instead of 64
write_data error in mpsse_store
write error: -1 instead of 64
write error: -1 instead of 64

openFPGALoader -b tangnano -fv ./blinky-tangnano.fs 
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
found 1 devices
index 0:
        idcode 0x900281b
        manufacturer Gowin
        model  GW1N-1
        family GW1N
        irlength 8
File type : fs
Parse file Parse ./blinky-tangnano.fs: 
checksum 0xd125
Done
DONE
bitstream header infos
CRCCheck: ON
Compress: OFF
ConfDataLength: 274
ProgramDoneBypass: OFF
SPIAddr: 00fff000
SecurityBit: ON
idcode: 0900281b
loading_rate: 120
Jtag frequency : requested 2.50MHz   -> real 2.00MHz  
pollFlag: 190a0
erase SRAM pollFlag: 190a0
Done
pollFlag: 19020
pollFlag: 190a0
erase Flash Done
pollFlag: 19020
write Flash: [==================================================] 100.00%
Done
pollFlag: 19020
CRC check : FAIL
d125 0000
displayReadReg 00019020
        Memory Erase
        Gowin VLD
        Ready
        POR

[josuah]

Sorry, this is very old.

The hint might be in the displayReadReg here:

$ python3 decode_gowin_status.py 0x00019020
OK   1<<0    CRC valid
OK   1<<1    Command valid
OK   1<<2    Verify IDCODE valid
OK   1<<3    Timeout not reached
OK   1<<12   Gowin embedded flash valid (VLD)
ERR  1<<13   Done Final Status, loading successful
ERR  1<<14   Security Final, security enabled
OK   1<<15   Ready Status Flag
OK   1<<16   POR Status ("ERR" when RECONFIG_N is low)

https://github.com/brilliantlabsAR/monocle-micropython/blob/dea1c0b41c34f561033ee19132127cf563e6693c/tools/decode_gowin_status.py

You will want to disable that security bit somehow: SecurityBit: ON unless you support it as a feature.

A special design for the configuration data security of Gowin FPGA product. After you write the bitstream with security bit to the device SRAM, no one will be able to read back the data. Gowin Software sets a security bit for the bitstream data of all FPGA products by default. -- http://cdn.gowinsemi.com.cn/UG290E.pdf

[josuah]

After all, I do not think Security Bit should be a problem: it looks like openFPGALoader reads a checksum in a status register rather than the content of the bitstream itself...

Something more to check is whether the checksum is enabled in the .fs file, it might be a dummy/blank value.

Not sure about the "Done Final Status, loading successful" not ok though...