I have to add something to my previous mail. GDB no longer hangs, but produces the following error message:
-------------------------------------------------------------------------------- Run flash-remote function: ========================== flash-remote( elf_file = application.elf , openocd_path = openocd , probe_file = ../config/openocd_probe.cfg , chip_file = ../config/openocd_chip.cfg , ) -------------------------------------------------------------------------------- xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-dirty (2020-10-26-06:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html jtag Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: JTAG Supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (JTAG) Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 0 nTRST = 0 nRESET = 1 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : cmsis-dap JTAG TLR_RESET Info : cmsis-dap JTAG TLR_RESET Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1) Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7) Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3" Info : datacount=4 progbufsize=2 Info : Examined RISC-V core; found 1 harts Info : hart 0: XLEN=32, misa=0x40901105 Info : starting gdb server for riscv.cpu on 3333 Info : Listening on port 3333 for gdb connections Error: The 'gdb_port' command must be used before 'init'. Remote communication error. Target disconnected.: Success. make: *** [../config/makefile:622: flash] Error 1 make: Leaving directory 'C:/embeetle/beetle_projects/gd32vf103c_start/build' The main takeaway from this is the error message: Error: The 'gdb_port' command must be used before 'init'. I do not understand what this error message is trying to tell me. As you can see in my previous mail, I do invoke the 'gdb_port' command first before anything else. How can I solve this? Kind regards, Kristof Mulier Van: "kristof mulier" <kristof.mul...@telenet.be> Aan: "openocd-devel" <openocd-devel@lists.sourceforge.net> Verzonden: Dinsdag 27 oktober 2020 17:24:45 Onderwerp: [OpenOCD-devel] OpenOCD (or GDB) hangs when trying to flash a RISC-V chip from a single console. I'm running into quite a complicated problem. When I flash my RISC-V chip with two consoles - one for OpenOCD and another for GDB - the flash succeeds. When I try to flash it from a single console - a procedure I've successfully applied on countless ARM-based chips - it fails. I'll give more details below. FLASHING FROM TWO CONSOLES ====================== To flash my GD32VF103CBT6 chip (GD32VF103C-START board from GigaDevice) I spawn two consoles: one for OpenOCD and another for GDB. It kind of works - I have to increase the remote timeout before instructing the microcontroller to reset and run: # after loading the firmware to the chip: (gdb) set remotetimeout 3000 (gdb) monitor reset run But aside from this issue with, the firmware flashes successfully. However, I might miss some anomalies in the output that some of you can better detect. Therefore, I've added the OpenOCD and GDB output to this mail: - openocd_output.txt - gdb_output.txt And also the OpenOCD config files: - openocd_chip.cfg - openocd_probe.cfg The OpenOCD version is compiled by GigaDevice themselves. They followed the xPack build procedure from Liviu Ionescu. The result can be found here, for Linux: [ https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z | https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z ] for Windows: [ https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z | https://new.embeetle.com/downloads/beetle_tools/windows/openocd_giga_0.10.0_dev_64b.7z ] FLASHING FROM A SINGLE CONSOLE ======================== In Embeetle IDE we aim to do the flashing procedure in a single console. That's why we give the following .gdbinit file to GDB at startup: define flash-remote echo \n echo \n-------------------------------------------------------------------------------- echo \n Run flash-remote function: echo \n ========================== echo \n flash-remote( echo \n elf_file = $arg0 , echo \n openocd_path = $arg1 , echo \n probe_file = $arg2 , echo \n chip_file = $arg3 , echo \n ) echo \n-------------------------------------------------------------------------------- echo \n file $arg0 target extended-remote | $arg1 -f $arg2 -f $arg3 -c "gdb_port pipe; log_output openocd.log" load monitor reset run monitor shutdown quit end As you can see, this .gdbinit file instructs GDB to launch OpenOCD and hook into its GDB server. When launching GDB, we not only pass this .gdbinit file, but also give it a couple of flags on the commandline. This is our flash target in the makefile, so you can see the flags for yourself: GDB_FLASHFLAGS = \ -n \ -batch \ -x ../config/.gdbinit \ -ex "flash-remote $(ELF_FILE) openocd ../config/openocd_probe.cfg ../config/openocd_chip.cfg" \ .PHONY : flash flash : $(ELF_FILE) $(GDB) $(GDB_FLASHFLAGS) In short, GDB starts in batch mode, is given a .gdbinit file with a user-defined-function and that same function is then called with the proper arguments. We've applied this technique to countless other chips (ARM-based ones) and it always worked. However, when running this flash target, I get the following output: -------------------------------------------------------------------------------- Run flash-remote function: ========================== flash-remote( elf_file = application.elf , openocd_path = openocd , probe_file = ../config/openocd_probe.cfg , chip_file = ../config/openocd_chip.cfg , ) -------------------------------------------------------------------------------- xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-dirty (2020-10-26-06:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html jtag Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: JTAG Supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (JTAG) Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : cmsis-dap JTAG TLR_RESET Info : cmsis-dap JTAG TLR_RESET Info : Then it hangs. Nothing happens - I have to kill the process. There is no openocd.log file to be found. What could the problem be? Kind regards, Kristof Mulier _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
