E21 RTL bring up for JTAG interface

Sorry if this isn’t in the right category but it looks like the E21 Core forums have been archived.

I am building the RTL project from scratch in the Vivado tool flow for the Arty A7 board. It is generating errors when I launch the debugger in Freedom studio so I need help determining what is not connected properly. Here is the output from Freedom studio:

Open On-Chip Debugger 0.11.0+dev (SiFive OpenOCD 0.11.0-2022.08.0)
Licensed under GNU GPL v2
For bug reports:
debug_level: 0

Using JTAG
Error: Failed read (NOP) at 0x10; value=0x0, status=2
Error: failed write at 0x10, status=2
Error: failed read at 0x10, status=2
Error: failed write at 0x10, status=2
Error: failed read at 0x10, status=2
Error: Target not examined yet

The Verilog code configures the following signals.

assign system_clock = CLK100MHZ;
assign system_psd_test_clock_enable = 0;
assign system_debug_clock = CLK100MHZ;
assign system_external_source_for_core_0_clock = CLK100MHZ;
assign jd_0 = system_debug_systemjtag_jtag_TDO_data;
assign system_debug_systemjtag_jtag_TCK = jd_2;
assign system_debug_systemjtag_jtag_TDI = jd_4;
assign system_debug_systemjtag_jtag_TMS = jd_5;

assign system_debug_systemjtag_jtag_TDO_driven = 1;
assign system_debug_systemjtag_mfr_id = 11’b0;
assign system_debug_systemjtag_part_number = 16’b0;
assign system_debug_systemjtag_version = 4’b0;

assign system_debug_dmi_block = 1’b1;
assign system_debug_dmactiveAck = system_debug_dmactive;

assign system_debug_extTrigger_out_ack = system_debug_extTrigger_out_req;
assign system_debug_extTrigger_in_req = 2’b00;

assign system_reset_vector_0 = 32’h00000000;

assign system_meip_0 = 1’b0;

assign system_nmi_0_rnmi = 1’b0;
assign system_nmi_0_rnmi_interrupt_vector = 32’b0;
assign system_nmi_0_rnmi_exception_vector = 32’b0;

assign system_rtc_toggle = CLK10MHZ;

I have a reset loop that drives the reset signals for 16 clock cycles when the reset button is pressed.

Please let me know if any of you see something I have missed.


Hi @knfrey great question! I’m not at all familiar with RTL but your observation Error: Target not examined yet intrigues me. It is the same I’ve seen many times with my hardware asic SoC, the FE310-G002.

What is your openocd setup and configuration (tcl)? You can see how I do things in the fe310-g002.cfg file of RISC Five Easy As PI. More detail is in Demystifying OpenOCD

Are you using a USB JTAG device with the FT(2)232 chip? There’s a little trouble I found which I describe in fixing the FT chip glitch. It relates to the default configuration of the FT chip pin states.

Some other relevant discussions are here in the forums at Dmcontrol_stuck_in_infinite_loop and Understanding the PRCI clock path.

I was able to connect the board to Freedom Studio by changing the settings in the Makefile and OpenOCD.cfg files to point to the TIM.

Select the scratchpad in the Makefile as shown below

ifeq ($(LINK_TARGET),)
LINK_TARGET = scratchpad

Comment out the lines below in the OpenOCD.cfg file

#flash bank spi0 fespi 0x40000000 0 0 0 $_TARGETNAME_0 0x20004000
#flash protect 0 64 last off



The line
flash bank spi0 fespi 0x40000000 0 0 0 $_TARGETNAME_0 0x20004000
looks strange to me. It should be
flash bank spi0 fespi 0x20000000 0 0 0 $_TARGETNAME_0 0x10014000
because the SPI peripheral (QSPI0) is mapped to 0x10014000 on the FE310-G00x SoC; and you can certainly use 0x20004000 if you wish to preserve an already-flash’ed bootloader.

1 Like

This line is commented out in the OpenOCD.cfg file since I am targetting the TIM. The location is based on the address of the SPI which is set to 0x20000000. I didn’t change that part of the file. It was autogenerated by Freedom Studio.

1 Like