OpenOCD fails memory accesses (progbuf=disabled, sysbus=skipped, abstract=disabled) during peripheral polling and stepping

[Deeptha1212]

I’m working with a custom RISC-V 64-bit SoC (derived from the Shakti processor family).
The PlatformIO support for this SoC is still under development, and I am part of the team building that integration.

When debugging through OpenOCD + PlatformIO:

• Peripherals from the SVD file appear in the debug view.
• A temporary breakpoint is set at main() as expected.
• OpenOCD is started externally in another terminal.
• PlatformIO connects to OpenOCD using a custom debug tool.

But OpenOCD repeatedly reports memory read failures.

---

Symptoms

1. Peripheral polling fails

Immediately after the breakpoint at main() is set, PlatformIO tries to refresh peripheral registers and fails:

PlatformIO debug console:

Internal error: Failed to update peripheral UART0 after memory reads

OpenOCD log:

Error: [riscv.cpu.0] Failed to read memory (addr=0x80006568)
  progbuf=disabled, sysbus=skipped (sysbus access failed), abstract=disabled

2. Stepping also fails

Whenever I try to step in or step out of the code in VS Code, OpenOCD reports the same type of error:

Error: [riscv.cpu.0] Failed to read memory (addr=0x11300)
  progbuf=disabled, sysbus=skipped (sysbus access failed), abstract=disabled

So the issue affects both SVD-based peripheral updates and standard debug flow (stepping) whenever the SVD file is given as input.

---

Environment

• OpenOCD: official upstream build
• OpenOCD launch command:

  openocd -f interface/jtag.cfg -f target/riscv.cfg

• PlatformIO platformio.ini:

  [env:secure-iot]
  platform = mg
  board = secure-iot
  framework = Apps
  monitor_speed = 115200
  monitor_port = /dev/ttyUSB1
  debug_svd_path = path/to/Secure_IoT.svd
  upload_protocol = ft2232
  debug_speed = 1000
  debug_tool = custom
  debug_port = localhost:3333
  
  debug_build_flags = -O0 -ggdb3 -g3
  build_type = debug
  
  ; Override GDB init sequence
  debug_extra_cmds =
      monitor halt

---

Logs

From OpenOCD:

Warn : [riscv.cpu.0] Failed to read memory via system bus.
Error: [riscv.cpu.0] Failed to read memory (addr=0x80006568)
  progbuf=disabled, sysbus=skipped (sysbus access failed), abstract=disabled
Error: [riscv.cpu.0] Failed to read memory (addr=0x60100)
  progbuf=disabled, sysbus=skipped (sysbus access failed), abstract=disabled
Error: [riscv.cpu.0] Failed to read memory (addr=0x20100)
  progbuf=disabled, sysbus=skipped (sysbus access failed), abstract=disabled
Error: [riscv.cpu.0] Failed to read memory (addr=0x11300)
  progbuf=disabled, sysbus=skipped (sysbus access failed), abstract=disabled
(repeats for multiple addresses)

From PlatformIO:

PlatformIO: Initialization completed
Internal error: Failed to update peripheral OTP after memory reads
Internal error: Failed to update peripheral UART0 after memory reads
PlatformIO: Resume the execution to `debug_init_break = tbreak main`

---

Important Observation

Manual memory reads in GDB do succeed, for example:

(gdb) x/x 0x11300
0x11300:  0x017c017c

So the hardware can return values from memory, but OpenOCD reports that progbuf, sysbus, and abstract are all disabled/skipped when memory accesses are triggered automatically (peripheral polling, stepping).

---

Hardware

• Custom RISC-V 64-bit SoC (derived from Shakti)
• Debug module is expected to support progbuf, sba, and abstract

---

Steps to Reproduce

1. Start OpenOCD with:

   openocd -f interface/jtag.cfg -f target/riscv.cfg

2. Launch a debug session in PlatformIO with the platformio.ini shown above.
3. Observe that:
   • Peripherals are listed, but register updates fail immediately after hitting the initial breakpoint at main().
   • Stepping in/out also fails with the same error.
4. Compare with manual GDB access (x/x <addr>), which works.

---

Question

• Is this an OpenOCD limitation with the debug module, or a configuration issue on my side?
• Why do manual GDB memory reads succeed, but OpenOCD reports all access paths (progbuf, sysbus, abstract) as disabled/skipped during automated operations?

[en-sc]

Thank you for the report!

Could you please launch OpenOCD with debug logging enabled:

openocd -f interface/jtag.cfg -f target/riscv.cfg -d3 -l <your-log-name>

And attach the log (probably archived, since it can get quite large).

[Deeptha1212]

Thank you for the quick response!

I launched OpenOCD with -d3 as suggested. Please find the log attached:

logopenocd.zip

[en-sc]

I've looked at the logs and here is what I have so far:

1. You are using some custom OpenOCD version based on not-so-recent RISC-V OpenOCD (older then !1136 which was a year ago). Is it possible to reproduce the issue on TOT RISC-V OpenOCD? If not, maybe you can share the source code of the version you are using?
2. You have gdb report_data_abort disable. Try running with gdb report_data_abort enable in the configuration file. See https://openocd.org/doc/html/Server-Configuration.html#index-gdb-report_005fdata_005fabort
3. AFAIU, the accesses always fail on the same addresses (0x601f8 for the access at 0x60100, 0x20110 for the access at 0x20100, etc.). Can the reproduction be minimized by running:

openocd -f interface/jtag.cfg -f target/riscv.cfg -d3 -l <your-log-name> -c init -c halt -c 'read_memory 0x20110 64 1' -c shutdown

[Deeptha1212]

Thanks for the suggestions.

Unfortunately, I’m not able to share my source code, and due to a hardware issue in the chip I’m using, I also can’t test with the latest (ToT) RISC-V OpenOCD at the moment.

However, I’ve collected the logs from my setup, which might help understand the issue. Please find them below:

platformio__oct9_09:34.log

[Deeptha1212]

Additionally I was able to get this log from platform io configuration. I assume that this log contains the request sent to openocd.

gdb.txt

[TommyMurphyTM1234]

You are using some custom OpenOCD version based on not-so-recent RISC-V OpenOCD (older then !1136 which was a year ago). Is it possible to reproduce the issue on TOT RISC-V OpenOCD? If not, maybe you can share the source code of the version you are using?

Unfortunately, I’m not able to share my source code

If your code is derived from the original OpenOCD or the RISC-V fork then, under GPL, you're obliged to make it available on request as far as I know.

and due to a hardware issue in the chip I’m using, I also can’t test with the latest (ToT) RISC-V OpenOCD at the moment.

Why not? Can't you rebase your custom changes on the top of the sources and try that?

Have you tried the other suggestions from @en-sc above?

[en-sc]

If your code is derived from the original OpenOCD or the RISC-V fork then, under GPL, you're obliged to make it available on request as far as I know.

@TommyMurphyTM1234, AFAIK this is only the case if the code is being distributed. @Deeptha1212 is free to modify and use OpenOCD however he likes).

However, I’ve collected the logs from my setup, which might help understand the issue. Please find them below:

Please, add -d3 or debug_level 3. In the current log there is not much to analyse:

> cat ~/Downloads/platformio__oct9_09.34.log
set log_output to "platformio__oct9_09:34.log"
Info : clock speed 10000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x100039d3 (mfg: 0x4e9 (IIT Madras), part: 0x0003, ver: 0x1)
Info : [riscv.cpu.0] datacount=12 progbufsize=0
Warn : [riscv.cpu.0] We won't be able to execute fence instructions on this target. Memory may not always appear consistent. (progbufsize=0, impebreak=0)
Info : [riscv.cpu.0] Vector support with vlenb=0
Info : [riscv.cpu.0] S?aia detected with IMSIC
Info : [riscv.cpu.0] Examined RISC-V core
Info : [riscv.cpu.0]  XLEN=64, misa=0x800000000014112d
[riscv.cpu.0] Target successfully examined.
Info : [riscv.cpu.0] Examination succeed
Info : starting gdb server for riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
riscv.cpu.0 halted due to undefined.
riscv.cpu.0 halted due to undefined.
0x20100000000
shutdown command invoked

In any case, it seems like the error did not reproduce. Please, post a -d3 log for the case when the error is being reported. I'm afraid there is not much I can do without it.

[TommyMurphyTM1234]

@TommyMurphyTM1234, AFAIK this is only the case if the code is being distributed. @Deeptha1212 is free to modify and use OpenOCD however he likes).

Yes, good point.

[Deeptha1212]

Please, add -d3 or debug_level 3. In the current log there is not much to analyse:
Thanks for the suggestion. I’ve added logs at debug_level 3 for better analysis.

The issue appears to occur when reading a whole block in this scenario.

I faced a similar issue at 0x40200, where the request was attempting to read all registers including write-only registers, which is why it failed to read the memory address.

I wasn’t initially sure what request was being sent to OpenOCD from PlatformIO, but with your help I was able to identify that it’s a read command trying to read 28 bytes at a time and is attempting to access write-only registers.

This command is from PlatformIO side
'Unable to read memory: Unable to read memory. (from data-read-memory-bytes 0x20200 28)'

I assume that read memory bytes (PlatformIO) corresponds to
mdb 0x20100 28.
debug_platformio.zip