GDB (Breakpoint) and OpenOCD problem

Hello,

I have the Artix-7 35T FPGA and I’m following the freedom platform github.

There was a problem while debugging using openocd and gdb.

The brakepoint does not work, and the s command also operates abnormally.

Please help me…

Attach the make run_gdb script below.

-VirtualBox:~/RISC-V/freedom-e-sdk$ sudo make run_gdb PROGRAM=demo_gpio BOARD=freedom-e300-arty
/home/moonhg/RISC-V/freedom-e-sdk/work/build/riscv-gnu-toolchain/riscv64-unknown-elf/prefix/bin/riscv64-unknown-elf-gdb software/demo_gpio/demo_gpio -ex “set remotetimeout 240” -ex “target extended-remote localhost:3333"
GNU gdb (GDB) 8.0.50.20170724-git
Copyright © 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying"
and “show warranty” for details.
This GDB was configured as “–host=x86_64-pc-linux-gnu --target=riscv64-unknown-elf”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from software/demo_gpio/demo_gpio…done.
Remote debugging using localhost:3333
0x204000ec in main (argc=, argv=) at demo_gpio.c:260
260 atomic_fetch_xor_explicit(&GPIO_REG(GPIO_OUTPUT_VAL), bitbang_mask, memory_order_relaxed);
(gdb) monitor reset halt
JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive, Inc.), part: 0x0000, ver: 0x2)
dtmcontrol_idle=5, dmi_busy_delay=5, ac_busy_delay=0
(gdb) monitor flash protect 0 64 last off
cleared protection for sectors 64 through 255 on flash bank 0
(gdb) load
Loading section .init, size 0x6c lma 0x20400000
Loading section .text, size 0xbbde lma 0x2040006c
Loading section .rodata, size 0x1154 lma 0x2040bc50
Loading section .eh_frame, size 0x68 lma 0x2040cda4
Loading section .data, size 0x9d0 lma 0x2040ce0c
Start address 0x20400000, load size 55254
Transfer rate: 736 bytes/sec, 6906 bytes/write.
(gdb) hb main
Hardware assisted breakpoint 1 at 0x2040006c: file demo_gpio.c, line 197.
(gdb) list 210
205
206
207 int a = 1234;
208
209 a = a + 1;
210
211 a = a + 10;
212
213 printf(”%d”, a);
214
(gdb) hb 209
Hardware assisted breakpoint 2 at 0x2040006e: file demo_gpio.c, line 209.
(gdb) c
Continuing.

Breakpoint 1, main (argc=0, argv=0x0) at demo_gpio.c:197
197 {
(gdb) c
Continuing.

Breakpoint 2, main (argc=0, argv=0x0) at demo_gpio.c:213
213 printf("%d", a);
(gdb) s
197 {
(gdb) s
213 printf("%d", a);
(gdb) s
Note: automatically using hardware breakpoints for read-only addresses.
Warning:
Cannot insert hardware breakpoint 0.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

0x20400772 in printf ()
(gdb) s
Single stepping until exit from function printf,
which has no line number information.
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1335). Workaround: increase “set remotetimeout” in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1002). Workaround: increase “set remotetimeout” in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1002). Workaround: increase “set remotetimeout” in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1016). Workaround: increase “set remotetimeout” in GDB
0x204007b2 in _vfprintf_r ()
(gdb) quit

and below are make_openocd error messages

Error: Couldn’t find an available hardware trigger.
Error: can’t add breakpoint: resource not available

How to solve this problem?

Thank you!

The SiFive core only supports two hardware breakpoints. Because the code resides in read-only flash software breakpoints did not work. Single step on source level in gdb requires sometimes two breakpoints, e.g. when stepping over code containing conditional branches. You have set a breakpoint at the beginning of your debug session, this blocks already one hw breakpoint.
You should disable this breakpoint before single stepping. This can be a bit anoying.

I complained about this long time ago, and, if I remember right, the E31/E51 cores were upgraded to 8 hw breakpoints; or at least this was the plan.

The updated E31 FPGA bitstream has 8 breakpoints:
https://dev.sifive.com/dashboard/deliverables/sifive_e31_fpga_eval_kit_bitstream/releases/v3p0/

Thank you very much everyone!!

It seems that it does not apply to rocket chip sources that can be compiled yet.

Not that you can also change

(gdb) hb main

to

(gdb) thb main

to have a temporary breakpoint at main() that still leaves the two hardware breakpoints for single stepping.