During scan openjocd assumes progbuf is available. This is OPTIONAL. Scan fails on this.

[InspireSemi]

Error: 19418 1342611 program.c:203 riscv_program_insert(): [riscv.cpu] Unable to insert program into progbuf, capacity would be exceeded (progbufsize=0).
Error: 19419 1342611 target.c:681 target_examine_one(): [riscv.cpu] Examination failed
Debug: 19420 1342611 target.c:682 target_examine_one(): [riscv.cpu] examine() returned error code -4
Debug: 19421 1342611 target.c:1782 target_call_event_callbacks(): target event 20 (examine-fail) for core riscv.cpu
Debug: 19422 1342611 target.c:3009 handle_target(): [riscv.cpu] Examination failed. Polling again in 5000ms
Debug: 19423 1342611 target.c:3002 handle_target(): [riscv.cpu] target_poll() -> -4, next attempt in 5000ms

[InspireSemi]

My .cfg file:

#debug verbosity 0-4 (2 normal error+warn; 3 debug; 4 extremely verbose)
debug_level 4

adapter speed 10000

adapter driver remote_bitbang
remote_bitbang host localhost
remote_bitbang port 43860
#remote_bitbang_port $::env(JTAG_VPI_PORT)

set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME -rtos hwthread
#ThreadX, FreeRTOS, eCos, linux, ChibiOS, Chromium-EC, embKernel, mqx, uCOS-III, nuttx, hwthread, or auto

riscv set_reset_timeout_sec 3600
riscv set_command_timeout_sec 3600
riscv set_mem_access sysbus

gdb_port 3333

#riscv set_mem_access off

#use system bus access vs program buffer for mem access

init
echo "Ready for Remote Connections"

[TommyMurphyTM1234]

I thought that this assumption by OpenOCD that the target implements a progbuf had been addressed previously? At least for debug spec 0.13 or later targets? E.g. see here:

• OpenOCD should support targets that don't implement a program buffer #112 (comment)
• Add support for system bus master, and for targets that don't have any program buffer #203

[en-sc]

@InspireSemi, can you please provide more context?
To triage the issue the log prior to the error is also needed -- currently it is unclear what is the program the debugger attempts to run here.
debug_level 3 should be enough.

[InspireSemi]

This is during initial connection to the target. It has not gotten to opening up the gdb connection yet in openocd.

BTW: The "other" openocd (upstream) does not exhibit this behavior.
I have been using it, but wanted to switch over to the riscv one, based on what looks like you are pulling from upstream back into this version.

[TommyMurphyTM1234]

To echo what @en-sc said earlier, you'll probably need to capture and attach the verbose openocd -d3 log if you want others to look into this issue. The log fragments posted so far are insufficient for understanding fully what's happening.

[InspireSemi]

log.txt
Here is a full log. Search for ERROR to find the issue. It is right afdter it reads the fp register.

Again this is before gdb can even be connected to openocd. It is in the initial connect stage.

[InspireSemi]

I am moving back to the openocd from openocd.org for now.
I need something that works for our use as well as customers use.

I will be more than happy (as time permits) to help you debug what is wrong.

[en-sc]

@InspireSemi, I'm sorry for the delay.

I have analyzed the logs.
The failure occurs while reading dcsr register.

Debug: 1968 308879 riscv-013.c:1776 set_dcsr_ebreak(): [riscv.cpu] Set dcsr.ebreak*
Debug: 1969 308879 riscv.c:5260 riscv_get_register(): [riscv.cpu] Reading dcsr from target

However, the abstract command fails with abstractcs.cmderr = 7 (other):

Debug: 1972 308879 riscv-013.c:893 execute_abstract_command(): [riscv.cpu] access register=0x2207b0 {regno=0x7b0 write=arg0 transfer=enabled postexec=disabled aarpostincrement=disabled aarsize=32bit}
Debug: 1991 309944 riscv-013.c:397 dump_field(): 66b w 002207b0 @17 -> + 00000004 @00; 20i
Debug: 1992 309944 riscv-013.c:405 dump_field(): write: command=0x2207b0 {control=0x2207b0}
...
Debug: 2011 311091 riscv-013.c:397 dump_field(): 66b r 00000000 @16 -> + 00000004 @00; 10i
...
Debug: 2023 312064 riscv-013.c:397 dump_field(): 66b - 00000000 @16 -> + 00000704 @00; 10i
Debug: 2024 312064 riscv-013.c:411 dump_field(): read:
Debug: 2025 312064 riscv-013.c:917 execute_abstract_command(): [riscv.cpu] command 0x2207b0 failed; abstractcs=0x704

Therefore, it is attempted to read dcsr via program buffer, which fails with the reported error:

Error: 2181 321258 program.c:203 riscv_program_insert(): [riscv.cpu] Unable to insert program into progbuf, capacity would be exceeded (progbufsize=0).

TLDR:

This is not obvious by the error reported to the user, but the examination fails because the debugger is unable to read dcsr via abstract command access. This seems like a hardware issue to me, though I would like to investigate further to be sure.

Why openocd.org version works?

Setting dcsr.ebreak* during examine() was introduced in f089815.
I'm curious to know, are you able to step/resume the hart on openocd.org version (the dcsr is read there also)?
If you can, please, provide the log from doing step or resume on either 21433e8 or the version from openocd.org.

[InspireSemi]

I have not seen any issues with openocd.org. I am able to connect, set SW breakpoints, resume, halt (ctrl-C), dump memory, single step, etc..

I will post the logs from running openocd.org.

I noticed that you are setting the ebreak bits in dcsr during initial connection and openocd.org is not doing this. It waits until gdb has connected to set them.

[InspireSemi]

cr2464_mmap.txt
gdb.output.txt
Here is the output from openocd.org.
It is through connecting to the target, openign gdb port, gdb connecting
I then executed: si, display/4i $pc, si

FYI: I had opened gdb with the wrong elf file.

[InspireSemi]

Do you need any further information? Logs, etc..
Would like to move over to this version of openocd.

I can spare some cycles in helping to debug if needed..

[en-sc]

@InspireSemi, again, sorry for the delay. This issue slipped my mind.

Do you need any further information?

Yes, It would be nice if you could collect OpenOCD -d3 logs for the following scenarios (using openocd.org version). They can be collected without running GDB if it is more convenient. In particular:

1. Reading dcsr:

.../openocd ... -d3 -l <log_name> -c init -c 'reset halt' -c 'reg dcsr' -c shutdown

1. Stepping:

.../openocd ... -d3 -l <log_name> -c init -c 'reset halt' -c step -c shutdown

[InspireSemi]

I will get to this in a day or so..