I am developing a RISC-V based toolchain, and I am interested in buying the RevB board.
My main reason for getting one is to test my FTDI + OpenOCD toolchain with a working RISC-V debug module. My own setup will eventually include a different RISCV chip with a v0.13 debug module, and a JTAG interface through FTDI. I want to get my hands on a working debug module implementation first.
It is my understanding that the older board had an FTDI interface and the new one has a JLink OB. The older one is more similar to what I actually want to implement, but the fact that it uses v0.11 for its debug module worries me about potential version differences.
The docs for the G002 chip mention the ability to bypass the JLink OB and use an external JTAG header., as shown in:
I think it should be possible without any modifications to the board, although I haven’t tried it. According to the schematics, you can use the J1 connector to access JTAG signals and RESET. The board even has resistors between J-Link and these JTAG lines, so you probably will not damage anything if you use both JTAG connector and J-Link at the same time, but I’d recommend you to not connect to the J-Link interface after applying power to the board.
Hi!
I use a few i/o lines on the Raspberry Pi with the “bit-bang” adapter of OpenOCD and it works quite well. No need any JLink, USB, etc.
Two issues though: First, don’t use wiring too long or messy, and supply good thick grounds; in the bit-bang code there’s a teeny improvement to be made, putting a bit of delay between actuation of the TDO, TDI, and TCK signals–helps a lot; you will see weird jtag errors and attachment failures, and occasionally OpenOCD (yes, it’s buggy here) will hang freeze and need to be process-killed when signal noise and race conditions happen; annoying, but no biggee. Second, the fespi transport seems to do only 64K chunks at a time, nothing smaller, so code load is long and thus painfully slow; however, using RAM (0x80000000) as your target rather than flash (0x20000000) is significantly faster and really helps the spiral development process.
Can confirm that it’s possible to use an FTDI-based probe with HiFive1 RevB. I used Bus Blaster v3c with the following config:
adapter_khz 1000
interface ftdi
ftdi_device_desc "Dual RS232-HS"
ftdi_vid_pid 0x0403 0x6010
ftdi_layout_init 0x0c08 0x0f1b
ftdi_layout_signal nSRST -data 0x0200 -noe 0x0800
#Reset Stretcher logic on FE310 is ~1 second long
#This doesn't apply if you use
# ftdi_set_signal, but still good to document
#adapter_nsrst_delay 1500
set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x20000913
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME
$_TARGETNAME configure -work-area-phys 0x80000000 -work-area-size 0x400 -work-area-backup 0
flash bank onboard_spi_flash fespi 0x20000000 0 0 0 $_TARGETNAME
init
#reset -- This type of reset is not implemented yet
if {[ info exists pulse_srst]} {
ftdi_set_signal nSRST 0
ftdi_set_signal nSRST z
#Wait for the reset stretcher
#It will work without this, but
#will incur lots of delays for later commands.
sleep 1500
}
halt
#flash protect 0 64 last off
I also used the latest openocd Linux build from SiFive.
Yes, this will work just fine.
Also suggest for faster results of programming, put your code in SRAM rather than flash … changing the “flash bank” command to use address 0x80000000 instead; helps a lot. Then, when all is good you can retarget back to flash.
