Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux upload/debug fails #22

Closed
gicking opened this issue Mar 7, 2023 · 21 comments
Closed

Linux upload/debug fails #22

gicking opened this issue Mar 7, 2023 · 21 comments
Labels
bug Something isn't working package

Comments

@gicking
Copy link

gicking commented Mar 7, 2023

First of all thanks a lot for your effort! I very much appreciate it :-)

Unfortunately I still have an issue with upload/debug under Linux (Xubuntu 22.04). Here's what I did:

  1. Install CH32V platform as described here and here -> no issue
  2. Clone PIO examples projects as described here -> no issue
  3. Open example "blinky-none-os" and build -> no issue
  4. Press upload button -> failed with Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
  5. In terminal type lsusb to get WCH-LinkE debugger VID&PID -> Bus 001 Device 007: ID 1a86:8010 QinHeng Electronics WCH-Link
  6. Add the following lines to /etc/udev/rules.d/99-platformio-udev.rules:
# WCH-LinkE
ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="8010", MODE="0666", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_PORT_IGNORE}="1"
  1. Reboot PC and re-try upload -> failed with Error: unknow WCH-LINK

I tried the above with the CH32V003F4P6-EVT-R0 (1-wire debug) and CH32V203C8T8-EVT-R0 (2-wire debug) eval boards from here. Both boards function using MounRiver IDE under Win10 in a VirtualBox on the same PC. So it's not a hardware or setup issue.

@gicking
Copy link
Author

gicking commented Mar 7, 2023

Seems like I'm not the only one.

Here is a page which explains how to solve this issue. I didn't go through the details, but I hope it helps...!?

@maxgerhardt
Copy link
Member

I've only tried Linux + WCHLink (not the E version) with a Ch32V307 until now, not yet the WCHLink-E with the CH32V003 or CH32V203 board (although I both have them now :)).

The udev rules definitely and entire bringup (and wireup procedure) definitely need to be documented better, that's on the list for this weekend.

The repo with the OpenOCD from MounRiver sources is really good, thanks for that. But the link doesn't say anyhting baout the "Error: unknow WCH-LINK" error? :(

I'll test this on my WCHLink-E + CH32V{0,2}03 boards today.

@gicking
Copy link
Author

gicking commented Mar 7, 2023

Thanks already in advance! I'm sure it's just a typo, wrong access rights or something similarly simple...

I found the page with the OpenOCD from MounRiver sources referenced here

@gicking
Copy link
Author

gicking commented Mar 7, 2023

lsusb yields Bus 001 Device 005: ID 1a86:8010 QinHeng Electronics WCH-Link (without E)

However, the label on both PCB and ESD bag of the debugger states "WCH-LinkE-R0-1v3.FP".

So I figure it's indeed a WCH-LinkE, which is also listed in the WCH-Link manual v1.6

@maxgerhardt maxgerhardt added the bug Something isn't working label Mar 7, 2023
@maxgerhardt
Copy link
Member

My WCHLink-E is also only appearing as "WCH-Link"

[   83.547685] usb 1-2: New USB device found, idVendor=1a86, idProduct=8010, bcdDevice= 2.08
[   83.547691] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   83.547694] usb 1-2: Product: WCH-Link
[   83.547695] usb 1-2: Manufacturer: wch.cn
[   83.547697] usb 1-2: SerialNumber: 81188F0605F5
[   83.563045] cdc_acm 1-2:1.1: ttyACM0: USB ACM device
[   83.563110] usbcore: registered new interface driver cdc_acm
[   83.563139] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

... and I am indeed getting the same error message too.

max@virtualbox:~/ch32/MRS_Toolchain_Linux_x64_V1.60/OpenOCD$ ./bin/openocd -s bin -f wch-riscv.cfg
Open On-Chip Debugger 0.11.0+dev-02215-gcc0ecfb6d-dirty (2022-10-10-10:35)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: unknow WCH-LINK 

@maxgerhardt
Copy link
Member

If I use MounRiver in Windows with the exact same hardware and go Flash->Download, it spews out at least some firmware version

------------ Begin flash process of "obj\CH32V003A4M6.hex" ------------ 
23:16:25:445 >> Current project vendor is WCH, debugger is WCH-Link

23:16:25:445 >> Attempt to open link device and upgrade firmware if necessary...
23:16:25:540 >> Link Device is CH32V305. Already the latest version v2.8, no need to upgrade

23:16:25:584 >> Starting to Send Chip Type...
23:16:25:645 >> Send Chip Type Success

23:16:25:645 >> Starting to Check Read-Protect Status...
23:16:25:645 >> Read-Protect Status Currently Disabled

23:16:25:645 >> Starting to Erase All...
23:16:25:715 >> Erase All Success

23:16:25:716 >> Starting to Download & Verify...
23:16:25:980 >> Download & Verify Success

23:16:25:980 >> Starting to Reset...
23:16:25:996 >> Reset Success

23:16:25:996 >> Starting to Close Link...
23:16:26:003 >> Close Link Success
---------------------------------End ----------------------------------

@maxgerhardt
Copy link
Member

I just sent a support email in regards to it. A smoking gun is definitely that the Windows OpenOCD version is newer than the Linux one.

Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2023-01-03-10:00)

vs

Open On-Chip Debugger 0.11.0+dev-02215-gcc0ecfb6d-dirty (2022-10-10-10:35)

So they probably haven't released an updated Linux OpenOCD version yet.

@maxgerhardt
Copy link
Member

I got confirmation from support that a new version is coming soon.

Hello, as the printed message shows, the current V160 version of MRS_ ToolChain_ Linux does not support WCH-LinkE with the latest firmware (MRS on Windows platform already supports this firmware version). We will launch the MRS tool chain and debugger software on Linux platform as soon as possible.

@gicking
Copy link
Author

gicking commented Mar 10, 2023

oh darn! I was hoping for a wrong udev rule or something. Well, guess we have to hope that asap is really soon

@martiinezz
Copy link

martiinezz commented Mar 12, 2023

What I do on Linux is build in Platform.io and upload using https://github.com/ch32-rs/wchisp - it does upload elf or bin - all you need is to put board into boot mode. I'm sure you can use it as upload_custom script or so.

@maxgerhardt
Copy link
Member

We will integrate this natively (tracked in #14) indeed soon. I'm watching the Linux section in http://www.mounriver.com/download on the side.

@maxgerhardt
Copy link
Member

Just FYI @martiinezz I've implemented #14 now and created the project https://github.com/Community-PIO-CH32V/platform-ch32v/tree/develop/examples/usb-cdc-wch32v307-none-os which uploads fine via ISP and the USB works too.

Though WCHISP does not seem to have the ability to boot the chip into run-application, i.e. when it does a "reset" it still looks at BOOT0 pin state and in my case just ends up in USB ISP bootloader mode again. So after a upload, I physically have to move the BOOT0 jumper back to GND and press the reset button to make the board run the uploaded firmware.

@tmolteno
Copy link

I'm using Like-E on Debian and it seems to be working for me.

Building in release mode
Checking size .pio/build/ch32v003f4p6_evt_r0/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]  14.1% (used 288 bytes from 2048 bytes)
Flash: [=         ]   9.0% (used 1480 bytes from 16384 bytes)
Configuring upload protocol...
AVAILABLE: wch-link
CURRENT: upload_protocol = wch-link
Uploading .pio/build/ch32v003f4p6_evt_r0/firmware.elf
Open On-Chip Debugger 0.11.0+dev-02215-gcc0ecfb6d-dirty (2022-10-10-10:35)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

Ready for Remote Connections
Warn : Bypassing JTAG setup events due to errors
[riscv.cpu.0] Target successfully examined.
Warn : Bypassing JTAG setup events due to errors
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
Warn : Bypassing JTAG setup events due to errors
shutdown command invoked
============================ [SUCCESS] Took 1.29 seconds ============================

Environment          Status    Duration
-------------------  --------  ------------
ch32v003f4p6_evt_r0  SUCCESS   00:00:01.290

@maxgerhardt
Copy link
Member

maxgerhardt commented Mar 18, 2023 via email

@tmolteno
Copy link

Here's the output from MounRiver when I try and flash...

----------- Begin flash process of "/home/tim/mrs_community-workspace/CH32V003F4P6/obj/CH32V003F4P6.hex" ------------ 
18:44:03:411 >> Current project vendor is WCH, debugger is WCH-Link

18:44:03:411 >> Attempt to open device and upgrade firmware if necessary...
18:44:03:576 >> WCH-Link no need to upgrade. Already the latest version.

18:44:03:603 >> Starting to Send Chip Type...
18:44:03:663 >> Send Chip Type Success

18:44:03:664 >> Starting to Check Read-Protect Status...
18:44:03:664 >> Read-Protect Status Currently Disabled

18:44:03:665 >> Starting to Erase All...
18:44:03:672 >> Erase All Success

18:44:03:735 >> Starting to Download & Verify...
18:44:03:991 >> Download & Verify Success

18:44:03:991 >> Starting to Reset...
18:44:04:007 >> Reset Success

18:44:04:007 >> Starting to Close Link...
18:44:04:007 >> Close Link Success
---------------------------------------------------------End ---------------------------------------------------------
Operation Finished (took 0s.601ms)

@maxgerhardt
Copy link
Member

maxgerhardt commented Mar 29, 2023

image

image

HAHAR!!!

@gicking
Copy link
Author

gicking commented Mar 29, 2023

HAHAR!!!

like! :-)))

@maxgerhardt
Copy link
Member

Linux + WCH-LinkE + CH32V003 is working with the new OpenOCD version.

max@virtualbox:~/ch32/MRS_Toolchain_Linux_x64_V1.70/OpenOCD/bin$ ./openocd -s . -f wch-riscv.cfg 
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
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.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

working on the packages now.

@martiinezz
Copy link

Awesome :)

@maxgerhardt
Copy link
Member

The packages were approved in the PIO registry so this should now work out-of-the box. Easiest way to update is to force a reinstall.

rm -rf ~/.platformio/platforms/ch32v
rm -rf ~/.platformio/packages/tool-openocd-riscv-wch

and build again.

Reopen if issues persist.

@gicking
Copy link
Author

gicking commented Apr 2, 2023

Thanks a lot!!!

I just tried CH32V003 and it works :-) However, I did have to copy ~/.platformio/packages/tool-openocd-riscv-wch/bin/60-openocd.rules to /etc/udev/rules.d/ and reboot. Maybe you can also add that to the installation somehow...?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working package
Projects
None yet
Development

No branches or pull requests

4 participants