search

trabucayre / openFPGALoader

Universal utility for programming FPGA
https://trabucayre.github.io/openFPGALoader/
Apache License 2.0
1.16k stars 249 forks source link

tangprimer20k flash failure with "Error: ftdi_read_data in mpsse_read". When programming into SRAM is stuck on "pollFlag: a1" #300

Open ZhekaS opened 1 year ago

ZhekaS commented 1 year ago

Hello. Just got my new Tang Primer 20K, verified it is working with Gowin programmer on windows. Unfortunately with openFpgaLoader I am facing an issue consistently. The flashing is stopping at ~48% and then it starts showing an error: "Error: ftdi_read_data in mpsse_read" indefinitely. After the process is interrupted, the board is in some bad state and any subsequent attempts to program it fail even earlier, and in order to recover I need to use the Gowin programmer. I am using the build from commit b1c843acdb549c17c15525df649e02f88960d06b Here is the dump from the session:

write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
found 1 devices
index 0:
    idcode 0x81b
    manufacturer Gowin
    family GW2A
    model  GW2A(R)-18(C)
    irlength 8
File type : fs
Parse file Parse /redacted/TangPrimer-20K-example/DDR-test/LicheeTang20K_DDR_Test/impl/pnr/ddr3_ref_design.fs: 
checksum 0xaf49
Done
DONE
bitstream header infos
CRCCheck: ON
Compress: OFF
ConfDataLength: 2110
ProgramDoneBypass: OFF
SPIAddr: 00000000
SecurityBit: ON
idcode: 0000081b
loading_rate: 0
Jtag frequency : requested 2.50MHz   -> real 2.00MHz  
Jtag frequency : requested 10.00MHz  -> real 6.00MHz  
pollFlag: 60a0
erase SRAM pollFlag: 4080
pollFlag: 4080
pollFlag: 4080
pollFlag: a0
Done
pollFlag: 20
b 40 16 b read b40160b
Detail: 
Jedec ID          : 0b
memory type       : 40
memory capacity   : 16
EDID + CFD length : 0b
EDID              : 1640
CFD               : 0f 40 16 0b 40 12 0b 60 16 
9 40 6 b read 940060b
Detail: 
Jedec ID          : 0b
memory type       : 40
memory capacity   : 16
EDID + CFD length : 09
EDID              : 0640
CFD               : 0b 00 16 0b 40 16 0b 40 16 
RDSR : 00
WIP  : 0
WEL  : 0
BP   : 0
TB   : 0
SRWD : 0
RDSR : 00
WIP  : 0
WEL  : 0
BP   : 0
TB   : 0
SRWD : 0
flash chip unknown: use basic protection detection
Erasing: [==================================================] 100.00%
Done
Writing: [=======================                           ] 45.51%Error: ftdi_Writing: [=========================                         ] 48.83%Error: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_read^C

When trying to program into SRAM instead, it will get stuck at about 76% with infinite "pollFlag: a1" message. This happens most of the time, but I got it successfully programmed once or twice:

write to ram
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
found 1 devices
index 0:
    idcode 0x81b
    manufacturer Gowin
    family GW2A
    model  GW2A(R)-18(C)
    irlength 8
File type : fs
Parse file Parse /redacted/TangPrimer-20K-example/DDR-test/LicheeTang20K_DDR_Test/impl/pnr/ddr3_ref_design.fs: 
checksum 0xaf49
Done
DONE
bitstream header infos
CRCCheck: ON
Compress: OFF
ConfDataLength: 2110
ProgramDoneBypass: OFF
SPIAddr: 00000000
SecurityBit: ON
idcode: 0000081b
loading_rate: 0
Jtag frequency : requested 2.50MHz   -> real 2.00MHz  
displayReadReg 00000421
    CRC Error
    Memory Erase
    Non-jtag is active
pollFlag: a1
erase SRAM pollFlag: 81
pollFlag: 81
pollFlag: 81
pollFlag: 81
pollFlag: a1
Done
pollFlag: 421
pollFlag: a1
Flash SRAM: [=======================================           ] 76.85%pollFlag: a1
pollFlag: a1
pollFlag: a1
pollFlag: a1
pollFlag: a1
pollFlag: a1
pollFlag: a1
pollFlag: a1
pollFlag: a1
pollFlag: a1
....
trabucayre commented 1 year ago

I have to check if there is not related to a regression in ftdi support: never seen this error with my tang primer 20k But could you provides more information about your env (ie your computer). I know BL702 used as usb<->jtag interface may be unstable (or not working on rpi4). Could you try with another cable? Do you use an USB switch?

Thanks

ZhekaS commented 1 year ago

I have Ubuntu 22.10 on an old-ish Dell Inspiron 5775 laptop (AMD Ryzen 3 2200U), not using any external USB hubs. Here is lsusb output:

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 0cf3:e009 Qualcomm Atheros Communications
Bus 003 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 008: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1bcf:28c1 Sunplus Innovation Technology Inc. Integrated_Webcam_HD
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Here is dmesg:

[ 2312.275551] usb 3-1: new full-speed USB device number 8 using xhci_hcd
[ 2312.428134] usb 3-1: not running at top speed; connect to a high speed hub
[ 2312.446128] usb 3-1: New USB device found, idVendor=0403, idProduct=6010, bcdDevice= 5.00
[ 2312.446142] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2312.446147] usb 3-1: Product: JTAG Debugger
[ 2312.446150] usb 3-1: Manufacturer: SIPEED
[ 2312.446153] usb 3-1: SerialNumber: FactoryAIOT Pro
[ 2312.451151] ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
[ 2312.451205] usb 3-1: Detected FT2232C
[ 2312.456286] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0
[ 2312.456539] ftdi_sio 3-1:1.1: FTDI USB Serial Device converter detected
[ 2312.456595] usb 3-1: Detected FT2232C
[ 2312.461248] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB1

And these are the libraries used to build the project:

libftdi1-2/kinetic,now 1.5-6 amd64 [installed]
libftdi1-dev/kinetic,now 1.5-6 amd64 [installed]
libhidapi-dev/kinetic,now 0.12.0-1 amd64 [installed]
libhidapi-hidraw0/kinetic,now 0.12.0-1 amd64 [installed]
libudev-dev/kinetic,now 251.4-1ubuntu7 amd64 [installed]
zlib1g-dev/kinetic,now 1:1.2.11.dfsg-4.1ubuntu1 amd64 [installed]

I haven't yet tried to use another cable, will find one and let you know later.

trabucayre commented 1 year ago

Seems to have no visible issue. Could you just paste dmesg after failure? weird :-/

ZhekaS commented 1 year ago

Will do, but I believe it is the same. Could do anything with timing as my hardware is quite old? Let me know if I can enable any extra debug messages in compilation that might be helpful.

trabucayre commented 1 year ago

My primary computer is ~10 years old. I'm have not really idea on how to see why it's not working: never found solution for ch552 device used for tang nano and bl702 has issues with linux on rpi4. So I suspect something internal to the jtag<->usb converter. But it's may be wrong.

trabucayre commented 1 year ago

Hi, Any news? Thanks

bentwire commented 1 year ago

I'm having the exact same issue. Where it fails seems to vary and sometimes I can make it succeed just by commenting out a line of code. I am on a fairly modern laptop so I don't think its timing, just in case I hacked the gowin.cpp to set the clock to 100KHz and it still happens. I think it may be bitstream specific as it hags in different places and I can make it go away by undoing my last change or comment out some other large piece of code (like change a read from the DDR to a fixed set of bytes when writing to a FIFO), sometimes commenting out the code does not make the hang go away but 'moves' it.

I have not figured out any pattern yet, but I can supply code and bitstreams if needed.

bentwire commented 1 year ago

Actually... I take it back, this is slightly different... It hangs with flash but I tried sram and I get this (and it ends up running...?)

After stashing my clock change and updating to latest git:

sudo openFPGALoader --board tangprimer20k --verbose-level 2 impl/pnr/dk_video.fs Jtag frequency : requested 6.00MHz -> real 6.00MHz
Raw IDCODE:

displayReadReg 00006020 Memory Erase Done Final Security Final

bentwire commented 1 year ago

This occurs with 0.10.0 BTW. I did read the troubleshooting guide. Btw Awesome job on all the docs!

vpecanins commented 1 year ago

I can reproduce this issue. Program to SRAM works most of the times, getting stuck at 76% in some occasions. Program to external FLASH, fails consistently stuck at 46%. Giving error Error: ftdi_read_data in mpsse_read in both cases.

Can be reproduced with this bitstream on the Sipeed Tang 20K https://github.com/sipeed/TangPrimer-20K-example/tree/main/DDR-test/LicheeTang20K_DDR_Test

vpecanins commented 1 year ago

Also, programming to external flash works correctly with this bitstream: https://github.com/sipeed/TangPrimer-20K-example/tree/main/UART

trabucayre commented 1 year ago

I have retried with master branch and with LicheeTang20K_DDR_Test without issue :( SRAM and flash works (also with verify). I have a tangPrimer20k with dock lite but I doesn't use the cable provided with the board and it's plugged on thinkpad's dock. I haven't any idea on how to reproduce your issue :(

wingrime commented 1 year ago

Some bitstreams hung for me with this error, reverting commit https://github.com/trabucayre/openFPGALoader/commit/94d0ad6c851f691b27ed48884744dcaeb051e734 works

trabucayre commented 1 year ago

As mentionned previously this commit is unrelated to gowin class so the problem is between this commit and HEAD (this mean around 139 commits). Could you provides hash you use or distro/package version to reduce amount of commits to check. Thanks.

wingrime commented 1 year ago

As mentionned previously this commit is unrelated to gowin class so the problem is between this commit and HEAD (this mean around 139 commits). Could you provides hash you use or distro/package version to reduce amount of commits to check. Thanks.

I didn't rollback tree, I revert exactly that commit. And one more thing, dmesg shows sudden disconnect of bl702 without reverting commit in a middle of flashing

I think it's something with ft232 comparability with bl702

distro - Archlinux last commit 8989ac9768767829d84848b5207834f0d03f884d

trabucayre commented 1 year ago

disconnect is the usual behavior: when you plug an ftdi (or clone) ftdi_sio took an exclusive access to the peripheral. First thing done by the libftdi is to detach device (ie the driver lost access). Without this step user space application can't directly communicate with the peripheral. When openFPGALoader stop, the driver is reattached so a new message about "new device detected" is shown in dmesg. But if openFPGALoader crash or is manually stopped this last step is bypassed and the device is not detected.

Commit mentioned (archlinux) has introduces an issue in JTAG state machine behavior (fixed by commit https://github.com/trabucayre/openFPGALoader/commit/61b59ce8271a65f38d608fb8337215cffed5587b). And in fact I'm a bit perplex about the fact reverting commit mentioned at this thread beginning fixes Gowin flash programming since it's related to a class used only when a direct access to flash must be done (as required by ice40, some efinix boards and cologneChip).