Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

UPDATE: issue burning FPGA #5

Closed
rabarar opened this issue Mar 18, 2023 · 30 comments
Closed

UPDATE: issue burning FPGA #5

rabarar opened this issue Mar 18, 2023 · 30 comments

Comments

@rabarar
Copy link

rabarar commented Mar 18, 2023 •
edited
Loading

I have a dock and accidentally burned the lite core - and now I can't burn the dock core.

Have I fried it or his it in a state that can be reset?
When I run openFPGALoad --detect I see the board

% sudo openFPGALoader --detect                          
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
index 0:
	idcode 0x81b
	manufacturer Gowin
	family GW2A
	model  GW2A(R)-18(C)
	irlength 8

but when I attempt to load the core, I get:

% sudo openFPGALoader -b tangprimer20k -f nestang-0.4-dock.fs 
write to flash
Jtag frequency : requested 6.00MHz   -> real 6.00MHz  
Parse file Parse nestang-0.4-dock.fs: 
Done
DONE
Jtag frequency : requested 2.50MHz   -> real 2.00MHz  
Jtag frequency : requested 10.00MHz  -> real 6.00MHz  
erase SRAM Done
Detail: 
Jedec ID          : ff
memory type       : ff
memory capacity   : ff
EDID + CFD length : ff
EDID              : ffff
CFD               : 
Detail: 
Jedec ID          : ff
memory type       : ff
memory capacity   : ff
EDID + CFD length : ff
EDID              : ffff
CFD               : 
RDSR : ff
WIP  : 1
WEL  : 1
BP   : f
TB   : 1
SRWD : 1
flash chip unknown: use basic protection detection
unlock blocks
Error: block protection is set
       can't unlock without --unprotect-flash
Error: Failed to program FPGA: Error: write to flash failed

UPDATE1:

I was able to burn the dock core and get the checkered patterned color blocks up when the core runs. I've had to use an external 6V supply as I can only burn the core using openFPGALoad on OSX - Linux fails. As such, I have to switch back over to linux to run the loader - but when I run it, it detects two gamepads but doesn't respond to the controllers at all

$ sudo ./loader/loader -c /dev/ttyUSB1 games/pacman.nes.hex
pacman.nes.hex transmitted over /dev/ttyUSB1 at baudrate 921600.
Found 2 gamepads
Opening gamepad /dev/input/event16
Opening gamepad /dev/input/event17

getting closer... but no roms running ... roms run successfully in the sim
@rabarar rabarar changed the title issue burning FPGA UPDATE: issue burning FPGA Mar 19, 2023
@nand2mario
Copy link
Owner

Try something like "loader pacman.nes".

The loader takes the binary rom (ines format), not the .hex file.

@rabarar
Copy link
Author

rabarar commented Mar 19, 2023 •
edited
Loading

okay - was able to load a rom! see the game running, but there's no response to the controllers. I'm using the NES original controllers...

Bus 007 Device 015: ID 0810:e501 Personal Communication Systems, Inc. SNES Gamepad

Also there's no sound via HDMI is that to be expected?

@rabarar
Copy link
Author

rabarar commented Mar 19, 2023

UPDATE2: gamepad -

so lsusb shows Personal Communication Systems, Inc. SNES Gamepad which I don't see in the gist sourced in the code... is that an issue?

https://gist.github.com/nondebug/aec93dff7f0f1969f4cc2291b24a3171

@nand2mario
Copy link
Owner

Sound: Are you on a TV or monitor? I ran into the no sound issue on a Sony TV too. I had a fix for that checked into master (unfortunately the code is in flux now).

Gamepad: that's probably the issue. Could you post the relevant lsusb -v part? That should show the vendor and product id.

@rabarar
Copy link
Author

rabarar commented Mar 19, 2023 via email

@nand2mario
Copy link
Owner

Your device 0810:e501 is actually in the gamepad list. So it seems to be something else.

Try pass -v to loader. It will print everything the loader passes to the fpga. Check if there are packets when you press controller buttons.

@rabarar
Copy link
Author

rabarar commented Mar 19, 2023 via email

@rabarar
Copy link
Author

rabarar commented Mar 19, 2023 via email

@rabarar
Copy link
Author

rabarar commented Mar 19, 2023

UPDATE:

Some points of clarification:

  1. I cannot get the Gowin software to recognize the FTDI USB port and use it to program... solely using openFPGALoader
  2. using OpenFPGALoader to load flash fails consistently
  3. using OpenFPGALoader to load SRAM works but takes more than a few attempts before it either loads 100% and reboots after loading to accept roms correctly from the loader

not sure if this is expected behavior or if this is an indication of a configurations/hw issue with the TangPrimer20K

@Chandler-Kluser
Copy link
Contributor

maybe this link can help you...

@rabarar
Copy link
Author

rabarar commented Mar 19, 2023 via email

@nand2mario
Copy link
Owner

It looks like a defective board or BL702 firmware bug to me. I have 3 tang primer 20k and the Gowin programmer works on all 3. Maybe Sipeed can help?

@rabarar
Copy link
Author

rabarar commented Mar 20, 2023 via email

@nand2mario
Copy link
Owner

I'm using windows Gowin programmer and openFPGALoader on Windows/Linux and Mac.

I haven't upgraded the firmware on this board. But afaik the BL702 firmware is closely related to this: https://github.com/sipeed/RV-Debugger-BL702

Try asking sipeed in places like here: https://github.com/sipeed/sipeed_wiki/issues

@rabarar
Copy link
Author

rabarar commented Mar 20, 2023 via email

@CoreRasurae
Copy link

I had this issue. My Tang Primer 20K Dock would always hang during the programming with openFPGALoader on Linux. I have reflashed the firmware of the BL702 and now I am both able to flash and load to load into SRAM without hanging, except that now the serial UART with the FPGA is not working. No communication at all. I have temporarily circumvented the problem by assigning a PMOD connector to an external USB to UART adapter and it not only works, as it is much more reliable loading games through this externall adapter, than going through the BL702.

@rabarar
Copy link
Author

rabarar commented Jul 14, 2023

How do I reflash the firmware on the BL702?

I had this issue. My Tang Primer 20K Dock would always hang during the programming with openFPGALoader on Linux. I have reflashed the firmware of the BL702 and now I am both able to flash and load to load into SRAM without hanging, except that now the serial UART with the FPGA is not working. No communication at all. I have temporarily circumvented the problem by assigning a PMOD connector to an external USB to UART adapter and it not only works, as it is much more reliable loading games through this externall adapter, than going through the BL702.

@Chandler-Kluser
Copy link
Contributor

I had this issue. My Tang Primer 20K Dock would always hang during the programming with openFPGALoader on Linux. I have reflashed the firmware of the BL702 and now I am both able to flash and load to load into SRAM without hanging, except that now the serial UART with the FPGA is not working. No communication at all. I have temporarily circumvented the problem by assigning a PMOD connector to an external USB to UART adapter and it not only works, as it is much more reliable loading games through this externall adapter, than going through the BL702.

this could be in a wiki page, could you provide us more details?

@CoreRasurae
Copy link

CoreRasurae commented Jul 15, 2023 •
edited
Loading

The procedure to generate and flash the BL702 usb2uartjtag is as follows:

git clone https://github.com/sipeed/RV-Debugger-BL702
cd RV-Debugger-BL702
git submodule init
git submodule update

cd bl_mcu_sdk
make APP=usb2uartjtag APP_DIR=../app CHIP=bl702 INTERFACE=/dev/ttyACM0

cd tools/bflb_flash_tool/
./bflb_mcu_tool --chipname=bl702 --port=/dev/ttyACM0 --xtal=32M --firmware="../../out/app/usb2uartjtag/usb2uartjtag_bl702.bin"

@rabarar
Copy link
Author

rabarar commented Jul 15, 2023 via email

@CoreRasurae
Copy link

Ubuntu 20.04 LTS

@rabarar
Copy link
Author

rabarar commented Jul 15, 2023 via email

@CoreRasurae
Copy link

I don't remember where I got it from, but it came from a zip file named:
toolchain_riscv_thead_linux64.zip

@rabarar
Copy link
Author

rabarar commented Jul 15, 2023 via email

@rabarar
Copy link
Author

rabarar commented Jul 15, 2023 via email •
edited
Loading

@rabarar
Copy link
Author

rabarar commented Jul 15, 2023 via email

@CoreRasurae
Copy link

Here it goes the compiled usb2uartjtag:
usb2uartjtag_bl702.zip

@CoreRasurae
Copy link

Maybe you forgot to update cmake to 3.26.4, it is mandatory on my Ubuntu to make a local installation of that cmake version.
With that added to the PATH and riscv toolchain, it gets straightforward.

@rabarar
Copy link
Author

rabarar commented Jul 18, 2023

so burning fails... am I missing something??

$ sudo ./bflb_mcu_tool --chipname=bl702 --port=/dev/ttyACM0 --xtal=32M --firmware=/home/robert/usb2uartjtag_bl702/usb2uartjtag_bl702.bin 
[19:56:37.260] - ==================================================
[19:56:37.260] - Chip name is bl702
[19:56:37.261] - Serial port is /dev/ttyACM0
[19:56:37.261] - Baudrate is 115200
[19:56:37.261] - Firmware is /home/robert/usb2uartjtag_bl702/usb2uartjtag_bl702.bin
[19:56:37.261] - Default flash clock is 72M
[19:56:37.261] - Default pll clock is 144M
[19:56:37.261] - ==================================================
[19:56:37.267] - Update flash cfg finished
[19:56:37.268] - EFUSE_CFG
[19:56:37.268] - BOOTHEADER_CFG
[19:56:37.271] - Create bootheader using /home/robert/src/NES/RV-Debugger-BL702/firmware/bl_mcu_sdk/tools/bflb_flash_tool/chips/bl702/img_create_mcu/bootheader_cfg.ini
[19:56:37.271] - Updating data according to </home/robert/src/NES/RV-Debugger-BL702/firmware/bl_mcu_sdk/tools/bflb_flash_tool/chips/bl702/img_create_mcu/bootheader_cfg.ini[BOOTHEADER_CFG]>
[19:56:37.273] - Created file len:176
[19:56:37.275] - Image create path: /home/robert/src/NES/RV-Debugger-BL702/firmware/bl_mcu_sdk/tools/bflb_flash_tool/chips/bl702/img_create_mcu
[19:56:37.275] - Config file: /home/robert/src/NES/RV-Debugger-BL702/firmware/bl_mcu_sdk/tools/bflb_flash_tool/chips/bl702/img_create_mcu/img_create_cfg.ini
[19:56:37.275] - Image hash is b'7bf22d2b8644ead66173b83728f792f9efaad2d71bb152646e9cb8b96462a053'
[19:56:37.275] - Header crc: b'233e4063'
[19:56:37.275] - Write flash img
[19:56:37.276] - ========= eflash loader config =========
[19:56:37.283] - Version: bflb_eflash_loader_v2.1.2
[19:56:37.283] - Program Start
[19:56:37.283] - ========= eflash loader cmd arguments =========
[19:56:37.283] - Config file: /home/robert/src/NES/RV-Debugger-BL702/firmware/bl_mcu_sdk/tools/bflb_flash_tool/chips/bl702/eflash_loader/eflash_loader_cfg.ini
[19:56:37.284] - serial port is /dev/ttyACM0
[19:56:37.284] - chiptype: bl702
[19:56:37.284] - ========= Interface is uart =========
[19:56:37.284] - com speed: 115200
[19:56:37.284] - Eflash load helper file: /home/robert/src/NES/RV-Debugger-BL702/firmware/bl_mcu_sdk/tools/bflb_flash_tool/chips/bl702/eflash_loader/eflash_loader_32m.bin
[19:56:37.284] - Eflash load helper file: /home/robert/src/NES/RV-Debugger-BL702/firmware/bl_mcu_sdk/tools/bflb_flash_tool/chips/bl702/eflash_loader/eflash_loader_32m.bin
[19:56:37.284] - ========= load eflash_loader.bin =========
[19:56:37.284] - Load eflash_loader.bin via uart
[19:56:37.284] - ========= image load =========
[19:56:37.291] - usb serial port
[19:56:37.341] - clean buf
[19:56:37.341] - send sync
[19:56:37.443] - ack is b''
[19:56:37.443] - retry
[19:56:37.443] - usb serial port
[19:56:37.494] - clean buf
[19:56:37.494] - send sync
[19:56:37.696] - ack is b'4f4b'
[19:56:37.726] - shake hand success
[19:56:37.736] - get_boot_info
[19:56:38.843] - FL0102 unknown
[19:56:38.843] - Not ack OK
[19:56:38.843] - FL0102 unknown
[19:56:38.843] - result: FL0102 unknown
[19:56:38.844] - fail
[19:56:38.844] - Img load fail
[19:56:38.844] - Load helper bin time cost(ms): 1559.5830078125
[19:56:38.844] - {"ErrorCode": "0003","ErrorMsg":"BFLB LOAD HELP BIN FAIL"}
[19:56:38.844] - Burn Retry
[19:56:38.844] - 0
[19:56:38.844] - Burn return with retry fail

@rabarar
Copy link
Author

rabarar commented Jul 18, 2023

Here it goes the compiled usb2uartjtag:
usb2uartjtag_bl702.zip

installed snap version of cmake and rebuilt without issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rabarar @Chandler-Kluser @CoreRasurae @nand2mario