Debugging CH32V103R with Visual Studio Code on Ubuntu #2

As I wrote in the previous post regarding debugging on the macOS environment, I figured out a way to avoid the Restart (Ctrl+Shift F5) and Disconnect (Shift+F5) operation issues I found in my past Visual Studio Code on Ubuntu post. So, I tested my finding on Ubuntu also.

At first, I edited the /etc/group file to add my Ubuntu account to the plugdev group (ncpin is my account name on Ubuntu).



By doing this, I didn’t have to use the sudo command when I run the openocd command anymore. Since the Linux kernel sets the user group of the WCH-Link USB device to the plugdev group when the kernel detects the device according to the udev rule file /etc/udev/rules.d/50-wch.rules that I copied before, and if a user does not belong to the plugdev group, the user will need root privilege to access the WCH-Link USB device from a process like the openocd command.

I added the following line to the end of OpenOCD’s wch-riscv.cfg file.

$_TARGETNAME.0 configure -event gdb-detach { shutdown }

I replaced the contents of Visual Studio Code’s code-workspace JSON file as follows.

  "tasks": {
    "version": "2.0.0",
    "tasks": [
        "label": "run_openocd",
        "type": "process",
        "isBackground": true,
        "command": "${workspaceRoot}/openocd",
        "args": ["-f", "${workspaceRoot}/wch-riscv.cfg"],
        "problemMatcher": [
            "pattern": [
              "regexp": ".",
              "file": 1,
              "location": 2,
              "message": 3
            "background": {
            "activeOnStart": true,
            "beginsPattern": ".",
            "endsPattern": "."
  "folders": [
      "path": "."
  "launch": {
    "version": "0.2.0",
    "configurations": [
        "name": "gdb-openocd",
        "type": "gdb",
        "request": "attach",
        "executable": "exiti0.elf",
        "remote": true,
        "target": ":3333",
        "cwd": "${workspaceRoot}",
        "gdbpath": "riscv32-unknown-elf-gdb",
        "preLaunchTask": "run_openocd",
        "autorun": [
          "set mem inaccessible-by-default off",
          "set architecture riscv:rv32",
          "set remotetimeout unlimited",
          "monitor reset halt",

(Please note that this setting file assumes that both the openocd command and the wch-riscv.cfg file exists at the workspace root directory of the Visual Studio Code project)

With the above changes, I no longer needed to run the openocd command separately. When I started the debug operation, Visual Studio Code automatically ran the openocd command in the background, and the launched openocd command stopped when I chose the Restart (Ctrl+Shift F5) and Disconnect (Shift+F5) command. And I was able to start debugging again also, unlike before.

Debugging with Visual Studio Code

As part of testing GDB in the previous post, I checked to see if I could also debug the CH32V103R Mini Evaluation board with Visual Studio Code.

After installing Visual Studio Code, I added the Native Debug extension by WebFreak. This extension is mandatory for the following process.

At first, I saved a workspace of Visual Studio Code into the ch32v103/EVT/EXAM/EXTI/EXTI0/User/ directory that I used in the previous post and added this directory to the workspace also. Then I created a launch.json file by clicking create a launch.json file(1), (2) and selecting the GDB(3) item.

I replaced the contents of the created JSON file with the following.

	"folders": [],
	"launch": {
		"version": "0.2.0",
		"configurations": [
				"name": "OpenOCD",
				"type": "gdb",
				"request": "attach",
				"executable": "exiti0.elf",
				"remote": true,
				"target": ":3333",
				"cwd": "${workspaceRoot}",
				"gdbpath": "riscv32-unknown-elf-gdb",
				"autorun": [
					"set mem inaccessible-by-default off",
					"set architecture riscv:rv32",
					"set remotetimeout unlimited",
					"monitor reset halt",

Before starting the debugging with Visual Studio Code, I ran the openocd in a different terminal.

sudo ./openocd -f wch-riscv.cfg

I set a breakpoint in main.c and started debugging by selecting the Start Debugging (F5) item under the Run menu.

One thing I noticed is that Restart (Ctrl+Shift F5) and Disconnect (Shift+F5) didn’t work properly. I saw that openocd outputted libusb-related errors after those two commands. I was able to start debugging again by restarting the openocd process and selecting Start Debugging (F5). Other than those two it looked that debugging on Visual Studio Code worked as expected.

[Added on 2022-06-24]
I wrote a new blog that addressed how to solve Restart (Ctrl+Shift F5) and Disconnect (Shift+F5) operation issue in the above. Please check my new post in addition to this entry.

Testing the toolchain – GDB

As a final step of testing the toolchain, I tried GDB with the CH32V103R Mini Evaluation board. Unfortunately, the binaries that I built in this post didn’t include a binary of the GDB command. Therefore, I rebuilt the toolchain with the following revised ct-ng menuconfig options.

  • In the Target options menu, I enabled the Build a multilib toolchain.
  • In the C-library menu, I selected the newlib as the C library.
  • In the Companion libraries menu, I selected the newlib-nano and enabled the Additionally install newlib-nano libs into TARGET dir option for the newlib-nano.
  • In the Debug facilities menu, I enabled the gdb. (*New)

After removing the previous ${HOME}/x-tools directory, I built the toolchain that includes the GDB command.

sudo apt install python3-distutils python3-dev<br>ct-ng build

Please note that I installed additional python related packages to build GDB with Crosstool-NG.

I tested the riscv32-unknown-elf-gdb using the same CH32V103 example as the previous post. To generate debug information I added -g and -O0 to the GCC options in the Makefile (Here is the updated file).
I ran the openocd separately in a different terminal first as follows.

sudo ./openocd -f wch-riscv.cfg

Then I ran riscv32-unknown-elf-gdb and executed the following commands in the GDB (I typed in the bolded part).

nc-pin$ riscv32-unknown-elf-gdb
GNU gdb (crosstool-NG 1.25.0_rc2.1_7e21141) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
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-build_pc-linux-gnu --target=riscv32-unknown-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) set mem inaccessible-by-default off
(gdb) set architecture riscv:rv32
The target architecture is set to "riscv:rv32".
(gdb) set remotetimeout unlimited
(gdb) file exiti0.elf
Reading symbols from exiti0.elf...
(gdb) target extended-remote :3333
Remote debugging using :3333
HardFault_Handler () at ch32v10x_it.c:40
40	    while(1)
(gdb) load exiti0.elf
Loading section .init, size 0x38 lma 0x0
Loading section .vector, size 0x108 lma 0x38
Loading section .text, size 0x2a60 lma 0x140
Loading section .data, size 0x84 lma 0x2ba0
Start address 0x00000000, load size 11300
Transfer rate: 4 KB/sec, 2825 bytes/write.

Then I set a breakpoint at line 73 of the main.c and let the GDB continue to the breakpoint.

 (gdb) break main.c:73
Breakpoint 1 at 0x17f6: file main.c, line 73.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) cont

Breakpoint 1, main () at main.c:73
Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xcd in position 449: invalid continuation byte
73	    printf("EXTI0 Test\r\n");

After inputting the cont command to the GDB, I saw the output of printf("SystemClk:%d\r\n", SystemCoreClock); at line 71 of the main.c on the UART connection from the CH32V103. I also tried several next commands.

(gdb) next
78	        Delay_Ms(1000);
(gdb) next
79	        printf("Run at main\r\n");
(gdb) next
78	        Delay_Ms(1000);
(gdb) next
79	        printf("Run at main\r\n");
(gdb) next
78	        Delay_Ms(1000);

This time I just tried the limited number of the GDB commands. However, it looked that the GDB I built was working as expected.

Testing the toolchain – Interrupt

When I was looking into the sample codes of ch32v103 on the git hub as written in my previous post, I noticed that the sample codes are using a non-standard function attribute __attribute__((interrupt("WCH-Interrupt-fast"))) for the interrupt routines. This unsupported attribute resulted in the following warning message during the build.

warning: argument to 'interrupt' attribute is not "user", "supervisor", or "machine" [-Wattributes]

To find out how to handle the interrupt routine with the toolchain that I built, this time, I picked up an interrupt example in the ch32v103/EVT/EXAM/EXTI/EXTI0 (GitHub).

git clone<br>cd ch32v103/EVT/EXAM/EXTI/EXTI0/User

Then I created a Makefile in the ch32v103/EVT/EXAM/EXTI/EXTI0/User directory in the same way as before. Without modifying the ch32v10x_it.c (GitHub), the compiler gave me the warning message I mentioned and generated the following assembly code for EXTI0_IRQHandler() – one of the interrupt routines in the ch32v10x_it.c (Snipped from this exiti0.lst).

000018d8 <EXTI0_IRQHandler>:
  18d8: 1141               addi  sp,sp,-16
  18da: 4505               li  a0,1
  18dc: c606               sw  ra,12(sp)
  18de: 2c3d               jal 1b1c <EXTI_GetITStatus>
  18e0: c911               beqz  a0,18f4 <EXTI0_IRQHandler+0x1c>
  18e2: 6509               lui a0,0x2
  18e4: fe450513           addi  a0,a0,-28 # 1fe4 <__sf_fake_stdin+0xa4>
  18e8: 94ffe0ef           jal ra,236 <puts>
  18ec: 40b2               lw  ra,12(sp)
  18ee: 4505               li  a0,1
  18f0: 0141               addi  sp,sp,16
  18f2: a491               j 1b36 <EXTI_ClearITPendingBit>
  18f4: 40b2               lw  ra,12(sp)
  18f6: 0141               addi  sp,sp,16
  18f8: 8082               ret
  18fa: a001               j 18fa <EXTI0_IRQHandler+0x22>
  18fc: a001               j 18fc <EXTI0_IRQHandler+0x24>

This code will not work correctly since the compiler puts ret at the end of the interrupt function. The following is the output from the compiler that came with the MounRiver Studio for the same EXTI0_IRQHandler() with the non-standard function attribute __attribute__((interrupt("WCH-Interrupt-fast"))) (Snipped from this exiti0.lst).

000001ee <EXTI0_IRQHandler>:
   1ee: 4505               li  a0,1
   1f0: 2629               jal 4fa <EXTI_GetITStatus>
   1f2: c909               beqz  a0,204 <EXTI0_IRQHandler+0x16>
   1f4: 00002537           lui a0,0x2
   1f8: c0850513           addi  a0,a0,-1016 # 1c08 <_read+0xc>
   1fc: 105000ef           jal ra,b00 <puts>
   200: 4505               li  a0,1
   202: 2e19               jal 518 <EXTI_ClearITPendingBit>
   204: 30200073           mret

To get a similar result, I modified the function attribute for the three functions in the ch32v10x_it.c.

// [original]
void NMI_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));
void HardFault_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));
void EXTI0_IRQHandler(void) __attribute__((interrupt("WCH-Interrupt-fast")));

// [modified]
void NMI_Handler(void) __attribute__((interrupt("machine")));
void HardFault_Handler(void) __attribute__((interrupt("machine")));
void EXTI0_IRQHandler(void) __attribute__((interrupt("machine")));

I got the following output with this change (Snipped from this exiti0.lst).

000018da <EXTI0_IRQHandler>:
  18da: 7139               addi  sp,sp,-64
  18dc: d62a               sw  a0,44(sp)
  18de: 4505               li  a0,1
  18e0: de06               sw  ra,60(sp)
  18e2: dc16               sw  t0,56(sp)
  18e4: da1a               sw  t1,52(sp)
  18e6: d81e               sw  t2,48(sp)
  18e8: d42e               sw  a1,40(sp)
  18ea: d232               sw  a2,36(sp)
  18ec: d036               sw  a3,32(sp)
  18ee: ce3a               sw  a4,28(sp)
  18f0: cc3e               sw  a5,24(sp)
  18f2: ca42               sw  a6,20(sp)
  18f4: c846               sw  a7,16(sp)
  18f6: c672               sw  t3,12(sp)
  18f8: c476               sw  t4,8(sp)
  18fa: c27a               sw  t5,4(sp)
  18fc: c07e               sw  t6,0(sp)
  18fe: 2ca9               jal 1b58 <EXTI_GetITStatus>
  1900: c901               beqz  a0,1910 <EXTI0_IRQHandler+0x36>
  1902: 6509               lui a0,0x2
  1904: 02050513           addi  a0,a0,32 # 2020 <__sf_fake_stdin+0xa4>
  1908: 92ffe0ef           jal ra,236 <puts>
  190c: 4505               li  a0,1
  190e: 2495               jal 1b72 <EXTI_ClearITPendingBit>
  1910: 50f2               lw  ra,60(sp)
  1912: 52e2               lw  t0,56(sp)
  1914: 5352               lw  t1,52(sp)
  1916: 53c2               lw  t2,48(sp)
  1918: 5532               lw  a0,44(sp)
  191a: 55a2               lw  a1,40(sp)
  191c: 5612               lw  a2,36(sp)
  191e: 5682               lw  a3,32(sp)
  1920: 4772               lw  a4,28(sp)
  1922: 47e2               lw  a5,24(sp)
  1924: 4852               lw  a6,20(sp)
  1926: 48c2               lw  a7,16(sp)
  1928: 4e32               lw  t3,12(sp)
  192a: 4ea2               lw  t4,8(sp)
  192c: 4f12               lw  t5,4(sp)
  192e: 4f82               lw  t6,0(sp)
  1930: 6121               addi  sp,sp,64
  1932: 30200073           mret
  1936: a001               j 1936 <EXTI0_IRQHandler+0x5c>
  1938: a001               j 1938 <EXTI0_IRQHandler+0x5e>

I tested the outputted hex file with the CH32V103R Mini Evaluation board. I wired up a push switch to the GPIO PA0 pin as follows.

While the loop in the main() function outputted Run at main periodically to the UART output, the interrupt routine EXTI0_IRQHandler() outputted Run at EXTI whenever I pressed and released the button that I added.

In this way, I was able to make the interrupt routine work by applying the standard function attribute __attribute__((interrupt("machine"))). It also increased the object size slightly compared with the object generated by MounRiver’s modified GCC (92bytes vs. 26bytes. @.text section).
I tried a combination of a function attribute __attribute__((naked())) that will not generate prologue/epilogue codes to a specified function and an inline assembly routine to remove the instructions for pushing and popping registers to the stack and confirmed that it worked also. We should use the naked attribute carefully, as written here, though.

[Added on 2022-05-07]
I noticed that WCH explained their interrupt mechanism in the below YouTube video (The explanation starts from around 11min). It appears that they call it the “HPE mode.”
The Research of RISC-V for Embedded MCUs. – YouTube

[Added on 2022-06-24]
The following page might be also very useful to understand the interrupt of the CH32V series.
FreeRTOS on CH32V307 (

Testing the toolchain – CH32V103R

I tested the toolchain for RISC-V that I built on the Ubuntu 20.04 with a CH32V103R Mini Evaluation board (CH32V103R8T6). I used one of the sample codes on the GitHub – openwch/ch32v103. I cloned the repository first.

git clone<br>cd ch32v103/EVT/EXAM/GPIO/GPIO_Toggle/User

Then I created a Makefile as listed below in the ch32v103/EVT/EXAM/GPIO/GPIO_Toggle/User directory (GitHub).

# ----------------------------------------------------------------------
#  Macros for User App
# ----------------------------------------------------------------------
USER_OBJS	= main.o system_ch32v10x.o
APP_NAME	= gpio_toggle

# ----------------------------------------------------------------------
#  Macros for WCH common library sources
# ----------------------------------------------------------------------
WCH_DIR			= ../../../SRC

WCH_START_OBJS		= startup_ch32v10x.o

WCH_PERI_INC_DIR	= $(WCH_DIR)/Peripheral/inc
WCH_PERI_SRC_DIR	= $(WCH_DIR)/Peripheral/src
  ch32v10x_gpio.o ch32v10x_usart.o ch32v10x_rcc.o ch32v10x_misc.o

WCH_DEBUG_OBJS		= debug.o

WCH_LD_SCRIPT		= $(WCH_DIR)/Ld/Link.ld

# ----------------------------------------------------------------------
#  Macros for Common part
# ----------------------------------------------------------------------

# ----------------------------------------------------------------------
#  Build Options
# ----------------------------------------------------------------------
TOOL_PREFIX	= riscv32-unknown-elf
CC		= $(TOOL_PREFIX)-gcc
LD		= $(CC)
  -mabi=ilp32 -msmall-data-limit=8 -mno-save-restore \
  -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections \
  -Wunused -Wuninitialized -MMD
SFLAGS		= -march=rv32imac_zicsr $(COMMON_FLAGS)
CFLAGS		= -march=rv32imac $(COMMON_FLAGS)
LDFLAGS 	= -march=rv32imac $(COMMON_FLAGS) -T $(WCH_LD_SCRIPT) \
  -nostartfiles -Xlinker --gc-sections -Wl,-Map,$(MAP_FILE_NAME) \
  -specs=nano.specs -specs=nosys.specs

# ----------------------------------------------------------------------
#  Default Rules
# ----------------------------------------------------------------------
	$(CC) $(SFLAGS) $(INCLUDES) -o $@ -c $<

	$(CC) $(CFLAGS) $(INCLUDES) -o $@ -c $<

	$(CC) $(CFLAGS) $(INCLUDES) -o $@ -c $<

# ----------------------------------------------------------------------
#  Build Rules
# ----------------------------------------------------------------------
all: $(TARGETS)


	$(OBJCOPY) -O ihex $(ELF_FILE_NAME) $@
	$(OBJDUMP) --all-headers --demangle --disassemble $(ELF_FILE_NAME) > $(DUMP_FILE_NAME)

.PHONY : clean depend

-include $(DEPENDS)

I also copied the openocd and wch-riscv.cfg files I built before into this directory. I made and flashed a hex file of the GPIO_Toggle sample program by running make and openocd.

export PATH=$PATH:$HOME/x-tools/riscv32-unknown-elf/bin
sudo ./openocd -f wch-riscv.cfg -c init -c halt -c "program gpio_toggle.hex" -c exit

I used a WCH-Link to flash the CH32V103R Mini Evaluation board this time.

I connected between the P1 header PA0 pin and theP4 header LED1 pin by a jump wire to see the toggling of the GPIO PA0 pin as the blinking of the LED1 (The small blue LED at the bottom right corner).