Browse Source

Add debugging info into README.

master
flabbergast 5 months ago
parent
commit
930b40bef2
  1. 36
      README.md

36
README.md

@ -22,6 +22,42 @@ The filenames in the examples follow the convention that `main.s` is the main fi
## Miscellaneous
### Debugging
I did not set up any `Makefile` debugging targets (yet). One can use `JLinkExe` directly, or `JLinkGDBServer` and then `gdb`. Or, instead of JLinkExe, `openocd` also works somewhat -- but I've had limited "success" with it.
The commands are:
#### JLinkExe directly
JLinkExe -device FE310 -if JTAG -speed 4000 -si JTAG -jtagconf -1,-1 -autoconnect 1
After connecting to the board, one has a "command line" interface to the debugger. `?` will bring up help. The commands I use most often are `loadfile main.hex` to flash, `r` for reset, `g` for go (as in let the mcu run), `h` for halt, `s` for step one instruction, `regs` to display all the registers, `mem8` and `mem32` to read memory. `setbp HEXADDRESS` to set a breakpoint, `clrbp HANDLE` to clear a breakpoint.
The biggest downside to this is that JLinkExe does not read `elf`, so one has to have `main.list` open in a side window to make the connection with where in the program the execution currently is, or at which address one should set a breakpoint, etc.
An alternative is to run a gdb server and use `riscv32-elf-gdb` or something on top of that. So, run a JLink gdb server with
JLinkGDBServer -device FE310 -if JTAG -speed 4000 -jtagconf -1,-1
and then in another window gdb with
riscv32-elf-gdb main.elf
(or cgdb with `cgdb -d riscv32-elf-gdb main.elf`),
and then connect it to the jlink server with `tar ext :2331`. After that the normal gdb things apply. Like `mon[itor] help` (talks to the jlink process) will show which special commands does the jlink gdb server support; `mon regs` with show regs, `mon reset` will reset the mcu. Other useful gdb commands are: `load` (flash the firmware), `cont` (let the mcu run), `Ctrl+C` (halt the mcu), `disassemble` (show disassembly of the current function), etc... Cgdb will also show the corresponding portion of the source code, one can visually set breakpoints (space), step (f8), etc... `:help` will bring up cgdb help which also describes the keybindings (quit help with `:set nodis` or `:set dis` ... oh well).
#### TUI cheatsheet
Gdb TUI seems to work fine as well: `C-x C-a` in gdb; does not need anything beyond `gdb` itself, but it needs to be built into it (e.g. the SiFive toolchain-supplied gdb does not). Better layout with `tui new-layout rv {-horizontal src 2 regs 1} 2 status 0 cmd 1` and switch to it with `tui layout rv`. Then `tui reg all` to actually display the registers. `C-x 2` cycles through layouts (one of them has assembly view).
`C-x s` switches to "single key" mode; `q` switches out of it. Then: `c`ontinue, `d`own, `f`inish, `n`ext, `r`un, `s`tep, `u`p, `w`here.
Breakpoints just from the command line, so: `b[reak] file.s:LINENUM` or `b[reak] *ADDRESS` sets; `i[nfo] b[reakpoints]` lists; `d[elete] NUM` deletes.
#### openocd
When I run it with `openocd -f /usr/share/openocd/scripts/board/sifive-hifive1-revb.cfg` it does connect; but seems to often not do what's asked about it regarding the mcu. I suppose this improves with time.
### Commentary about the board
The [RED-V Thing][redv-thing] board carries SiFive's [FE310-G002] RV32IMAC microcontroller (with supporting crystals and flash), as well as a JLink debugger (actually licensed from Segger). This is very nice - no external hardware needed for flashing, _and debugging_ via JTAG, and a convenient access to UART0. (Most conveniently used using the non-open-source JLink software; but `openocd` also works.) The board is roughly compatible with SiFive's [Hifive1 RevB] board, to the point that Hifive1B firmware runs fine on the RED-V, except the RED-V is missing the LEDs and the (imo pointless) ESP32 wifi.

Loading…
Cancel
Save