Can't add breakpoints with gdb on Hifive1

HiFive1 Rev B
1

Hello everyone!

I have been playing with the Hifive1 for a few weeks and I have time and again been encountering a problem during debugging. I saw this post the other day, so I thought maybe I was doing it wrong. But today I tried the instructions explained there and still the same problem.

Below you can see what I have done. Basically connect to openocd, create a breakpoint anywhere in the code (in the image it’s main, but it also happens if I choose any other address), and try to run from the beginning. If instead of start or run I try to continue, the same problem arises.

This is during executing make run_gdb PROGRAM=owny BOARD=freedom-e300-hifive1 on one window and make run_openocd BOARD=freedom-e300-hifive1 on another. (Sorry but I can’t upload more than one image yet :sweat:).

Can't breakpoint.jpg1022×945 847 KB

As you can see everything looks fine until this error appears:
halted at 0x404 due to software breakpoint Error: Core got an exception (0xffffffff) while writing to 0x204005ca Error: Failed to write 2-byte breakpoint instruction at 0x204005ca Error: can't add breakpoint: unknown reason

In case you were wondering, I can upload to Hifive1 without apparent problems, so I don’t thinks it’s a problem with permissions in my system, and if I remember correctly, last week I tried to run some tests as root, and had the same problem…

Until now, the way I have been dealing with this is adding a loop before the code I want to debug so that I can execute the debugger before it executes and begin stepping from there, but this is a huge pain, as you can imagine.

Any ideas what might be wrong??
Thank you!

2

I believe gdb can’t currently put a breakpoint on a compressed instruction. Maybe can’t disassemble them as well?

3

Quick answer: make sure you have “expat-dev” or “libexpat1-dev” installed before you ran “make tools”.

Long answer:

You are getting a GDB warning, “cannot parse XML memory map.” That is the key.

addresses at 0x20000000 are in flash memory, not SRAM. The flash memory is basically read-only when you’re running your program. So to set a breakpoint there you (or GDB) need to use hardware breakpoints, not SW. (Try this manually using ‘hbreak’ instead of ‘break’)

OpenOCD knows about the flash memory region because we pass it a configuration file. It tries to tell GDB by passing it the memory map. GDB would then request hardware breakpoints automatically as needed. But the error you’re getting means GDB doesn’t understand the memory map.

You need the package installed when you build GDB in order to have it understand the memory map.

4

C should work now…

5

Oh, good. That’s the last piece of the C puzzle in place then.

6

After waiting +4 hours for the toolchain to compile on my poor old laptop it worked!! :grin: I really have to begin thinking about crosscompiling the toolchain on my workstation…

I still found some problems though, when I said GDB to start, it would only continue from where it was before, instead of beginning execution from _start, but I can work around that changing the pc directly.

I’ve actually been meaning to ask about this for some time, because I did not found it clear in the documentation. How does the memory hierarchy work on the Hifive1??

When we flash the Hifive1 we write to the off-chip flash memory and when the CPU begins execution it caches it into the instruction cache at address 0x80000000, right?
Or is it not cached and executed directly from flash? That’s what I understand by XIP. But then, what are the data and instruction SRAM for?
Where does the on-chip Scratchpad RAM come into play?

I know, so many questions! :sweat_smile:

Thank you!!! :blush:

7

I believe every instruction executed comes from the cache. It does not matter where that instruction appears in the memory map – in ROM, OTP, the RAM scratchpad, or the off-chip SPI flash – in every case the 32 bytes containing the instruction to be executed are copied into the cache.

But that’s mostly invisible to us. It looks as if the program is executing directly from the flash at 0x2000000.

0x8000000 is not the instruction cache, it’s the 16 KB SRAM scratchpad containing the stack and modifiable globals/static i.e. .data and .bss sections.

The instruction cache does not have an address.

1 Like
8

Ok, after reading your response and checking back with the docs, everything is much clearer now. :grinning:

Thank you!!

9

Hi,

I’m trying to use GDB, but I cannot make use of it. Please help me.

I’m using Ubuntu 16.04 in VMware on Windows 10.
I installed libexpat1-dev and downloaded the latest SDK and rebuilt the toolchain.

open a screen window.

$ screen /dev/ttyUSB1 115200

upload hello program.

$ make PROGRAM=hello upload

“hello world!” is displayed on the screen window.

run openocd on a window.

$ make run_openocd

run GDB on another window.

$ make run_gdb PROGRAM=hello
/home/osboxes/Work/freedom-e-sdk/toolchain/bin/riscv32-unknown-elf-gdb /home/osboxes/Work/freedom-e-sdk/software/hello/hello
GNU gdb (GDB) 7.12.50.20170109-git
…
Reading symbols from /home/osboxes/Work/freedom-e-sdk/software/hello/hello…done.
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
0x20400394 in __wrap__exit (warning: Can not parse XML memory map; XML support was disabled at compile time
code=0) at …/…/bsp/libwrap/sys/_exit.c:14
14 write(STDERR_FILENO, “\n”, 1);
(gdb)

I have the following messages on the openocd window.
Note I still have “warning: Can not parse XML memory map; XML support was disabled at compile time” message.

Info : accepting ‘gdb’ connection on tcp/3333
Info : Found flash device ‘issi is25lp128’ (ID 0x0018609d)

Set a SW breakpoint and run.

(gdb) break main
Breakpoint 1 at 0x20400070: file hello.c, line 5.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 2 at 0x20400070: file hello.c, line 5.
Starting program: /home/osboxes/Work/freedom-e-sdk/software/hello/hello
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x20400070

Command aborted.
(gdb)

I have the following messages on openocd window.

Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1)
riscv.cpu: target state: halted
halted at 0x404 due to software breakpoint
Error: Core got an exception (0xffffffff) while writing to 0x20400070
Error: Failed to write 2-byte breakpoint instruction at 0x20400070
Error: can’t add breakpoint: unknown reason

I restarted gdb and set a HW break point and run.
But the GDB command prompt never returns.

…
14 write(STDERR_FILENO, “\n”, 1);
(gdb) hbreak main
Hardware assisted breakpoint 1 at 0x20400070: file hello.c, line 5.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/osboxes/Work/freedom-e-sdk/software/hello/hello

The following messages is on the screen window.

trap

Progam has exited with code:0x00000003

The following messages is on the openocd window.

Info : JTAG tap: riscv.cpu tap/device found: 0x10e31913 (mfg: 0x489 (), part: 0x0e31, ver: 0x1)
riscv.cpu: target state: halted
halted at 0x404 due to software breakpoint

Am I missing anything?

Thanks.

10

I could set a breakpoint.

$ cat gdb.scr
target extended-remote localhost:3333
hb main
set $pc = 0x20000000
c
$ /home/osboxes/Work/freedom-e-sdk/toolchain/bin/riscv32-unknown-elf-gdb -x gdb.scr /home/osboxes/Work/freedom-e-sdk/software/hello/hello
…
Breakpoint 1, main () at hello.c:5
5 printf(“hello world!\n”);
(gdb)

Now I can debug using a GDB!

But I still have

warning: Can not parse XML memory map; XML support was disabled at compile time

message.

Quick answer: make sure you have “expat-dev” or “libexpat1-dev” installed before you ran “make tools”.

Do I need anything else?

Thanks.

11

It seems that next and step commands use the software breakpoint.

I have to fix the XML support issue …

12

Hello,

Just wondering… When you rebuilt the toolchain did you run make uninstall first?

I say this because, as you said, GDB is still telling you that it is compiled without support for parsing the XML memory maps, and the only way I can think of this happening is that it wasn’t recompiled after installing libexpat1-dev.

If you did do this, we would have to rethink the problem… :cold_sweat:

1 Like
13

Miguel,

Thank you for your reply.
By reading your message, I checked libexpat1-dev was installed correctly, and I found it was not.
Sorry for my bad.

Now gdb breaks at main() automatically and next and step commands work!

Thanks!

14

Hi sflin,
Would you show your way to solve your problem? Now, i meet the same problem with you. Thanks

15

If you have same problem which I had, i.e. you have “warning: Can not parse XML memory map; XML support was disabled at compile time” message, install libexpat1-dev and rebuild the toolchain.

$ sudo apt install libexpat1-dev
$ cd …/freedom-e-sdk # change dir to your SDK directory
$ make uninstall
$ make tools

16

It seems that the problem is different. Thanks for your reply.