Can't program GW1NZ-LV1 FPGA with published code.

[dmolinagarcia]

Hi. I'm struggling to fix an issue I'm having with the published usb2uartjtag code.

I have a Tang Nano 1k, with a BL702 on board. I desoldered both the Bl702 and the GW1NZ FPGA, and transfered them to my own PCB, that replicates the TANG NANO schematich, but with severl BL and GW1NZ pins exposed via pin headers, as well as some additional stuff.

I can program the FPGA with the current BL702 firmware. Both the BL and the FPGA behave as expected, same as when they were on the Tang Nano PCB. However, after building the USB2UARTJTAG firmware for the Bl702, it fails to program the FPGA.

With this firmware, the Bl702 is properly detected as a FTDI device. And the gowin programmer works. However, it ends up with an error code, and the FPGA won't wake up. This firmware can program the SRAM properly though, but it fails to program the flash.

Reverting to the original firmware allows me to reprogram the FPGA, with no issues.

In order to discard any issues while soldering, I build 3 boards, from 3 Tang Nano. Same behaviour in the 3 of them. So I'm pretty sure my issue is caused by some firmware error I'm failing to detect.

I've capture the full JTAG operation with a logic analizer. Both captures are pretty much identical, except on two points.

After erasing the Emb.Flash, on the original firmware the status is 0x39020, but with the github code, I get 0x19020. This is bit 17 being changed, however, bit 17 does not show in the gowin documentation!

Also, at the end of the programming cycle, instead of 0x39020, I get 0x11426 or 0x15422.

Everything else is the same in the JTAG conversation.

Another difference is the time it take to complete the programing. On the original firmware a bit below 5 seconds. With the compiled code from github, it goes up to 7-8 seconds. I'm guessing the issue is cause by some timing issue, but I'm still not able to pinpoint it.

If needed, I can provide the full JTAG capture, my pcb schematichs, anything you may need if you're able to look into this.

Many thanks.

[dmolinagarcia]

Hi,

It turned out, I wasn't compiling the right code. I had to use the jtag_process.c.gowin file which has several differences with the jtag_process.c file.

I'll provide more details later, but I've managed to program my gowin fpga now.

[dmolinagarcia]

More details

Indeed, in order to program gowin devices, it seems the jtag_process.c.gowin has to be used, instead of the jtag_process.c.

However, when exchanging those files, disable_irq and enable_irq, called from within the jtag process, are not found. I added this to the jtag_process.c file:

__ALWAYS_STATIC_INLINE void enable_irq(void)
{
    __ASM volatile("csrs mstatus, 8");
}

__ALWAYS_STATIC_INLINE void disable_irq(void)
{
    __ASM volatile("csrc mstatus, 8");
}

Also, I get a linker error:

c:/users/daniel.molina/appdata/roaming/c-sky/cdkrepo/toolchain/xtgccelfnewlib/v2.6.1/r/bin/../lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld.exe: region RAM overflowed with stack
c:/users/daniel.molina/appdata/roaming/c-sky/cdkrepo/toolchain/xtgccelfnewlib/v2.6.1/r/bin/../lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld.exe: section .system_ram_data_region VMA [0000000022018000,000000002201bfff] overlaps section .stack_dummy VMA [000000002201741c,000000002201841b]
c:/users/daniel.molina/appdata/roaming/c-sky/cdkrepo/toolchain/xtgccelfnewlib/v2.6.1/r/bin/../lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld.exe: region `dtcm_memory' overflowed by 1052 bytes
collect2.exe: error: ld returned 1 exit status

So I need to amend the linker settings, in the bl702_flash.ld file from

MEMORY
{
    xip_memory  (rx)  : ORIGIN = 0x23000000, LENGTH = 1024K
    itcm_memory (rx)  : ORIGIN = 0x22014000, LENGTH = 8K
    dtcm_memory (rx)  : ORIGIN = 0x22016000, LENGTH = 8K
    ram_memory  (!rx) : ORIGIN = 0x22018000, LENGTH = 88K
    hbn_memory  (rx)  : ORIGIN = 0x40010000, LENGTH = 0xE00     /* hbn ram 4K used 3.5K*/
}

to

MEMORY
{
    xip_memory  (rx)  : ORIGIN = 0x23000000, LENGTH = 1024K
    itcm_memory (rx)  : ORIGIN = 0x22014000, LENGTH = 8K
    dtcm_memory (rx)  : ORIGIN = 0x22016000, LENGTH = 12K
    ram_memory  (!rx) : ORIGIN = 0x22019000, LENGTH = 84K
    hbn_memory  (rx)  : ORIGIN = 0x40010000, LENGTH = 0xE00     /* hbn ram 4K used 3.5K*/
}