Can't write to Instruction Memory from gdb

[ColinBathe]

Hi Stephen, (love the project!)

I've managed to generate Neorv32 on a Max10 dev kit, compile and run the blink_leds example via the bootloader and connect to the cpu via openocd / gdb.

My problem is that I can't write to the Instruction Memory from gdb. This then means that the load command doesn't work in gdb amongst other issues.

gdb log

>>> target extended-remote localhost:3333
>>> set {int}0x80000000 = 0x1234
>>> x 0x80000000
0x80000000:     0x00001234
>>> set {int}0x00000000 = 0x1234
Cannot access memory at address 0x0
>>> file main.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from main.elf...
>>> load
Loading section .text, size 0x36c lma 0x0
Start address 0x00000000, load size 876
Transfer rate: 7008 bits in <1 sec, 876 bytes/write.
>>>

openocd log

xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-03-25-17:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : J-Link V11 compiled Mar  3 2022 10:16:14
Info : Hardware version: 11.00
Info : VTarget = 3.290 V
Info : clock speed 8000 kHz
Info : JTAG tap: neorv32.cpu tap/device found: 0x0cafe001 (mfg: 0x000 (<invalid>), part: 0xcafe, ver: 0x0)
Info : datacount=1 progbufsize=2
Info : Disabling abstract command reads from CSRs.
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40801104
Info : starting gdb server for neorv32.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Target HALTED.
Ready for remote connections.
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Warn : Failed to write memory via program buffer.
Error: Target neorv32.cpu.0: Failed to write memory (addr=0x0)
Error:   progbuf=failed, sysbus=disabled, abstract=disabled
Error: Target neorv32.cpu.0: Failed to write memory (addr=0x0)
Error:   progbuf=failed, sysbus=disabled, abstract=disabled
Info : Disabling abstract command writes to CSRs.

(Note: The write to address 0x00000000 produced the first Failed to write to memory error and the the load command produced the second.)

I suspect that the issue may be in my openocd .cfg file (though I don't really know) so here it is.

adapter driver jlink
adapter speed 8000

transport select jtag

# ----------------------------------------------
# Target configuration
# ----------------------------------------------

set _CHIPNAME neorv32
set _JTAGID 0x0cafe001
jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id $_JTAGID

set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME.0 riscv -chain-position $_TARGETNAME

# ----------------------------------------------
# Access memory via program buffer
# ----------------------------------------------

riscv set_mem_access progbuf

# ----------------------------------------------
# Scratch pad RAM
# ----------------------------------------------

# work area ("scratch pad RAM"): beginning of (internal) DMEM, 256 bytes, requires(!) backup
$_TARGETNAME.0 configure -work-area-phys 0x80000000 -work-area-size 256 -work-area-backup 1

# ----------------------------------------------
# Expose NEORV32-specific CSRs
# ----------------------------------------------

riscv expose_csrs 4032=mxisa

# ----------------------------------------------
# Start session
# ----------------------------------------------

init
halt

echo "Target HALTED."
echo "Ready for remote connections."

Any ideas as to what I'm doing wrong?

[stnolting]

Hey Colin!

What does your processor setup (and the configuration) look like?

I think this might be caused by the boot configuration of your setup. If the internal bootloader is disabled (INT_BOOTLOADER_EN => false) the system uses the "Direct Boot" approach where the IMEM is initialized with the actual application code during synthesis. This also makes the IMEM a real ROM (so it is read-only) and would explain your error message:

>>> set {int}0x00000000 = 0x1234
Cannot access memory at address 0x0

You can find more information about this in the data sheet's section Boot Configuration.

Just enable the bootloader and you can happily write to the IMEM again. I know this is no perfect solution. You could also replace the default bootloader by a simple endless-loop. So the processor would run this loop until the debugger takes over.

[ColinBathe]

That sorted it! (and why didn't I think of that..)

Thanks for your help.