WLink driver for Linux

[openwch]

WLink driver for Linux

[karstengit]

"Magic - Yes" - I am scratching my head in wonder (or is it awe) for 2 reasons...

The chinese love to call it secrets. :-)

1. no reset - I'm familiar with the SWD/SWC used on the LGT8F... chinese ATMEGA328 clones.  It uses reset.  Where was I reading about the protocol starting with 100 alternating 1s and 0s?  in lieu of reset??

I asked the WCH support what will happen when pin PD1 / SWIO is used and configured as output, but get no answer.
I would say this is a secure method to protect the chip from any access.

2. the recent statement that all WCD chips could use the same upload config...  I know the chips are extremely similar internally with the exception of the "003" which uses a 1-wire programming interface rather than a 2-Wire like the rest,  which is why I would expect the "003" config to be different...

Without a clock signal there must be a fixed clock rate and some kind of synchronisation.
100 alternating 1s and 0s sounds good for it.

I need to dig deeper into the minichlink...

It's opensource.
Maybe this page will offer some more ideas for you?
https://github.com/CaiB/CH32V003-Architecture-Exploration/
Please let me know when you find out more.

I just submitted my first "003" design to JLCPCB - I'm optimistic and at $.20 cents each not wasting too much dough. First project will be an OptiBoot bootloader..

I am eager about the Arduino solution.
My breakout board is already in use now.
I have have presented it here https://www.mikrocontroller.net/topic/556005 (german), but there seems not really interest for it.

A bootloader would be really a more comfortable way to program this chip without the need of this tricky programmer and it is the standard in the Arduino world.
Hopefully it will not take to much of the flash space.

[maxgerhardt]

Can you tell what compiler is used in PlatformIO for the Risc-V?

The MounRiver one. They recently also open-sourced this as https://github.com/openwch/risc-none-embed-gcc

Edit: Nah it's not open-source, that's just the compiled binaries, same as from http://www.mounriver.com/download.

[maxgerhardt]

Having 0 problems here. Not pushing any ModeS button, just plugging in my WCH-Link E and forwarding it to my Linux VM I get

[  119.829556] usb 1-2: new full-speed USB device number 3 using xhci_hcd
[  120.103606] usb 1-2: New USB device found, idVendor=1a86, idProduct=8010, bcdDevice= 2.08
[  120.103612] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  120.103615] usb 1-2: Product: WCH-Link
[  120.103616] usb 1-2: Manufacturer: wch.cn
[  120.103617] usb 1-2: SerialNumber: 81188F0605F5
[  120.166057] cdc_acm 1-2:1.1: ttyACM0: USB ACM device
[  120.166086] usbcore: registered new interface driver cdc_acm
[  120.166088] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

so that gives me a /dev/ttyACM0.

Double check what your sudo dmesg -w is saying when you plug in the device.

[karstengit]

Here it is the same problem like described by ArduinoShop.

Development is under Debian GNU/Linux 11 (bullseye).

The udev rules have been added and the WCH-LinkE is recognized by the kernel.
The device ttyACM0 is existant, but a query for it fails in the MounRiver Studio.

[ 5536.279293] usb 3-2: new full-speed USB device number 3 using xhci_hcd
[ 5536.502046] usb 3-2: New USB device found, idVendor=1a86, idProduct=8010, bcdDevice= 2.08
[ 5536.502055] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5536.502060] usb 3-2: Product: WCH-Link
[ 5536.502063] usb 3-2: Manufacturer: wch.cn
[ 5536.502066] usb 3-2: SerialNumber: 87A08F060C7E
[ 5536.515558] cdc_acm 3-2:1.1: ttyACM0: USB ACM device

What maxgerhardt has written is maybe not relevant, because the WCH-LinkE is handled and initialized first by the Windows-driver and then the control is given to the virtual machine.

The WCH-LinkUtility works and find the WCH-LinkE when starting Windows7 in a VM in Debian.
So the hardware seems to be O.K.

[karstengit]

Compiling the minichlink from ch32v003fun it can find the WCH-LinkE
https://github.com/cnlohr/ch32v003fun/tree/master/minichlink

Found WCH Link
WCH Programmer is LinkE version 2.8
Chip Type: 003
Part Type (A): 0x0010 (This is the capacity code, in KB)
Part UUID    : 39-ca-ab-cd-a1-d8-bc-41
PFlags       : ff-ff-ff-ff
Part Type (B): 00-30-05-00
Interface Setup

But the MounRiver Studio only generates a hex and not a bin file to program.
So this is not a solution at this moment for Linux!

[karstengit]

Please consider the remarks on the main project page, that are showing up multiple problems with the WCH-LinkE programmer in Linux (It seems only to be made to work in Windows):
https://github.com/cnlohr/ch32v003fun/tree/master#wch-link-hardware-access-in-wsl

WCH-Link Hardware access in WSL

To use the WCH-Link in WSL, it is required to "attach" the USB hardware on the Windows side to WSL. This is achieved using a tool called usbipd.

1. On windows side, install the following MSI https://github.com/dorssel/usbipd-win/releases

2. Install the WSL side client:
   For Debian: sudo apt-get install usbip hwdata usbutils
   For Arch-based: sudo pacman -S usbip hwdata usbutils
   For Ubuntu (not tested):

    sudo apt install linux-tools-5.4.0-77-generic linux-tools-virtual hwdata usbutils
    sudo update-alternatives --install /usr/local/bin/usbip usbip `ls /usr/lib/linux-tools/*/usbip | tail -n1` 20
   

3. Plug in the WCH-Link to USB

4. Run Powershell as admin and use the usbipd list command to list all connected devices

5. Find the this device: 1a86:8010 WCH-Link (Interface 0) and note the busid it is attached to

6. In powershell, use the command usbipd wsl attach --busid= to attach the device at the busid from previous step

7. You will hear the windows sound for the USB device being removed (and silently attached to WSL instead)

8. In WSL, you will now be able to run lsusb and see that the SCH-Link is attached

9. For unknown reasons, you must run make under root access in order to connect to the programmer with minichlink. Recommend running sudo make when building and programming projects using WSL. This may work too (to be confirmed):
   ...

[karstengit]

The MounRiver Studio can be downloaded, installed and used in Linux without problems.
The examples can be imported and compiled, but it is not possible to program the CH32V003F4P6.

Here is a screenshot for the support from the MounRiver Studio, showing that in Flash -> Configuration the "Target Mode" is greyed out and "Query" has no effect (no error message).

The menu item Flash -> Download only shows:

------------ Begin flash process of "obj/GPIO_Toggle.hex" ------------ 
09:04:42:354 >> Current project vendor is WCH, debugger is WCH-Link

09:04:42:354 >> Attempt to open link device and upgrade firmware if necessary...

Afterwards nothing happens without any error message.

[UCSIG]

Compiling the minichlink from ch32v003fun it can find the WCH-LinkE https://github.com/cnlohr/ch32v003fun/tree/master/minichlink

Found WCH Link
WCH Programmer is LinkE version 2.8
Chip Type: 003
Part Type (A): 0x0010 (This is the capacity code, in KB)
Part UUID    : 39-ca-ab-cd-a1-d8-bc-41
PFlags       : ff-ff-ff-ff
Part Type (B): 00-30-05-00
Interface Setup

But the MounRiver Studio only generates a hex and not a bin file to program. So this is not a solution at this moment for Linux!

You can change the output format in the project properties in MounRiver Studio.
Right-click on the project in the Project Explorer and click on Properties. In the left column click on C/C++ Build -> Settings.
Under the Tool Settings tab click GNU RISC-V Cross Create Flash Image -> General.
There you can change the output file format (-O setting) from Intel HEX to Raw binary.

[karstengit]

You can change the output format in the project properties in MounRiver Studio.
Right-click on the project in the Project Explorer and click on Properties. In the left column click on C/C++ Build -> Settings.
Under the Tool Settings tab click GNU RISC-V Cross Create Flash Image -> General.
There you can change the output file format (-O setting) from Intel HEX to Raw binary.

Thank you - that solves the problem to generate a binary file.

10:30:45 **** Build of configuration obj for project GPIO_Toggle ****
make -j4 all 
Invoking: GNU RISC-V Cross Create Flash Image
Invoking: GNU RISC-V Cross Print Size
riscv-none-embed-objcopy -O binary "GPIO_Toggle.elf"  "GPIO_Toggle.bin"
riscv-none-embed-size --format=berkeley "GPIO_Toggle.elf"
   text	   data	    bss	    dec	    hex	filename
   7012	    152	    276	   7440	   1d10	GPIO_Toggle.elf
Finished building: GPIO_Toggle.bin
Finished building: GPIO_Toggle.siz

10:30:45 Build Finished. 0 errors, 0 warnings. (took 436ms)

Besides - the generated GPIO_Toggle.bin has 7164 Bytes, but the blink.bin from ch32v003fun has only 496 Bytes?

The flashing of the binary file works manually as root and the blink is working now:

# minichlink -w GPIO_Toggle.bin flash -b
Found WCH Link
WCH Programmer is LinkE version 2.8
Chip Type: 003
Part Type (A): 0x0010 (This is the capacity code, in KB)
Part UUID    : 39-ca-ab-cd-a1-d8-bc-41
PFlags       : ff-ff-ff-ff
Part Type (B): 00-30-05-00
Interface Setup
Image written.

Is there a possibility to include minichlink into eclipse?

What is the last firmware version of the WCH-LinkE?
Can the firmware only be updated in Windows?
Will the problems in Linux be fixed by WCH?

[maxgerhardt]

ch32v003fun is a lot smaller because it does not rely on the EVT / SDK made by WCH. It also avoids a integer divide and other things that would cause big code on its rv32ec core that has no integer multiply or divide.

[karstengit]

ch32v003fun is a lot smaller because it does not rely on the EVT / SDK made by WCH. It also avoids a integer divide and other things that would cause big code on its rv32ec core that has no integer multiple or divide.

Ah - O.K. Thank you.

Apropo - is there an explicit description of the mnemonics / machine code for this RISC-V CPU's?
Specially with values for the execution time, if a timed assembler code is needed.

[maxgerhardt]

As far as I know, the QingKe V2 RISC-V V2A documents do not explicitly state how many cycles each instruction takes. It's also influenced by the alignment of the instruction address and possible memory operands. There's some work going on https://github.com/CaiB/CH32V003-Architecture-Exploration/ and in the discord channel, e.g.

In any case, this issue is getting more and more derailed -- originally it was about the WCH-Link(E) not getting recognized in Linux.

[karstengit]

As far as I know, the QingKe V2 RISC-V V2A documents do not explicitly state how many cycles each instruction takes.

Is it not normal that an developer and seller of an CPU / MCU gives such basic documentation of the instruction set?
It should not have to be reengineered by the users that buy the product.

There's some work going on https://github.com/CaiB/CH32V003-Architecture-Exploration/ and in the discord channel,

Thanks for the info. This is interesting.

In any case, this issue is getting more and more derailed -- originally it was about the WCH-Link(E) not getting recognized in Linux.

Yes - that's true. Can you recommend a forum or a Wiki for this MCU?
This informations will be collected and spreaded.

[ArduinoShop]

Continuing on.. I ran into a blog on ee about my very same problem... Only dif was that his MRS was 1 rev older. - It appears that MRS (under Windows) check the rev of the firmware on the LinkE and INSISTs on upgrading it... After that the LinkE is bricked... He assumed that MRS was uploading the hex file of your project rather than the firmware for the LinkE. I can't disagree with him. The blog is at: eevblog.

I wasn't sure if this was my problem so I ordered another LinkE as well as an old LinkV (LinkR??). They arrived today and my brother-in-law loaned me a laptop with Win 10... So I tried plugging in the LINKs to see if they were recognized.. I found that both MRS and the Utility recognized them fine and predictably. I decided to allow MRS to upgrade my LinkRV, but mistakenly had the LinkE plugged in... MISTAKE - I now have 2 bricked LinkEs... They are not recognized by MRS and crashes the utility program.

[ should also note that when the firmware is upgraded the device ID etc. changes which affects Linux udev ]

Which gives rise to 2 questions:

1. The Win installation of MRS always shows the 'upload' icon whether the Link is plugged in or not, whereas the Linux version never shows the 'upload' icon. Is this normal (assuming the Linux driver doesn't work) or do I have a bum Linux version (Linux64_V140).

2. How can I restore the firmware on my LinkEs? I don't know what ".hex" file to use with the "Utility" program and I can't seem to trust MRS... Can it be done with the LINKV? What MCU is used on the LinkE - I can't read what is on the chip.

[karstengit]

ArduinoShop closed this as completed

Please tell me why you have set this bug report to completed?

It isn't completed because there are still a couple of problems regarding the programming of an CH32V003F4P6 with an WCH-LinkE in Linux.

Here are the unanswered questions:

• Is there a possibility to include minichlink into eclipse?
• What is the last firmware version of the WCH-LinkE?
• Can the firmware only be updated in Windows?
• Will the problems in Linux be fixed by WCH?

[ArduinoShop]

My sincere apologies to all the commenters... It was not my intent whatsoever to close this issue. Not really sure how I did it. Don't have a lot of experience with github. Does anyone know how or if I can re-open the issue? Or can we ask the dev to do it for us.

In fact I want to add another comment - I tried using the "Utility" program to upgrade the LinkR with the same result. BRICKED LinkR. It also crashes the Utility program if I try any operations with the either Link connected. Windows to close it.

Only possible solution I can see would be to use 2-Wire JTAG to upgrade/re-install the firmware. Although at this points I have my doubts that MRS or Utility have the correct firmware files... This also leaves me with a chicken and egg situation. I think I would need the Utility to do this and of course it cashes as soon as one connects a 'bricked' Link.

In the meantime I will open a separate issue re "upgrades".

Sorry guys.

P.S. - Looks like I answered my own question about re-opening the Issue - there was an option to re-open when submitting a further comment...... Still think I will open a separate Issue because it seems very important to me and this Issue had many and various subjects..

[karstengit]

Thanks for reopening the bug.

Only possible solution I can see would be to use 2-Wire JTAG to upgrade/re-install the firmware. Although at this points I have my doubts that MRS or Utility have the correct firmware files... This also leaves me with a chicken and egg situation. I think I would need the Utility to do this and of course it cashes as soon as one connects a 'bricked' Link.

It seems logical that the only way to recover your programmer is another programmer for the MCU in it.
The WCH-LinkE programmer here has an CH32V305 FBP6 in it.

But therefore we need the firmware files.
There should be all versions of firmware available, because the different versions seems to have different problems.
So if a newer firmware does not work under Linux we must downgrade, to keep the programmer usable.

[maxgerhardt]

The firmware .bin files lie in the MounRiver installation directory along with a version txt file.

[karstengit]

The firmware .bin files lie in the MounRiver installation directory along with a version txt file.

Yes - thanks for the hint.
So it seems that the own WCH-LinkE has already the newest firmware Version 2.8.

One question answered in the list #16 (comment) :-)
So only the latest firmware is shipped with the MounRiver Studio as "official" repository?

[maxgerhardt]

No the latest one is 2.9, not 2.8. Updating working for me and another person fine per topic. There should be a "Check for Updates" button in the IDE somewhere, it auto-opened for me.

[karstengit]

No the latest one is 2.9, not 2.8. Updating working for me and another person fine per topic. There should be a "Check for Updates" button in the IDE somewhere, it auto-opened for me.

O.K. It seems there is a third way to program the MCU's over OpenOCD.
Is there a description how to do it this way for an CH32V003F4P6?

It seems the firmware upgrade was done in the linked thread with the MounRiver Studio, that does not work in Linux.
Without the possibility of going back to the (older) firmware, it is to risky to try a newer firmware.
(This could end with no programming possibility in Linux or like ArduinoShop.)

[maxgerhardt]

Is there a description how to do it this way for an CH32V003F4P6?

You want to program a CH32V003F4P6 using a WCH-LinkE using OpenOCD? Sure, just use the WCH OpenOCD version contained in MounRiver Studio / the toolchain (or here) and do

./bin/openocd -c "debug_level 2" -s bin -s scripts -f wch-riscv.cfg -c init -c halt -c "program {firmware.elf} verify reset" -c shutdown

That's universal for all programmer types and chips.

[ArduinoShop]

Progress Update... I now have MRS and Utility (under Win 10) recognizing my 2 LinkE's. Not quite sure what I did right (or wrong) - I think it had to do with either several re-boots of my system or more likely switching to MRS 1.85 as opposed to MRS community 1.40. When I connected the LinkE running MRS the Download-> configure button suddenly thought it recognized my LinkE but did another firmware update. I noticed the blue LED was on (ie in ARM mode) so held down the Mode Switch during a power cycle and got a red LED only. After that it behaved normally - it was found during query etc.

I had no luck with the other Link (non-E) - I think it is in the wrong mode - can't remember how to change mode (something about shorting pin ?? to ?GND?) and cycling power.

But - when I try to upload a .hex I only get an "unable to config mcu" error. My WCH32V003 may be hosed due to my using the wrong cable.. I am not sure how to connect it - is it a 1-Wire I/F? I am trying to program the WCH32V103 but getting the same results.. I am connecting GND, 3V3, CLK and DIO. Going to have ti ring out the connections..

??? are we assuming ./bin/openocd should work under Linux ??

slowly but surely...

[maxgerhardt]

For programming a CH32V003, the only connections between the WCH-LinkE and the chip that you need is

LinkE <--> CH32V003
3.3V       VCC
GND        GND
SWDIO      PD1

And yes, OpenOCD will work fine. Just remember to install the udev rules per what's in the toolchain's OpenOCD folder so that a regular user can interact with the device as normal (but if you did a firmware upgrade succesfully that should already be taken care of).

Again, I've personally used Linux + WCH-LinkE + CH32V003 with the MRS OpenOCD and it works perfectly fine.

[karstengit]

You want to program a CH32V003F4P6 using a WCH-LinkE using OpenOCD? Sure, just use the WCH OpenOCD version contained in MounRiver Studio / the toolchain (or here) and do

Thank you and sorry for the late response, it could be tested now successfully (execution as normal user):

.../MounRiver_Studio/toolchain/OpenOCD/bin$ ./openocd -c "debug_level 2" -s bin -s scripts -f wch-riscv.cfg -c init -c halt -c "program {.../test.elf} verify reset" -c shutdown
Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2023-02-22-15:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : WCH-LinkE  mode:RV version 2.8 
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
Info : [wch_riscv.cpu.0] Hart unexpectedly reset!
** Programming Started **
Info : device id = 0xe603abcd
Info : flash size = 16kbytes
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked

It's fine that this is working too.
But I wonder what WCH has done that the tool is not working in the MounRiver Studio in Linux, because the shipped binary and configuration file of openocd is working.

[ArduinoShop]

Thanks so much... I'm getting 1/2 way there... getting libusb errors

Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2023-02-22-15:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

Info : only one transport option; autoselect 'sdi'
Warn : Transport "sdi" was already selected
Ready for Remote Connections
Info : WCH-LinkE mode:RV version 2.9
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: libusb_bulk_write error: LIBUSB_ERROR_PIPE
Error: libusb_bulk_read error: LIBUSB_ERROR_TIMEOUT
Error: libusb_bulk_write error: LIBUSB_ERROR_PIPE
Error: libusb_bulk_read error: LIBUSB_ERROR_PIPE
Info : wlink_init ok
Error: libusb_bulk_write error: LIBUSB_ERROR_PIPE
Error: libusb_bulk_read error: LIBUSB_ERROR_PIPE

Error: libusb_bulk_write error: LIBUSB_ERROR_PIPE
Error: libusb_bulk_read error: LIBUSB_ERROR_PIPE

I re-installed the toolchain (which I think should re-install the "libusb") to no avail...

hmmmmmm....

[karstengit]

Thanks so much... I'm getting 1/2 way there... getting libusb errors

What are the kernel messages when you plugin the programmer?

Use dmesg as root - it will show for connecting:

# dmesg
[  193.050124] usb 2-2: USB disconnect, device number 2
[  199.478404] usb 2-2: new full-speed USB device number 3 using xhci_hcd
[  199.701157] usb 2-2: New USB device found, idVendor=1a86, idProduct=8010, bcdDevice= 2.08
[  199.701166] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  199.701171] usb 2-2: Product: WCH-Link
[  199.701175] usb 2-2: Manufacturer: wch.cn
[  199.701178] usb 2-2: SerialNumber: 87A08F060C7E
[  199.715095] cdc_acm 2-2:1.1: ttyACM0: USB ACM device

and for disconnect

[ 193.050124] usb 2-2: USB disconnect, device number 2

[ArduinoShop]

Progress Update... I now have MRS and Utility (under Win 10) recognizing my 2 LinkE's. Not quite sure what I did right (or wrong) - I think it had to do with either several re-boots of my system or more likely switching to MRS 1.85 as opposed to MRS community 1.40. When I connected the LinkE running MRS the Download-> configure button suddenly thought it recognized my LinkE but did another firmware update. I noticed the blue LED was on (ie in ARM mode) so held down the Mode Switch during a power cycle and got a red LED only. After that it behaved normally - it was found during query etc.

I had no luck with the other Link (non-E) - I think it is in the wrong mode - can't remember how to change mode (something about shorting pin ?? to ?GND?) and cycling power.

But - when I try to upload a .hex I only get an "unable to config mcu" error. My WCH32V003 may be hosed due to my using the wrong cable.. I am not sure how to connect it - is it a 1-Wire I/F? I am trying to program the WCH32V103 but getting the same results.. I am connecting GND, 3V3, CLK and DIO. Going to have ti ring out the connections..

??? are we assuming ./bin/openocd should work under Linux ??

slowly but surely...

[ArduinoShop]

karstengit was kind enough to share the openocd command line for the "003" with us. Wondering if anyone has been able to do the same with other boards.... like the CH32V103...

[maxgerhardt]

The command line is universal for all WCH-Link(E) and CH32V series microcontrollers. There's no difference.

[karstengit]

My WCH32V003 may be hosed due to my using the wrong cable.. I am not sure how to connect it - is it a 1-Wire I/F?

Simply connect GND and VCC and PD1/SWIO with SWDIO of the WCH-LinkE.

It's chinese magic why it is working without any reset, but it takes sometimes 2 or 3 tries to work to program.
Used minichlink always so far.

[ArduinoShop]

"Magic - Yes" - I am scratching my head in wonder (or is it awe) for 2 reasons...

1. no reset - I'm familiar with the SWD/SWC used on the LGT8F... chinese ATMEGA328 clones. It uses reset. Where was I reading about the protocol starting with 100 alternating 1s and 0s? in lieu of reset??

2. the recent statement that all WCD chips could use the same upload config... I know the chips are extremely similar internally with the exception of the "003" which uses a 1-wire programming interface rather than a 2-Wire like the rest, which is why I would expect the "003" config to be different...

I need to dig deeper into the minichlink...

I just submitted my first "003" design to JLCPCB - I'm optimistic and at $.20 cents each not wasting too much dough.
First project will be an OptiBoot bootloader..

[ArduinoShop]

Did I read somewhere that the "Link-E" supports the ability to cycle power on the target board. - Would be about the same as a Reset I should think.. I assume that after a power-up (or a reset) the SWIO pin (and all other GPIOs) defaults to input as the Arduino chips do.

I downloaded the latest version of minichlink - this time it works - recognizes my Link-E as firmware version 2.9.. All I need is a working target...

I tried with my "103" target but didn't get far.... The 103 powers up with a red LED lit and a blue LED flashing.
With blue flashing I get:
"WCH Programmer is CH32V307 version 2.9
link error, nothing connected to linker
Could not setup interface.

If I hold down the "Boot" button during power-up only the red LED comes on and I get:
Found WCH Link
Error sending WCH command (on send): 81 0d 01 03
??? ID code ?? that the mini is not programmed for?

looks encouraging..... have to wait and see whether the 003 from AliExpress arrives first, or my own design..

[maxgerhardt]

With minichlink, only V003 is properly supported. Other things are not yet merged (cnlohr/ch32v003fun#176) / figured out. Just use OpenOCD or https://github.com/ch32-rs/wlink for those cases.

[karstengit]

Offtopic question: maxgerhardt are you working with PlatformIO?

Would you recommend it as solution for the CH32V003?

[maxgerhardt]

I'm not working at PlatformIO Labs (the company), but I do a lot of PlatformIO programming and 3rd-party support, especially platform-gd32 and platform-ch32v

[karstengit]

Anyway - then you must recommend it of course. :-)

Are the standard library functions for strings working in PlatformIO?

[maxgerhardt]

Are the standard library functions for strings working in PlatformIO?

Yes, since we link against the toolchain's newlib-nano C library, string functions are working. Just for the case of printf with %f and %g floating point specifiers, you'd have to activate floating point with build_flags = -Wl,--undefined,_printf_float.

[karstengit]

Are the standard library functions for strings working in PlatformIO?

Yes, since we link against the toolchain's newlib-nano C library, string functions are working. Just for the case of printf with %f and %g floating point specifiers, you'd have to activate floating point with build_flags = -Wl,--undefined,_printf_float.

I am asking because with the riscv64-unknown-elf-gcc it is not possible to use for example standard string funtions like utoa or sprintf via #include <stdlib.h> and #include <string.h>.

Is the newlib-nano C library part of the Moun River Studio?
At this time it is not clear why this standard library is not working with the riscv64-unknown-elf-gcc (in Debian).
It is only possible to copy or include manually the needed functions from other sources as C-code.

[maxgerhardt]

I just personally verified that

#include <ch32v00x.h>
#include <debug.h>
#include <string.h>
#include <stdlib.h>
void NMI_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));
void HardFault_Handler(void) __attribute__((interrupt("WCH-Interrupt-fast")));

int main(void)
{
        NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2);
        SystemCoreClockUpdate();
        USART_Printf_Init(115200);
        Delay_Init();

        while (1)
        {
                char buf[64];
                sprintf(buf, "%s value is %d", "hello world", 123);
                printf("%s\n", buf);
                utoa(1234567u, buf, 10);
                printf("1234567 integer convert to string: %s\n", buf);
        }
}

void NMI_Handler(void) {}
void HardFault_Handler(void)
{
        while (1)
        {
        }
}

compiles cleanly with 0 errors in PlatformIO (based on none-os-blink example), but the functions are quite flash hungry.

Linking .pio/build/ch32v003f4p6_evt_r0/firmware.elf
Checking size .pio/build/ch32v003f4p6_evt_r0/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  21.7% (used 444 bytes from 2048 bytes)
Flash: [=====     ]  53.1% (used 8692 bytes from 16384 bytes)
Building .pio/build/ch32v003f4p6_evt_r0/firmware.bin

Using mini printf functions is likely a better choice.

[karstengit]

I just personally verified that it
compiles cleanly with 0 errors in PlatformIO (based on none-os-blink example), but the functions are quite flash hungry.

Thanks for the test.
The output from the string functions is working practically?

Can you tell what compiler is used in PlatformIO for the Risc-V?

Using mini printf functions is likely a better choice.

I always did use the itoa, atoi, utoa, etc. functions on such small MCU's.
Before it was the ATmega8 and with the avr-gcc this functions seems to be implemented direct in assembler.

[CanHobby]

I'm happy to report that I finally got my new -003 board and it is working correctly... sort of..

Using Linux, of course, I can compile successfully with Moun River 1.4 but no upload icon shows up..
If I hit F11 it goes into a slew of config options that I do not understand...

I drop down to the command line and I can successfully use openocd to upload to the -003 at least...

to-do is: upgrade to 1.5 ... and try with my -103

as I mentioned my goal is to write a serial "Arduino-Style" bootloader, both for WCH RISC-V and STM32Fxxx
so far I'm making progress although my issues are more with IDEs than other technical problems..

Also need to find the email thread I had going on with MRS support to ask why (if indeed true) the OpenOCD in the toolchain works great standalone, but not from the IDE under Linux.

to-do s are all done ... AND I AM MOST PLEASED TO REPORT THAT IT ALL SEEMS TO WORK UNDER LINUX (Ubuntu 23.04)

Using MRS 1.5 and Toolchain 1,8 --- Off to the races..

still need to try with the "103"

..... in Conclusion - this "Issue" has become more of a "discussion", and a profitable one I should think...
my initial issue has been answered with the latest releasees of MRS and the toolchain. I am still waiting for some more "103" hardware to continue my efforts in this regard... I still have the same goal of doing a serial (CDC) bootloader also in parallel with a similar effort with the STM32F equivalent which is coming along slowly... Actually quite a pain due to the way the CDC Serial port disappears from Linux every time you do a firmware change on the board.

??? AnyWay - out of respect for the "Issue" process I propose closing this Issue...
??? Any objections from anyone ???

Thanx for all of your helpful responses.