Suggestion tangnano flash programming
the-snowwhite opened this issue · comments
Hi
I have with success programed my tang nano with your tool, both:
openFPGALoader -m -b tangnano impl/pnr/*.fs
and
openFPGALoader -m -b littleBee impl/pnr/*.fs
Give a successful (volatile) flash
However (as stated) the -f option does not work (yet) and I would like to hear if you have plans for implementing the -f (flash) programming option any time soon for the GW1N-1 chip ?
Reason is that I cannot get the GOWIN linux version of the programmer to work on the tang nano (kde neon 18.04).
Hi,
Thanks for your feedback.
Yes it's planned to validate the flash programming for the GW1N-1. Currently, the real problem is the usb-jtag converter: it is a ft2232 clone based on ch552 ( https://github.com/diodep/ch55x_jtag). I have added workaround to use it but, currently, time to flash is awfully slow and, consecuently, it's difficult to debug and I don't have other GW1N-1 board.
My second problem is: I have just discover an regression, in flash mode, since commit 9c9348f
I need to fix this with littleBee before retrying tangNano.
Hi,
I've fixed my regression but I need to check all others FPGA before pushing this fix.
I've started to work on GW1N-1 flash support, but ch552 is a painful... Maybe I need to bypass this device to focus on flash compatibility in a first time.
I've updated repository. Flash programming for GW1N-1 is now supported. But to do this I've used an external JTAG probe. I need to improve ch552g workaround...
Perhaps it is much better to fix issue in ch552 side?
Do you have description of issue that you workaround?
It's true, but the question is to know if this issue is due to something wrong in my code or in the ch552 firmware (I haven't able to find an ft2232C based eval board to test).
If it's a bug related to the probe it's required to explain how to upgrade firmware with one where this issue is fixed.
The issue is quite simple: after a small serie of transactions ftdi_write_data always fails (I don't remember error code but maybe LIBUSB_ERROR_IO)
I'm tempted to capture the JTAG TDI signal with a signal analyzer and compare how the GoWin Programmer does it with openFPGALoader, if you think that might help finding out what's missing?
Again: openFPGALoader is perfectly able to deal with flash for all supported models (and I assume for others too). If flash programming is not working with the tang nano it's because there is something wrong with transaction between openFPGALoader and the ch552 firmware. In fact I have one tang nano with a jumper to disable the onboard interface (and to allows using an external probe) and I'm perfectly able to write bitstream into internal flash.
I have already dumping USB transfer to try to see how to deal with this specific interface, alas I have never found the (I assume) small detail.
It's not to say this tang nano's version will never been fully supported (and I expect to find hook): I try, regularly, to rework this but unfortunately is, currently, a fail :(
It's been a long time since I last did any USB debugging and the software I used isn't available any more, but I should be able to do it. Would it help with a USB capture of the GoWin Programmer writing to flash?
I should read before I post, sorry.
I read somewhere that the RAM should be cleared before writing to flash, such that it doesn't run anything while writing. Don't know if you already tried or openFPGALoader already does it?
to dump usb traffic: wireshark is THE tool to use. I have a (uggly) piece of python code to analyse MPSSE sequence to display each transaction
again issue isn't related to the sequence of operation between openFPGALoader and gowin. It's between openFPGALoader and ch552. Maybe a too big transaction, a read required somewhere to flush endpoint buffer or something like this.
I haven't a tang nano 1k (new version of tang nano) with BL702 instead of ch552, but for 4K and 9K (BL702), trenz littlebee (ft2232), runber (ft232) and honeycomb (stm32 firmware) everything is perfectly working. I have another GWN-1 without onboard probe and it's works too.
Until I will able to find why ch552 stalls: flash programming with the tangnano will not possible :-/ and since sipeed has replaced orignal tang nano with 1k model I'm not sure to be able to re-order board if something goes wrong.
I can send you a Tang Nano if you want it?
Thanks but I have a working tang nano and I have bought some ch552 breakout board to be able to do some tests without FPGA or with another FPGAs.
In fact I have one tang nano with a jumper to disable the onboard interface (and to allows using an external probe) and I'm perfectly able to write bitstream into internal flash.
May I ask, are there any instruction on how to flash a nano tang with an ch552 externally ?
I am also one of the lucky ones :) updated ch552 firmware, built and used latest master branch of openFPGALoader, made sure that the cable argument is set to ch552_jtag, all with no luck, always going to 100% and then reporting a checksum error
Jtag frequency : requested 2.50MHz -> real 2.00MHz
Erase SRAM DONE
Erasing FLASH: [ ] 0.00%DONE
Erasing FLASH: [==================================================] 100.00%
Done
write Flash: [==================================================] 100.00%
Done
CRC check : FAIL
Read: 0x00000000 checksum: 0x7da3
Even tried switching to a Windows machine, but not even the GoWin EDA can write to it....
I Guess tangnano with ch522 are next to useless as they are now, even sipeed support asks us to buy a newer 1k one as a solution.
In short, I much more prefer to have a botched up tangnano with a pico jtag hanging on it's side with flash programming working, than only an sram option.
If no instructions exist, I will just have to attach something on the flash and program it without any power connected to the tangnano board usb and make a PR for your repo webpage in order to help anyone else.