Cannot flash Tang Primer 20K

[edofullin]

Hi everyone, I just got a Tang Primer 20K (with devboard) to play with LiteX. While the official Gowin tools can program the flash correctly, they are a pain to use as they unload the ftdi driver, killing the UART port in the process.

OpenFPGAloader has issues programming the flash, as it seems to hang dusring the programming process. I am using version 0.13.1 from my distro. This does not always happen, it seems smaller bitstream can be flashed correctly.

I am not sure if it can be related to #572, as the detect part works for me. Thank you in advance and let me know if I need to do further debugging.

edoardo@edoardo-fedora:~$ openFPGALoader --verbose-level 2 --cable ft2232 --write-flash --bitstream /home/edoardo/Code/litex/linux-on-litex-vexriscv/build/sipeed_tang_primer_20k/gateware/sipeed_tang_primer_20k.fs
empty
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Raw IDCODE:
- 0 -> 0x0000081b
- 1 -> 0xffffffff
Fetched TDI, end-of-chain
found 1 devices
index 0:
	idcode 0x81b
	manufacturer Gowin
	family GW2A
	model  GW2A(R)-18(C)
	irlength 8
File type : fs
Parse file Parse /home/edoardo/Code/litex/linux-on-litex-vexriscv/build/sipeed_tang_primer_20k/gateware/sipeed_tang_primer_20k.fs: 
checksum 0xbd96
Done
DONE
bitstream header infos
CRCCheck: ON
Compress: OFF
ConfDataLength: 2110
LoadingRate: 2500000
ProgramDoneBypass: OFF
SPIAddr: 00000000
SecurityBit: ON
idcode: 0000081b
after program flash: displayReadReg 00006020
	Memory Erase
	Done Final
	Security Final
Erase SRAM before erase sram: displayReadReg 00006020
	Memory Erase
	Done Final
	Security Final
pollFlag: 60a0 (80)
pollFlag: 4080 (0)
pollFlag: 4080 (0)
pollFlag: 4080 (0)
pollFlag: 4080 (0)
pollFlag: 4080 (0)
pollFlag: a0 (20)
after erase sram: displayReadReg 000000a0
	Memory Erase
	System Edit Mode
pollFlag: 20 (0)
after erase sram: displayReadReg 00000020
	Memory Erase
DONE
Jtag probe limited to %d MHz6000000
Jtag frequency : requested 10.00MHz  -> real 6.00MHz  
b 0 17 b read b00170b
Detail: 
Jedec ID          : 0b
memory type       : 00
memory capacity   : 17
b 40 17 b read b40170b
Detail: 
Jedec ID          : 0b
memory type       : 40
memory capacity   : 17
RDSR : 0x00
WIP  : 0
WEL  : 0
BP   : 0
TB   : 0
SRWD : 0
RDSR : 0x00
WIP  : 0
WEL  : 0
BP   : 0
TB   : 0
SRWD : 0
flash chip unknown: use basic protection detection
start addr: 00000000, end_addr: 000e0000
Erasing: [==================================================] 100.00%
Done
Writing: [===============                                   ] 28.16%Error: ftdi_read_data in mpsse_readError: ftdi_read_data in mpsse_read

[trabucayre]

Looks like a regression with this model. Since FTDI's error are displayed it looks like to be related to the FTDI clone interface.
Will check first with a true FTDI to have a better idea about the issue (I have a tang Primer 20k with a dock lite baseboard).

[edofullin]

My dock seems to have a BL702CA0 which is used for JTAG&UART. Unfortunately it seems like they do not publish the firmware for it. I also have a Tang Nano 20K, with the same SoC and that works without issues.

[trabucayre]

• tang Primer 20k: BL702
• tang Nano 20k: BL616

I think firmware is available somewhere because it's the same chip than RV-Debugger Plus (an in fact with dock lite this debugger is used).
But, I think, this confirm the assumption about issue with USB<->JTAG adapter

[trabucayre]

Ok Confirmed: I have used a digilent hs2 probe in place of the sipeed interface: programming a LiteX bitstream works perfectly.
I have to find where is the firmware and how to deal with this probe limitations.

[trabucayre]

JTAG interface firmware is available here but according to the history I haven't seen no improvements related to JTAG.
Maybe some forks have a fixed JTAG.

[edofullin]

JTAG interface firmware is available here but according to the history I haven't seen no improvements related to JTAG. Maybe some forks have a fixed JTAG.

I am a bit reluctant to trying to flash the firmware on the repo you linked on the debugger as I do not have at the moment another JTAG adapter if for some reason the new firmware does not work.

[trabucayre]

Yes: make sense.
I have a second JTAG adapter so I more easy to me to test an update

[edofullin]

Hey, so I looked today at the source code and it seems to get a TIMEOUT from the underlying libusb.
After a few tries it seems reducing the write page size to 128 (instead of 256) solves the issue.
I am not sure if it is a problem only on my board / with my programmer firmware and what is the best way to tackle this further, as I never worked with ftdi before.

openFPGALoader/src/spiFlash.cpp

Line 442 in a53aedb

size = (addr + 256 > len)?(len-addr) : 256;

for (int addr = 0; addr < len; addr += size, ptr+=size) {
		size = (addr + 128 > len)?(len-addr) : 128;
		if ((_jedec_id >> 8) == 0xbf258d) {
			size = 1;
		}
		if (write_page(base_addr + addr, ptr, size) == -1)
			return -1;
		progress.display(addr);
	}
	progress.done();

[buzmeg]

I have a new Sipeed Tang Primer 20K and it programs fine with the latest openFPGAloader from master. If one of the programs from TangPrimer-20K-example fails, please let me know and I will try it.

% openFPGALoader -f -r  WS2812.fs
empty
write to flash
No cable or board specified: using direct ft2232 interface
Jtag frequency : requested 6.00MHz    -> real 6.00MHz
Parse file Parse WS2812.fs:
Done
DONE
after program flash: displayReadReg 00006020
        Memory Erase
        Done Final
        Security Final
Erase SRAM DONE
Jtag probe limited to %d MHz6000000
Jtag frequency : requested 10.00MHz   -> real 6.00MHz
Detail:
Jedec ID          : 0b
memory type       : 40
memory capacity   : 17
Detail:
Jedec ID          : 0b
memory type       : 60
memory capacity   : 17
RDSR : 0x00
WIP  : 0
WEL  : 0
BP   : 0
TB   : 0
SRWD : 0
flash chip unknown: use basic protection detection
start addr: 00000000, end_addr: 00090000
Erasing: [==================================================] 100.00%
Done
Writing: [==================================================] 100.00%
Done

% openFPGALoader -V
openFPGALoader v0.13.1

[71661.144359] usb 3-3.4.1: new full-speed USB device number 41 using xhci_hcd
[71661.281014] usb 3-3.4.1: not running at top speed; connect to a high speed hub
[71661.282609] usb 3-3.4.1: New USB device found, idVendor=0403, idProduct=6010, bcdDevice= 5.00
[71661.282624] usb 3-3.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[71661.282630] usb 3-3.4.1: Product: JTAG Debugger
[71661.282635] usb 3-3.4.1: Manufacturer: SIPEED
[71661.282639] usb 3-3.4.1: SerialNumber: FactoryAIOT Pro
[71661.298657] ftdi_sio 3-3.4.1:1.0: FTDI USB Serial Device converter detected
[71661.298757] usb 3-3.4.1: Detected FT2232C/D
[71661.299537] usb 3-3.4.1: FTDI USB Serial Device converter now attached to ttyUSB0
[71661.299722] ftdi_sio 3-3.4.1:1.1: FTDI USB Serial Device converter detected
[71661.299780] usb 3-3.4.1: Detected FT2232C/D
[71661.300428] usb 3-3.4.1: FTDI USB Serial Device converter now attached to ttyUSB1

[buzmeg]

Okay, I'm seeing similar problems with "sipeed_tang_primer_20k.fs" from the LiteX example. This appears to be bitstream dependent.

I'm going to put out a hypothesis that it's due to the fact that the overload of the READY, DONE, and SSPI pins is causing issues. The two bitstreams that I included should be for the same LiteX code. However, the bad one was the one from when I regenerated the project while the good one is directly from the example repository.

Here are two bitstreams that seem to exhibit success and failure.
bitstreams.zip

[edofullin]

Okay, I'm seeing similar problems with "sipeed_tang_primer_20k.fs" from the LiteX example. This appears to be bitstream dependent.

I'm going to put out a hypothesis that it's due to the fact that the overload of the READY, DONE, and SSPI pins is causing issues. The two bitstreams that I included should be for the same LiteX code. However, the bad one was the one from when I regenerated the project while the good one is directly from the example repository.

Here are two bitstreams that seem to exhibit success and failure.
bitstreams.zip

What do you mean? Isn't the bitstream copied byte-for-byte? I suppose any effects will manifest only once the FPGA resets and loads the new bitstream into SRAM.

I also noticed the different behaviour with different bitstreams though, a simple blink written by hand in verilog in the Gowin ide flashes correctly. Also the LiteX bitstreams work with the Gowin programmer, as well as (it seems) with the modification above.