halted at 0x800001d8 due to debug interrupt

[sx2025]

I use this cfg file to config my openocd . // adapter_khz 1000

interface cmsis-dap

transport select jtag

set _CHIPNAME riscv jtag newtap $_CHIPNAME cpu -irlen 5

set _TARGETNAME $_CHIPNAME.cpu target create $_TARGETNAME riscv -chain-position $_TARGETNAME

init halt // my interface is cmsis-dap, my board has a core of E203 riscv .
when i run the cfg file with openocd , it always comes out a message which is 'halted at 0x800001d8 due to debug interrupt'. I cannot do anything . I want to listen to your advice. Is it an error of cfg file or some of errors in my riscv verilog file.

[TommyMurphyTM1234]

Why do you think that this is an error/anomaly? Your script has a halt command at the end so is going to put the target into debug halt after connecting.

What exactly do you mean by "I can't do anything"?

What happens if you run OpenOCD manually (outside of Eclipse) and then use the telnet interface to interact with it using the low level OpenOCD commands? For example:

# in one terminal
openocd -f <your-script>

# in another terminal
telnet localhost:4444
poll
reg
step
step

etc.

You should probably capture and attach a verbose openocd -d3 log to help with analysis.

[sx2025]

thank you for answering me. Because i am a rookie. I try to download my program into riscv . But it seems not working . And it also remind me 'halted at 0x800001d8 due to debug interrupt'. Whether i use halt or not ,it will still come out this infomation 'halted at 0x800001d8 due to debug interrupt'. I don't know why. Here are the debug infomations. 新建文本文档.txt

[TommyMurphyTM1234]

I try to download my program into riscv . But it seems not working .

I can't see any evidence of any attempt to load the program in your OpenOCD log.

And it also remind me 'halted at 0x800001d8 due to debug interrupt'. Whether i use halt or not ,it will still come out this infomation 'halted at 0x800001d8 due to debug interrupt'.

Possibly because your debug launch configuration in Eclipse is telling the target to halt (at main()?) after connecting? It's difficult to tell exactly what's going on when you are using so many things (Eclipse/plugins, GDB, OpenOCD) all at once.

It might be better to try to get things working using just OpenOCD and GDB from the command line first.

Aren't there existing resources that explain how to debug a Nuclei E203 RISC-V target using OpenOCD? For example?

• https://www.bilibili.com/read/cv28484104/
• https://www.rvmcu.com/community-topic-id-1628.html
• https://www.riscv-mcu.com/community-topic-id-913.html

I don't know why. Here are the debug infomations.

It's better to capture the log to a file and then attach/upload it rather than embedding the huge amount of text in a post.

[TommyMurphyTM1234]

To run OpenOCD and GDB standalone on the command line (outside of the scope of Eclipse) in order to simplify matters you should do something like this (this is off the top of my head so there may errors or omissions):

# In one terminal
openocd -c "debug_level 3; log_output openocd.log" -f e203.cfg

# In another terminal
riscv64-unknown-elf-gdb myprogram
target remote localhost:3333
load
break main
continue

It might be useful to see what this sort of basic debug session results in.

[sx2025]

Open On-Chip Debugger

load_image "E:\hbird\sdk\hel\Debug\hel.bin" 0x80000000 Core got an exception (0xffffffff) while writing to 0x80002108 keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (2381 ms). Workaround: increase "set remotetimeout" in GDB (It may have failed between 0x80000000 and 0x80002107 as well, but we didn't check then.)

it seems my riscv has some problems，maybe about clk. i use a board with 27M clk, while the e203 use 50M clk. By using pll i have an clock with 16.2Mhz. but the original verilog files use 16Mhz clk. And i have also devide a clk which is about 32.768khz . maybe they cause the errors,what's your opinion?

[TommyMurphyTM1234]

Open On-Chip Debugger

load_image "E:\hbird\sdk\hel\Debug\hel.bin" 0x80000000 Core got an exception (0xffffffff) while writing to 0x80002108 keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (2381 ms). Workaround: increase "set remotetimeout" in GDB (It may have failed between 0x80000000 and 0x80002107 as well, but we didn't check then.)

it seems my riscv has some problems，maybe about clk. i use a board with 27M clk, while the e203 use 50M clk. By using pll i have an clock with 16.2Mhz. but the original verilog files use 16Mhz clk. And i have also devide a clk which is about 32.768khz . maybe they cause the errors,what's your opinion?

If you are using an FPGA implementation of a RISC-V CPU/SoC then you need to ensure that it's fully functional before trying to debug against it. E.g. check all synthesis/P&R reports for any issues, check all clocks/resets, maybe double check functionality in simulation etc. However, attributing the above error to a clock issue seems like pure guesswork with no hard evidence to back it up.

[sx2025]

thank you ! i will examine my verilog files.