issues flashing a nanoCH32V203

[kxygk]

I should preface this with.. I'm not totally sure what I'm doing here.. so maybe I'm missing some obvious step,

But, I'm having issues flashing a nanoCH32V203

https://github.com/wuxx/nanoCH32V203

The board ticks off all my requirements:

• cheap
• has an RTOS
• has an SD card slot
• good voltage tolerances (I think?) so I can run it off a battery safely

However the official documentation is sparse.. and mostly Windows-centric

I've tried to flash the ch32fun examples and am having trouble getting it work

I installed the prerequisite packages from the Ubuntu repo

I cloned this repo and built everything. This part seems to work just fine

git clone https://github.com/cnlohr/ch32fun.git
cd build_scripts/
make

I then go in to examples_v20x/blink and run make, but the flashing step seems to fail

riscv64-unknown-elf-gcc -E -P -x c -DTARGET_MCU=CH32V203G6U6 -DMCU_PACKAGE=2 -DTARGET_MCU_LD=2 -DTARGET_MCU_MEMORY_SPLIT= ../../ch32fun//ch32fun.ld > ../../ch32fun//generated_CH32V203G6U6_.ld
riscv64-unknown-elf-gcc -o blink.elf ../../ch32fun//ch32fun.c blink.c   -g -Os -flto -ffunction-sections -fdata-sections -fmessage-length=0 -msmall-data-limit=8 -march=rv32imac -mabi=ilp32 -DCH32V20x=1 -static-libgcc -I/usr/include/newlib -I../../ch32fun//../extralibs -I../../ch32fun/ -nostdlib -I. -Wall  -Wl,--print-memory-usage -Wl,-Map=blink.map -lgcc -T ../../ch32fun//generated_CH32V203G6U6_.ld -Wl,--gc-sections
Memory region         Used Size  Region Size  %age Used
           FLASH:         880 B        32 KB      2.69%
             RAM:           0 B        10 KB      0.00%
riscv64-unknown-elf-objdump -S blink.elf > blink.lst
riscv64-unknown-elf-objcopy  -O binary blink.elf blink.bin
riscv64-unknown-elf-objcopy -O ihex blink.elf blink.hex
make -C ../../ch32fun//../minichlink all
make[1]: Entering directory '/home/kxygk/Projects/extern/ch32fun/minichlink'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/kxygk/Projects/extern/ch32fun/minichlink'
../../ch32fun//../minichlink/minichlink -w blink.bin flash -b
Found programmer in IAP mode. Attempting to eject it out of IAP.
Eject command sent (1)
make: *** [../../ch32fun/ch32fun.mk:351: cv_flash] Error 253

The board should be able to program the micro (as far as I understand their documentation). If you plug it in over USB without doing anything and run make then the last lines will read

../../ch32fun//../minichlink/minichlink -w blink.bin flash -b
VID:0x1209, PID:0xb003
Error: Could not initialize any supported programmers

If you follow the flashing instruction https://github.com/wuxx/nanoCH32V203

Keep pressing the BOOT button on the development board, then press and release the RST button, and finally release the BOOT button to make the chip enter the bootloader.

Then you get the previous error

../../ch32fun//../minichlink/minichlink -w blink.bin flash -b
Found programmer in IAP mode. Attempting to eject it out of IAP.
Eject command sent (1)
make: *** [../../ch32fun/ch32fun.mk:351: cv_flash] Error 253

I've tried both ports on the board with no luck.

I'm guessing it's having some issue "Attempting to eject it out of IAP". But I can't find where this is documented

Before the example I've also tried going in to the minichlink directory and running minichlink (after running make) - but I was giving me similar errors

I'm running Ubuntu 24.04 noble

I've tested with two boards - same errors

If anyone has any thoughts or suggestions, please let me know :))

PS: I originally wanted to port some Arduino code.. but I couldn't get Arduino to see the board in the "Port" menu (and no idea how to debug further). Obviously getting Arduino running would be preferable, but it's very difficult to deal with when things break

[biemster]

There are two ways to program the v203, with an external programmer (for example a wch linkE) or using the internal bootloader. minichlink requires an external programmer, but it looks like you want to try the internal bootloader. For that you need a separate application, for example wchisp.

You should then only do a build in the example directory: make clean build, instead of make which does a build+program. And then use wchisp to flash the resulting .bin file.

[kxygk]

Fantastic!

That solved everything.

Just to document the process for the next poor soul..

• I downloaded the latest release of wchisp
• I modified blink.c - changing #define PIN_1 PA0 to #define PIN_1 15 (the magic 15 number come from this confusing PDF https://github.com/wuxx/nanoCH32V203/blob/master/hardware/nanoCH32V203.pdf )
• ran make clean build
• ran wchisp flash blink.bin
• and it blinks!

---

I actually have a WCHLink-E. Am I understanding correctly that if I use that, I should be able to debug through gdb? (which is not possible through USB?)

I'd need to solder the header pins on and then .. well I'm not quite sure where I'd plug in the U_Rx U_Tx pins. (I'm guess from that previous PDF it's PA9 and PA10 b/c they have T_URX T_UTX label)

the README says minichlink has a gdbserver, but when I flash, how do I hang and wait for the debugger? Is there a default port it's on?

From when I did this a million years ago with a bluepill it looked something like

> target remote localhost:3333
> monitor reset halt
> load blinky.bin

[biemster]

With the linkE you are indeed able to debug through gdb. Don't use the linkE Rx/Tx for that though, but SWCLK/SWDIO and connect it to the same swd pins on the v203 (you'll need that confusing PDF again). You can then start minichlink -G which is the debug server, and then exactly the commands you did a million years ago.

(We have a very lively discord where you can also get help for these things, invite in the README)

[kxygk]

Okay, I managed to deadbug it partway (work in progress)

Walking through the steps for the next poor soul's benefit

In the PDF, in the upper left box

SWDIO is labeled PA13
SWCLK is labeled PA14

You then check in the right hand "Header" box where this comes out on the board.
On the silk screen the "P" part is skipped. So this is the A13 and A15 holes
(took me a sec to figure this out haha)
You can distinguish the sides b/c one has the 3V3 pin (no idea what 3V3 mean.. 3 Volts.. 3 something?- isn't it usually 3.3V? anyway...)

You can wire any of the Ground wires to the WCHLink Ground.
You then need to wire the 5V to a 5V pin.
Wiring 3V to 3V3 does not work!
Not totally sure why..
Seems some critical component on the board requires the 5V.
So even though the micro is 3V tolerant,
it's not clear what voltages the board will tolerate in the end
All TBD b/c I will need this running on off battery eventually.

Once you have all 4 wires connected you can run minichlink

Output looks like this

Found WCH Link
WCH Programmer is CH32V307 version 2.11
Full Chip Type Reply: [8] 82-0d-05-05-20-31-05-00-03
Detected: CH32V20x
Setup success
Flash Storage: 64 kB
Part UUID    : 7a-d8-ab-cd-e2-b4-bc-0f
PFlags       : e3-39-e3-39
Part Type (B): 20-31-05-00
Using binary blob write for operation.
Read protection: disabled
Interface Setup

If it's not wired up then the output looks like this

Found WCH Link
WCH Programmer is CH32V307 version 2.11
Already Connected
Full Chip Type Reply: [4] 81-55-01-01-11-00-00-00-01
Unknown chip fallback
No detected chip.
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Retrying
Fault on setup -9
Could not setup interface.

If everything is working up to this point, now run minichlink -G

$ ./minichlink -G
Found WCH Link
WCH Programmer is CH32V307 version 2.11
Full Chip Type Reply: [8] 82-0d-05-05-20-31-05-00-03
Detected: CH32V20x
Setup success
Flash Storage: 64 kB
Part UUID    : 7a-d8-ab-cd-e2-b4-bc-0f
PFlags       : e3-39-e3-39
Part Type (B): 20-31-05-00
Using binary blob write for operation.
Read protection: disabled
Interface Setup
gdbserver running on port 3333
GDBServer Running
Terminal started

@�      ��

At this point, my WLink started to blink with a blue light...
Open a new terminal and go in to the previous blink directory ch32fun/examples_v20x/blink and run gdb-multiarch.
And run

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
Truncated register 22 in remote 'g' packet
(gdb) 

In the minichlink terminal you should see new text output

Connection established to gdbserver backend
gdbserver running on port 3333

Going back the the gdb window you can run

(gdb) file blink.elf 
Reading symbols from blink.elf...

The other commands don't work though

(gdb) monitor reset halt
"monitor" command not supported by this target.
(gdb) load blink.elf
You can't do that when your target is `exec'

So at this point stuck, but I'll keep debugging.

Outstanding questions are:

• Is that gdb-multiarch correct or do I need to specify risv somewhere?
• Why is there a .bin and a .elf file b/c Aren't .elf files just a different binary format...?
• Previous I just flashed the .bin file with wchisp
• the .elf and .bin are of very different files sizes.. 41.9kb vs. 888B.
• I'm guessing I'm not supposed to be flashing the .elf - but gdb doesn't allow me to load the .bin

(gdb) file blink.bin 
"/home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.bin": not in executable format: file format not recognized

• Why the issues with load and monitor?
• How do make a DEBUG build with symbols? I'm guessing the toolchain and flags are hardcoded b.c this isn't using something like CMake and has a hardcoded Makefile system. Magic sauce in /ch32fun/ch32fun/ch32fun.mk I think

[kxygk]

As specified in the Makefile,

https://github.com/cnlohr/ch32fun/blob/master/ch32fun/ch32fun.mk#L325

running the gdb client is done by doing

$ gdb-multiarch blink.elf
(gdb) target remote :3333
0x00000318 in main () at /home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.c:17
17              funPinMode( PIN_K,     GPIO_CFGLR_OUT_10Mhz_PP ); // Set PIN_K to output

This way seems to work. You can then hit C-x C-a and it'll bring up the source code

[TommyMurphyTM1234]

• Why is there a .bin and a .elf file b/c Aren't .elf files just a different binary format...?

The .bin file is the raw binary program image (code plus initialised data) for flashing or for use as a bootloader program payload etc. The .elf file contains not just the raw binary program image but also additional information such as symbolic debug information, information about individual program sections (text, data, rodata, stack, heap etc.) etc. E.g.:

• https://stackoverflow.com/questions/2427011/what-is-the-difference-between-elf-files-and-bin-files

• the .elf and .bin are of very different files sizes.. 41.9kb vs. 888B.

See above. A more meaningful comparison is the size of the .bin file on disk versus size file.elf and the sum of the sizes of all "ROMable" ELF sections.

• I'm guessing I'm not supposed to be flashing the .elf - but gdb doesn't allow me to load the .bin

Not unless the flashing tool can read/interpret ELF and only write the relevant sections to flash.

[kxygk]

Thank you so much @biemster @TommyMurphyTM1234
I really appreciate you guys sharing your knowledge

Really Interesting, I think in my previous experience the tool (openocd) must have used the ELF directly and implicitly stripped out a .bin under the hood

It's all a but opaque, or maybe just inexperience futzing with gdb

For instance when gdb runs the program on-chip with continue you can interrupt it with Ctrl+C Ctrl+C. This stops it at some arbitrary point

It prints the file and line numbers..

But if you try inserting a breakpoint,
it suddently has no idea what file you're talking about haha

Ex:

(gdb) target remote :3333
Remote debugging using :3333
0x0000031a in main () at /home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.c:17
17              funPinMode( PIN_K,     GPIO_CFGLR_OUT_10Mhz_PP ); // Set PIN_K to output
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
^C0x00000316 in main () at /home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.c:17
17              funPinMode( PIN_K,     GPIO_CFGLR_OUT_10Mhz_PP ); // Set PIN_K to output
(gdb) Quit
(gdb) break breakpoint blink.c:30
No source file named breakpoint blink.c.
Make breakpoint pending on future shared library load? (y or [n]) 

Using the full path doesn't help

(gdb) break breakpoint /home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.c:30
No source file named breakpoint /home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.c.
Make breakpoint pending on future shared library load? (y or [n]) 

Stepping with n also hangs the program.
So I'm suspecting something is broken in the debug environment.

(gdb) n
Note: automatically using hardware breakpoints for read-only addresses.

Should I not maybe make a DEBUG build somehow?
Usually those map better to original source.
Here I'd assume almost everything gets stripped out by the linker b/c the program is so simple

[biemster]

The fact that you get source code at all in gdb means there are debug symbols in the ELF, so I highly suspect a debug build is default (I'll have to check the makefiles though, not sure of this). I don't use gdb a lot, but is break breakpoint blink.c:30 the right command? I'd guess break blink.c:30 is the way to do it, but again, I don't use this much.

With questions like this you really should join the discord, you reach many many more people with way more experience than me.

[kxygk]

yeah, i tried a bunch of variations - sorry, i skipped it to keep things shorter

I worked off of these examples:

https://www.gdbtutorial.com/gdb-breakpoints-example

(gdb) break blink.c:30
Invalid hex digit 32
(gdb) b blink.c:30
Invalid hex digit 32
(gdb) breakpoint blink.c:30
Undefined command: "breakpoint".  Try "help".
(gdb) break 30
Invalid hex digit 32

I'm also not totally sure how many breakpoints/watchpoints this chip provides. openocd usually prints that info, but here I'm not sure. Maybe it's in the spec sheet for the chip

With questions like this you really should join the discord, you reach many many more people with way more experience than me.

Okay, I will try to do that and make an account. It's just very long form and seemed inappropriate for a chat app. I'd also like the feedback to be useful to the next person trying it

[maxgerhardt]

I've had some problems with minichlink as the GDB server too. Invalid hex digit 32 screams that it received wrong data from minichlink. You can enable tracing of the network traffic between GDB and minichlink and file a bug report through that.

E.g. (minichlink -G started in the background, then)

gdb-multiarch -ex "set debug remote 1" -ex "target extended-remote :3333" blink.elf

Inside the GDB shell

load
b main
continue

That should make it flash the firmware from the provided .elf file, and I think it auto-resets it after flashing too, then we set a breakpoint to main() and continue to it.

Keep in mind there is a WCH provided openocd version, too: You can download it form http://www.mounriver.com/download. I've had no problems with that (given your WCH-Link(E) Firmware version is up-to-date! :) ) That has the usual monitor reset halt etc commands too.

[kxygk]

Ah okay, you know.. i somehow completely missed the error on the minichlink side

So while on the GDB end I was getting

(gdb) n
Invalid hex digit 79

On the minichlink side I'm seeing

Connection established to gdbserver backend
Fault on op (DMABSTRACTS = 08000602) (100) (Parity Bit) DMSTATUS: 00000382
Fault on DefaultReadHalfWord
Error setting read reg. Tell cnlohr. Maybe we should allow retries here?
RR: 4 :81 55 01 02 
Fault on op (DMABSTRACTS = ffffffff) (-1) (Other Error) DMSTATUS: ffffffff
Fault on DefaultReadHalfWord
Error reading binary blob at 000001ea

I guess I should "Tell @cnlohr " ? :))

And thank you @maxgerhardt

I tried the debugging run as you suggested. I'm not sure I can read the tea leaves on what it means, but I'll leave the output here

`minichlink` Side:

kxygk@matebook16:~/Projects/extern/ch32fun/minichlink$ ./minichlink -G
Found WCH Link
WCH Programmer is CH32V307 version 2.11
Full Chip Type Reply: [8] 82-0d-05-05-20-31-05-00-03
Detected: CH32V20x
Setup success
Flash Storage: 65535 kB
Part UUID    : f7-ff-ff-ff-00-00-00-00
PFlags       : 00-00-00-00
Part Type (B): 00-00-00-00
Using binary blob write for operation.
Read protection: enabled
Interface Setup
gdbserver running on port 3333
GDBServer Running
Terminal started

`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�`K�▒�Connection established to gdbserver backendK�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K�▒�`K
UNKNOWN PACKET: 3 (!#)
23 00 61 

`gdb` side:

kxygk@matebook16:~/Projects/extern/ch32fun/examples_v20x/blink$ gdb-multiarch -ex "set debug remote 1" -ex "target extended-remote :3333" blink.elf
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
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"...
Reading symbols from blink.elf...
Remote debugging using :3333
[remote] start_remote_1: enter
  [remote] Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;QThreadOptions+;no-resumed+;memory-tagging+;xmlRegisters=i386#72
  [remote] Received Ack
  [remote] Packet received: PacketSize=f000;hwbreak+;vContSupported+;qXfer:memory-map:read+;read+;QStartNoAckMode+
  [remote] packet_ok: Packet qSupported (supported-packets) is supported
  [remote] Sending packet: $vCont?#49
  [remote] Received Ack
  [remote] Packet received: vCont;c;C;s;S
  [remote] packet_ok: Packet vCont (verbose-resume) is supported
  [remote] Sending packet: $vMustReplyEmpty#3a
  [remote] Received Ack
  [remote] Packet received: 
  [remote] Sending packet: $QStartNoAckMode#b0
  [remote] Received Ack
  [remote] Packet received: OK
  [remote] Sending packet: $!#21
  [remote] Packet received: E 00
  [remote] Sending packet: $Hg0#df
  [remote] Packet received: 
  [remote] Sending packet: $qTStatus#49
  [remote] Packet received: 
  [remote] packet_ok: Packet qTStatus (trace-status) is NOT supported
  [remote] Sending packet: $?#3f
  [remote] Packet received: T05
  [remote] Sending packet: $qfThreadInfo#bb
  [remote] Packet received: m1
  [remote] Sending packet: $qsThreadInfo#c8
  [remote] Packet received: l
  [remote] Sending packet: $qAttached#8f
  [remote] Packet received: 1
  [remote] packet_ok: Packet qAttached (query-attached) is supported
  [remote] Sending packet: $Hc-1#09
  [remote] Packet received: 
  [remote] Sending packet: $qC#b4
  [remote] Packet received: QC1
  [remote] Sending packet: $qOffsets#4b
  [remote] Packet received: 
  [remote] wait: enter
    [remote] select_thread_for_ambiguous_stop_reply: enter
      [remote] select_thread_for_ambiguous_stop_reply: process_wide_stop = 0
      [remote] select_thread_for_ambiguous_stop_reply: first resumed thread is Thread 1
      [remote] select_thread_for_ambiguous_stop_reply: is this guess ambiguous? = 0
    [remote] select_thread_for_ambiguous_stop_reply: exit
  [remote] wait: exit
  [remote] Sending packet: $g#67
  [remote] Packet received: 000000006e020000f04f00207008002093037124700100000f0000004400612400080140868c08c3fa0000000080000090d003003100000000f000e0000000000a00000044844844d4581045e51b6138b6288049808093408061122342494c53015841a61d09048c0ea24a8145a46100c300870b0101e449b0d8d0336e4ac4321a030000
  [remote] Sending packet: $qfThreadInfo#bb
  [remote] Packet received: m1
  [remote] Sending packet: $qsThreadInfo#c8
  [remote] Packet received: l
  [remote] Sending packet: $qXfer:memory-map:read::0,1000#ab
  [remote] Packet received: l<?xml version="1.0"?><!DOCTYPE memory-map PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN" "http://sourceware.org/gdb/gdb-memory-map.dtd"><memory-map>  <memory type="flash" start="0x00000000" length="0x3fffc00">    <property name="blocksize">256</property>  </memory>  <memory type="ram" start="0x20000000" length="0x800">    <property name="blocksize">1</property>  </memory>  <memory type="ram" start="0x40000000" length="0x10000000">    <property name="blocksize">4</property>  </memory>  <memory type="r [110 bytes omitted]
  [remote] Sending packet: $m31a,4#92
  [remote] Packet received: f5df1c43
  [remote] Sending packet: $m316,4#67
  [remote] Packet received: 5c43858b
0x0000031a in main () at /home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.c:17
17              funPinMode( PIN_K,     GPIO_CFGLR_OUT_10Mhz_PP ); // Set PIN_K to output
  [remote] Sending packet: $qSymbol::#5b
  [remote] Packet received: 
  [remote] packet_ok: Packet qSymbol (symbol-lookup) is NOT supported
[remote] start_remote_1: exit
(gdb) 

As for OpenOCD, I didn't know that's an option! (I only saw their Windows IDE thing)
What are the pros/cons vs. minichlink?

I'm also having issues with it.. Downloaded and extracted the provided MRS_Toolchain_Linux_x64_V210.tar.xz

In the resulting folder, I then cd into OpenOCD/OpenOCD/bin/ and run

cp wch-riscv.cfg openocd.cfg

I then run openocd and gdb

`OpenOCD` Side:

kxygk@matebook16:~/Projects/nano/OpenOCD/OpenOCD/bin$ ./openocd 
Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2024-11-20-13:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : WCH-LinkE  mode:RV version 2.11 
Info : wlink_init ok
Info : clock speed 6000 kHz
Warn : target wch_riscv.cpu.0 examination failed
Info : starting gdb server for wch_riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Error: Target not examined yet
Error executing event gdb-attach on target wch_riscv.cpu.0:

Error: Target not examined yet
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

`GDB` Side:

kxygk@matebook16:~/Projects/extern/ch32fun/examples_v20x/blink$ gdb-multiarch blink.elf
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
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"...
Reading symbols from blink.elf...
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote connection closed
(gdb) 

(given your WCH-Link(E) Firmware version is up-to-date! :) )

This might be the crux of my problem! I will look into updating the fireware

[kxygk]

I used the flashing tool https://github.com/cjacker/wlink-iap

Running this seems to update the firmware:

./wlink-iap -f ../firmwares/FIRMWARE_CH32V305_v2.15.bin 

Things seem a bit better now.
Sometimes some parts work.
But it's all still pretty broken unfortunately.

For the load, b main, continue example

GDB

kxygk@matebook16:~/Projects/extern/ch32fun/examples_v20x/blink$ gdb-multiarch -ex "set debug remote 1" -ex "target extended-remote :3333" blink.elf
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
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"...
Reading symbols from blink.elf...
Remote debugging using :3333
[remote] start_remote_1: enter
  [remote] Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;QThreadOptions+;no-resumed+;memory-tagging+;xmlRegisters=i386#72
  [remote] Received Ack
  [remote] Packet received: PacketSize=f000;hwbreak+;vContSupported+;qXfer:memory-map:read+;read+;QStartNoAckMode+
  [remote] packet_ok: Packet qSupported (supported-packets) is supported
  [remote] Sending packet: $vCont?#49
  [remote] Received Ack
  [remote] Packet received: vCont;c;C;s;S
  [remote] packet_ok: Packet vCont (verbose-resume) is supported
  [remote] Sending packet: $vMustReplyEmpty#3a
  [remote] Received Ack
  [remote] Packet received: 
  [remote] Sending packet: $QStartNoAckMode#b0
  [remote] Received Ack
  [remote] Packet received: OK
  [remote] Sending packet: $!#21
  [remote] Packet received: E 00
  [remote] Sending packet: $Hg0#df
  [remote] Packet received: 
  [remote] Sending packet: $qTStatus#49
  [remote] Packet received: 
  [remote] packet_ok: Packet qTStatus (trace-status) is NOT supported
  [remote] Sending packet: $?#3f
  [remote] Packet received: T05
  [remote] Sending packet: $qfThreadInfo#bb
  [remote] Packet received: m1
  [remote] Sending packet: $qsThreadInfo#c8
  [remote] Packet received: l
  [remote] Sending packet: $qAttached#8f
  [remote] Packet received: 1
  [remote] packet_ok: Packet qAttached (query-attached) is supported
  [remote] Sending packet: $Hc-1#09
  [remote] Packet received: 
  [remote] Sending packet: $qC#b4
  [remote] Packet received: QC1
  [remote] Sending packet: $qOffsets#4b
  [remote] Packet received: 
  [remote] wait: enter
    [remote] select_thread_for_ambiguous_stop_reply: enter
      [remote] select_thread_for_ambiguous_stop_reply: process_wide_stop = 0
      [remote] select_thread_for_ambiguous_stop_reply: first resumed thread is Thread 1
      [remote] select_thread_for_ambiguous_stop_reply: is this guess ambiguous? = 0
    [remote] select_thread_for_ambiguous_stop_reply: exit
  [remote] wait: exit
  [remote] Sending packet: $g#67
  [remote] Packet received: 000000006e020000f04f00207008002093825124700100000f0000004400e120000000e069030000000000000080000090d003003100000000f000e0000000000a00000040000000d4781005e51b7121b60890418080914088611321c2490c53005841060509248c0ea24a8145a46104041000200021e449b0c8d0326e4ac43200000000
  [remote] Sending packet: $qfThreadInfo#bb
  [remote] Packet received: m1
  [remote] Sending packet: $qsThreadInfo#c8
  [remote] Packet received: l
  [remote] Sending packet: $qXfer:memory-map:read::0,1000#ab
  [remote] Packet received: l<?xml version="1.0"?><!DOCTYPE memory-map PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN" "http://sourceware.org/gdb/gdb-memory-map.dtd"><memory-map>  <memory type="flash" start="0x00000000" length="0x10000">    <property name="blocksize">256</property>  </memory>  <memory type="ram" start="0x20000000" length="0x800">    <property name="blocksize">1</property>  </memory>  <memory type="ram" start="0x40000000" length="0x10000000">    <property name="blocksize">4</property>  </memory>  <memory type="ram [108 bytes omitted]
  [remote] Sending packet: $m0,4#fd
  [remote] Packet received: 6f007032
InterruptVectorDefault () at ../../ch32fun/ch32fun.c:997
997             asm volatile( DEFAULT_INTERRUPT_VECTOR_CONTENTS );
  [remote] Sending packet: $qSymbol::#5b
  [remote] Packet received: 
  [remote] packet_ok: Packet qSymbol (symbol-lookup) is NOT supported
[remote] start_remote_1: exit
(gdb) load
[remote] Sending packet: $vFlashErase:00000000,00000400#be
[remote] Packet received: OK
Loading section .init, size 0xfc lma 0x0
[remote] Sending packet: $vFlashWrite:0:o\000\200\030\000\000\000\000R\002\000\000\006\002\000\000\000\000\000\000\006\002\000\000\000\000\000\000\000\000\000\000\006\002\000\000\006\002\000\000\000\000\000\000\000\000\000\000\006\002\000\000\000\000\000\000\006\002\000\000\000\000\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000\006\002\000\000#16
[remote] Packet received: OK
Loading section .text, size 0x27c lma 0xfc
[remote] Sending packet: $vFlashWrite:fc:�\a\000�\223\207\a8\230C\023w\a\bm�7'0x\023\a\207\b�\006\000�\230�\223\206\0068qG%H�U\234B\223�\a\b��3V�\000=\212\223\ap\005cd�\000\223\a\000\003�\227�\a\223�W\b\234�q\027�\035��\202\200��\000�\224G�G��D\000\223\207\a��\2273��\000:\2267�\000�\003%\210\000\203%�\000�\006�@�6�\0003\207�@\025\217�E\a�\202\200\227\001\000 \223\201A'\027!\000 \023\001\001g\023\205A�\223\205A�cw�\000}\003 \005\000\021\005�m��\023\005\2007\223\205A�\023\206A�c\212�\000\203"\005\000}\003�U\000\021\005\221\005����\223\a\000\000�Bs\220\002�\211b\223\202\202\210s�\0020\227\002\000\000\223\202��\223�2\000s\220R0��\000�\005G\230�\223\a\000-s\220\0274s\000 0s%\0204�=s%\0000�5s%04�5s% 4�5�\a\000�\223\207\a8\230C\023w\a\bm�\005g\023\aW�\230÷\a\000�\223\207\a8\230C\023w\a\bm�7���\023\a7�\230�\001�7\027\002@\034G�\006\200\000�\217\034ǷG\002@\223\207\a\200\230C\023g\a\001\230�7\a<\000�\027\002@\023\a\a@��7\a\b\001\023\a\027\b\230�7\a\237\000\230�7\027\002@\034C\223\226g\000��\006�\\C�\026\002@�\233\223�'\000\\�!G�B�\213�\236���\a\000�\223\207G8}\003�\a\000�\a\000�\223\207\a8\023\a\000\b\230�\202\200yq"�&�J�N�R�V�Z�^�\006ֵ?7\027\002 [155 bytes omitted]
[remote] Packet received: OK
[remote] Sending packet: $vFlashDone#ea
[remote] Packet received: OK
Start address 0x00000000, load size 888
Transfer rate: 521 bytes/sec, 444 bytes/write.
(gdb) b main
[remote] Sending packet: $m2c0,40#c2
[remote] Packet received: OK
Invalid hex digit 79
(gdb) continue
Continuing.
[remote] Sending packet: $vCont;c#a8
[remote] wait: enter
  [remote] Packet received: E 00
warning: Remote failure reply: E 00
[remote] wait: exit
[remote] Sending packet: $g#67
[remote] Packet received: OK
[remote] send_g_packet: Bad register packet; fetching a new packet
[remote] Packet received: 000000006e020000002800207008002093825124700100000f0000004400e12000080140000000000100000000000000000000003100000000f000e0000000000a00000040000000d4781005e51b7121b60890418080914088611321c2490c53005841060509248c0ea24a8145a46104041000200021e449b0c8d0326e4ac432ea010000
[remote] Sending packet: $qfThreadInfo#bb
[remote] Packet received: m1
[remote] Sending packet: $qsThreadInfo#c8
[remote] Packet received: l

Program stopped.
[remote] Sending packet: $m1ea,4#c4
[remote] Packet received: E 00
(gdb) 

minichlink

kxygk@matebook16:~/Projects/extern/ch32fun/minichlink$ ./minichlink -G
Found WCH Link
WCH Programmer is CH32V307 version 2.15
Full Chip Type Reply: [8] 82-0d-05-05-20-31-05-00-03
Detected: CH32V20x
Setup success
Flash Storage: 64 kB
Part UUID    : 7a-d8-ab-cd-e2-b4-bc-0f
PFlags       : e3-39-e3-39
Part Type (B): 20-31-05-00
Using binary blob write for operation.
Read protection: disabled
Interface Setup
gdbserver running on port 3333
GDBServer Running
Terminal started

�s�Connection established to gdbserver backend
UNKNOWN PACKET: 3 (!#)
23 00 61 
Writing flash: 00000000 len 252
Write OK
ESCAPED @ b9 -> # [35]
ESCAPED @ d7 -> # [35]
ESCAPED @ 1d1 -> # [35]
ESCAPED @ 229 -> } [125]
ESCAPED @ 23d -> } [125]
ESCAPED @ 265 -> # [35]
ESCAPED @ 269 -> # [35]
ESCAPED @ 26d -> # [35]
ESCAPED @ 271 -> # [35]
ESCAPED @ 277 -> # [35]
ESCAPED @ 27b -> # [35]
ESCAPED @ 27d -> $ [36]
Writing flash: 000000fc len 636
Write OK
Fault on op (DMABSTRACTS = 08000402) (100) (Processor not halted.) DMSTATUS: 000c0c82
Fault on DefaultReadBinaryBlob
Error reading binary blob at 000002c0
Fault on op (DMABSTRACTS = 08000402) (100) (Processor not halted.) DMSTATUS: 000c0382
Fault on DefaultReadHalfWord
Error reading binary blob at 000001ea

Some things I've noticed..

• When running with minichlink, continue works. The board will blink at me. If I interrupt it with Ctrl+C It usually shows me as being at line 17
• b blink.c:30 (just choosing a random line number inside the loop) make a breakpoint that is never hit. Or at least in the Ctrl+X Ctrl+A visual display it shows a b+ at line 30. But I in actuality get some error
  GDB

(gdb) b blink.c:30
Note: breakpoint 1 also set at pc 0x366.
[remote] Sending packet: $m366,2#6a
[remote] Packet received: E 00
Invalid hex digit 32

Minichlink

Fault on op (DMABSTRACTS = 08000402) (100) (Processor not halted.) DMSTATUS: 000c0c82
Fault on DefaultReadHalfWord
Error reading binary blob at 00000366

• After this error I can sometime continue.. sometimes I can't
• Sometimes I can step with n, sometimes I get a error

(gdb) n
[remote] Sending packet: $m318,4#69
[remote] Packet received: E 00
Invalid hex digit 32

• With openocd I can't load. Sometimes it can continue.. sometimes it can't. Very weird behavior

[maxgerhardt]

Your WCH-Link(E) version is 2.11, but mine is 2.17. I have no problem connecting via OpenOCD or flashing firmware with it. You also don't have to copy wch-riscv.cfg as your openocd.cfg, you can point to it via

>bin\openocd.exe -s bin -f wch-riscv.cfg
Open On-Chip Debugger 0.11.0+dev-snapshot (2025-06-20-16:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : WCH-LinkE  mode:RV version 2.17
Info : wlink_init ok
Info : clock speed 6000 kHz
Info : [wch_riscv.cpu.0] datacount=2 progbufsize=8
Info : [wch_riscv.cpu.0] Examined RISC-V core; found 1 harts
Info : [wch_riscv.cpu.0]  XLEN=32, misa=0x40800014
[wch_riscv.cpu.0] Target successfully examined.
Info : starting gdb server for wch_riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections

Sadly if you only have Linux, I don't know how to update the firmware: The WCH-LinkUtility program that I use seems to be Windows only. Maybe spin up a VM with a free Windows 10 evaluation image?

With openocd I can't load

Does it happen when you use ony OpenOCD to burn the firmware, too, aka not through GDB? You can use a command like

> bin\openocd.exe -s bin -f wch-riscv.cfg -c "init; program {blink.elf} verify reset; exit"
Open On-Chip Debugger 0.11.0+dev-snapshot (2025-06-20-16:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : WCH-LinkE  mode:RV version 2.17
Info : wlink_init ok
Info : clock speed 6000 kHz
Info : [wch_riscv.cpu.0] datacount=2 progbufsize=8
Info : [wch_riscv.cpu.0] Examined RISC-V core; found 1 harts
Info : [wch_riscv.cpu.0]  XLEN=32, misa=0x40800014
[wch_riscv.cpu.0] Target successfully examined.
Info : starting gdb server for wch_riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
** Programming Started **
Info : device id = 0xabc8abcd
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Info : [wch_riscv.cpu.0] Hart unexpectedly reset!

(works fine)

[kxygk]

EDIT: Nevermind.. OpenOCD is working now... I'm not sure why. My only guess is a bad contact :S

But I'm able to step b blink.c:30, I'm able to step through the program, and I can continue and have it break at the line in the while(1) loop. I think I'm all good to go now :)))

Thank you so so much @maxgerhardt
Wouldn't have gotten it working without your input

I'll try to hook it up to KDevelop or something and then make a short writeup so others can use it. Thanks everyone - everyone's input was incredibly useful. :)))

---

Your WCH-Link(E) version is 2.11, but mine is 2.17

I think it's 2.15? (maybe that was a typo!)

It was simply from the flashing tool's repo:
https://github.com/cjacker/wlink-iap/tree/main/firmwares

A quick online search brings up others - so I think I will try that next
https://github.com/21km43/WCH-Link_Firmware

Does it happen when you use ony OpenOCD to burn the firmware, too, aka not through GDB?

I checked out your command it seems to work!

kxygk@matebook16:~/Projects/nano/OpenOCD/OpenOCD/bin$ ./openocd -s bin -f wch-riscv.cfg -c "init; program {/home/kxygk/Projects/extern/ch32fun/examples_v20x/blink/blink.elf} verify reset; exit"
Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2024-11-20-13:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : WCH-LinkE  mode:RV version 2.15 
Info : wlink_init ok
Info : clock speed 6000 kHz
Info : [wch_riscv.cpu.0] datacount=2 progbufsize=8
Info : [wch_riscv.cpu.0] Examined RISC-V core; found 1 harts
Info : [wch_riscv.cpu.0]  XLEN=32, misa=0x40901105
[wch_riscv.cpu.0] Target successfully examined.
Info : starting gdb server for wch_riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
** Programming Started **
Info : device id = 0x7ad8abcd
Info : flash size = 64kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **

It seems to match what you have.