WLink driver for Linux #16
Comments
|
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 so that gives me a Double check what your |
|
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. 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. |
|
Compiling the minichlink from ch32v003fun it can find the WCH-LinkE But the MounRiver Studio only generates a hex and not a bin file to program. |
|
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): 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.
|
|
The MounRiver Studio can be downloaded, installed and used in Linux without problems. 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: Afterwards nothing happens without any error message. |
You can change the output format in the project properties in MounRiver Studio. |
Thank you - that solves the problem to generate a binary file. 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: Is there a possibility to include minichlink into eclipse? What is the last firmware version of the WCH-LinkE? |
|
|
Ah - O.K. Thank you. Apropo - is there an explicit description of the mnemonics / machine code for this RISC-V CPU's? |
|
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. |
Is it not normal that an developer and seller of an CPU / MCU gives such basic documentation of the instruction set?
Thanks for the info. This is interesting.
Yes - that's true. Can you recommend a forum or a Wiki for this MCU? |
|
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:
|
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:
|
|
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.. |
|
Thanks for reopening the bug.
It seems logical that the only way to recover your programmer is another programmer for the MCU in it. But therefore we need the firmware files. |
|
The firmware |
Yes - thanks for the hint. One question answered in the list #16 (comment) :-) |
|
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. It seems the firmware upgrade was done in the linked thread with the MounRiver Studio, that does not work in Linux. |
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 That's universal for all programmer types and chips. |
|
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... |
|
For programming a CH32V003, the only connections between the WCH-LinkE and the chip that you need is 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. |
Thank you and sorry for the late response, it could be tested now successfully (execution as normal user): It's fine that this is working too. |
|
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) Info : only one transport option; autoselect 'sdi' Error: libusb_bulk_write error: LIBUSB_ERROR_PIPE I re-installed the toolchain (which I think should re-install the "libusb") to no avail... hmmmmmm.... |
What are the kernel messages when you plugin the programmer? Use dmesg as root - it will show for connecting: and for disconnect
|
|
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... |
|
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... |
|
The command line is universal for all WCH-Link(E) and CH32V series microcontrollers. There's no difference. |
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. |
|
"Magic - Yes" - I am scratching my head in wonder (or is it awe) for 2 reasons...
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. |
The chinese love to call it secrets. :-)
I asked the WCH support what will happen when pin PD1 / SWIO is used and configured as output, but get no answer.
Without a clock signal there must be a fixed clock rate and some kind of synchronisation.
It's opensource.
I am eager about the Arduino solution. 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. |
|
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. If I hold down the "Boot" button during power-up only the red LED comes on and I get: looks encouraging..... have to wait and see whether the 003 from AliExpress arrives first, or my own design.. |
|
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. |
|
Offtopic question: maxgerhardt are you working with PlatformIO? Would you recommend it as solution for the CH32V003? |
|
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 |
|
Anyway - then you must recommend it of course. :-) 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 |
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? |
|
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.
Using mini printf functions is likely a better choice. |
Thanks for the test. Can you tell what compiler is used in PlatformIO for the Risc-V?
I always did use the itoa, atoi, utoa, etc. functions on such small MCU's. |
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. |
|
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.. 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 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... ??? AnyWay - out of respect for the "Issue" process I propose closing this Issue... Thanx for all of your helpful responses. |
I cannot get the Linux driver for the W-LinkE to work correctly on Ubuntu 23.04
If I set the ModeS to Serial (red LED) It seems to be OK - /dev/ttyACM0 appears..
BUT if I set it to Flash mode (blue LED) nothing happens - no /dev/ch3?? device appears
To check the hardware I tried it on Windows 10 and it seemed to work OK - both of the LEDs come on. If I reboot into Linux with both LEDs lit I get many usb enumeration errors and the system reboots.
more details on my hackaday https://hackaday.io/project/191172
any ideas?? - my boss will reject the WCH chips if I can't get them working on Linux.
The text was updated successfully, but these errors were encountered: