I run openocd:

openocd -f ~/openocd-cfg/if_rv_dbg_plus.cfg -f ~/openocd-cfg/tgt_702.cfg

and I get:

Open On-Chip Debugger 0.11.0+dev-02230-g347395372 (2022-02-16-03:05)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'ftdi vid_pid' not 'ftdi_vid_pid'
DEPRECATED! use 'ftdi channel' not 'ftdi_channel'
DEPRECATED! use 'ftdi layout_init' not 'ftdi_layout_init'
Ready for Remote Connections
Warn : `riscv set_prefer_sba` is deprecated. Please use `riscv set_mem_access` instead.
Info : clock speed 4000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x20000e05 (mfg: 0x702 (<unknown>), part: 0x0000, ver: 0x2)
Info : [riscv.cpu.0] 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=0x40801125
[riscv.cpu.0] Target successfully examined.
Info : starting gdb server for riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : JTAG tap: riscv.cpu tap/device found: 0x20000e05 (mfg: 0x702 (<unknown>), part: 0x0000, ver: 0x2)
reset-assert-pre
reset-deassert-post
Info : Disabling abstract command writes to CSRs.
reset-init
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333

Now I try to run gdb:

~/bl_iot_sdk/toolchain/riscv/Linux/bin/riscv64-unknown-elf-gdb -x ~/openocd-cfg/702.init

I get:

Copyright (C) 2020 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-linux-gnu --target=riscv64-unknown-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/sifive/freedom-tools/issues>.
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".
The target architecture is set to "riscv:rv32".
(gdb) file build_out/main.elf
Reading symbols from build_out/main.elf...
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
0x230003a0 in vApplicationIdleHook ()
    at /home/ajit/bl_iot_sdk/components/platform/soc/bl702/bl702/bfl_main.c:82
82	}
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/ajit/work/uc/bl702/my_led/build_out/main.elf

but it is just stuck here without the (gdb) prompt and the LED doesn't blink.

    If your code runs in xip flash，should not program，otherwise in ram is ok

      9 days later
      7 months later
      7 months later

      ntn888
      Dear ntn888
      Hello. Sorry for replying to the old post. I bumped into the same situation as your original post and would like to ask for some help.

      As you mentioned in the last post, is the code below the one you typed in gdb?

      (gdb) file debug_file_name.elf
(gdb) target remote localhost:1025
(gdb) set $pc = 0x21000000
(gdb) set $mie = 0
(gdb) set $mstatus = 0x1880
(gdb) run

      The below is what I've got. If you could provide any kind of help, I would be very appreciate it.

      (gdb) file build_out/lvgl_demo.elf
Reading symbols from build_out/lvgl_demo.elf...
(gdb) target extended-remote localhost:1025
Remote debugging using localhost:1025
lv_color_fill (buf=<optimized out>, buf@entry=0x53372000, color=color@entry=..., px_num=544, px_num@entry=1024)
    at M1s_BL808_SDK/components/lvgl/lvgl/src/misc/lv_color.c:59
59              *buf32 = c32;
(gdb) set $pc = 0x21000000
(gdb) set $mie = 0
(gdb) set $mstatus = 0x1880
(gdb) run
Starting program: build_out/lvgl_demo.elf
Remote communication error.  Target disconnected.: Connection reset by peer.
        8 days later
        21 days later

        yjkimmy Setting $pc behind the back of GDB makes it angry. It can cache things (like register contents as an example - I don't know if that's the downfall here) that it "knows" about the target that become invalid when you do things like this. Jumping through reset also invalidates things ike cached copies of local value because $sp is just one of many, many state components that's modified during reset.

        If you really need to debug it, you'll probably have to turn up remotedebuglevel and study the packets going over the wire to compare against official GDB protocol.

        Are you trying to debug a BL702 or are you trying to debug WITH the BL702 using something like Sipeed module on an for their $3.50 board? usb2uartjtag from https://github.com/sipeed/RV-Debugger-BL702 was quite good.

        I found setting $pc to reset and doing a 'cont' instead of a 'run' was pretty happy, but it's been a while since I've used this combination. (This snippet MIGHT be from a different RISC-V board of mine. It's hard to tell.)

        define reboot
  set $pc = 0
  cont
end
            Write a Reply...
            @ 2025 Bouffalo Lab (Nanjing) Co., Ltd. All rights reserved.