Closed RathBee closed 2 months ago
Bus 003 Device 012: ID 1a86:8012 QinHeng Electronics WCH-Link
Wrong USB VID/PID heavily indicates your WCH-Link is in ARM mode instead of RISC-V mode (needs to be 1a86:8010
), as discussed in https://github.com/Community-PIO-CH32V/platform-ch32v/issues/31#issuecomment-1899089224.
Follow the instructions there to set it back to RISC-V mode.
hmmmm...... now it spits out another error message......but this time perhaps it's wch's own problem, since it says: Error: communication fail,please contact [support@mounriver.com]
Closed since this issue is resolved.
./wlink status
recognize the programmer or even the chip it's conencted to?
What chip are you connecting to the WCH-LinkE with which exact wiring?
Did you ever update the firmware of the WCH-Link(E) via Mounriver studio?
Does
./wlink status
recognize the programmer or even the chip it's conencted to?
15:57:55 [INFO] Connected to WCH-Link v2.11(v31) (WCH-LinkE-CH32V305) 15:57:55 [INFO] Attached chip: CH32X035 [CH32X035F8U6] (ChipID: 0x035e0611) 15:57:55 [INFO] Chip UID: cd-ab-d5-9f-4e-bc-xx-xx 15:57:55 [INFO] Flash protected: false 15:57:55 [INFO] RISC-V ISA(misa): Some("RV32ACIMUX") 15:57:55 [INFO] RISC-V arch(marchid): Some("WCH-V4C") 15:57:55 [WARN] The halt status may be incorrect because detaching might resume the MCU 15:57:55 [INFO] Dmstatus { .0: 0x382, allhavereset: false, anyhavereset: false, allresumeack: false, anyresumeack: false, allunavail: false, anyunavail: false, allrunning: false, anyrunning: false, allhalted: true, anyhalted: true, authenticated: true, version: 0x2, } 15:57:55 [INFO] Dmcontrol { .0: 0x80000001, haltreq: true, resumereq: false, ackhavereset: false, ndmreset: false, dmactive: true, } 15:57:55 [INFO] Hartinfo { .0: 0x312380, nscratch: 0x3, dataaccess: true, datasize: 0x2, dataaddr: 0x380, } 15:57:55 [INFO] Abstractcs { .0: 0x8000002, progbufsize: 0x8, busy: false, cmderr: 0x0, datacount: 0x2, } 15:57:55 [INFO] haltsum0: 0x1
This error could also be on my side if it needs a newer OpenOCD version. That version could be before the CH32X035 chip was added. I will check this and update shortly.
As a short workaround, can you add this to your platformio.ini
:
upload_protocol = custom
upload_command = wlink flash $SOURCE
And upload again. You might ned to put the full path of the wlink
executable in there if it's not in the $PATH
.
Yes, that can definitely be the issue. The last version in the PIO registry is
0.11.0+dev-02415-gfad123a16-dirty (2023-01-03-10:00)
when the latest Mounriver version is
0.11.0+dev-02415-gfad123a16-dirty (2023-09-22-10:36)
package updates will be pushed.
This error could also be on my side if it needs a newer OpenOCD version. That version could be before the CH32X035 chip was added. I will check this and update shortly.
As a short workaround, can you add this to your
platformio.ini
:upload_protocol = custom upload_command = wlink flash $SOURCE
And upload again. You might ned to put the full path of the
wlink
executable in there if it's not in the$PATH
.
Yes, I'm already manually using this workaround, it says it flashes the program successfully, but the UART log outputs nothing despite UART number and baud rate being configured correctly.
And, I've tried to upload a blink program in MRS, it gets stuck and never get past 00:04:05:527 >> Attempt to open link device and upgrade firmware if necessary...
I've updated the example and added notes
Maybe this helps?
I've updated the example and added notes
Maybe this helps?
I'm using the CH32X035F8U6 Evaluation Board, and that board only has one UART -- UART2, I've set the marco DEBUG to DEBUG_UART2, and then connected PA2 to my WCH-Link's RX, PA3 to WCH-Link's TX.
Yes, that can definitely be the issue. The last version in the PIO registry is
0.11.0+dev-02415-gfad123a16-dirty (2023-01-03-10:00)
when the latest Mounriver version is
0.11.0+dev-02415-gfad123a16-dirty (2023-09-22-10:36)
package updates will be pushed.
It seems like the OpenOCD is indeed updated(updated to 0.11.0+dev-02415-gfad123a16-dirty (2023-02-22-15:09)), but not to the latest version you've suggested(0.11.0+dev-02415-gfad123a16-dirty (2023-09-22-10:36))?
The package update has not been approved by PlatformIO yet, this will take some time.
If you want to test it out now, add
platform_packages =
tool-openocd-riscv-wch@https://github.com/Community-PIO-CH32V/tool-openocd-riscv-wch.git#linux
assuming you're under Linux x64.
The package update has not been approved by PlatformIO yet, this will take some time.
If you want to test it out now, add
platform_packages = tool-openocd-riscv-wch@https://github.com/Community-PIO-CH32V/tool-openocd-riscv-wch.git#linux
assuming you're under Linux x64.
This time uploading and debugging works. Tested on CH32X035F8U6.
Very good. Then this issue will be resolved automatically on the PlatformIO registry packages are approved.
The only thing I have to worry about is that the new OpenOCD version didn't work for my WCH-Link(E) that had the v2.9 firmware on it. I needed to update to v2.11 using MounRiver Studio. Then it worked again. So for people that don't regularly update their debug probe's firmware, the OpenOCD update will break their workflow. I've put a disclaimer in the README
against that.
Closing. I've just updated the OpenOCD version again. Firmware version should be kept up-to-date using the WCHISP tool as linked in the README.
As the title says, it seems like my WCH-LinkE is not recognized by openocd. openocd output:
(this does not change when I unplug the WCH-Link, so it leads me to suspect that the WCH-Link is not recognized at all.)
to confirm the I don't have an USB connection issue, I ran lsusb:
I confirm I have copied the udev rules. Upon further inspection, it seems like there's no plugdev group on my computer, which is running Fedora 38 Workstation. Specifically, after I ran sudo usermod -a -G plugdev $USER , the output of groups still does not contain "plugdev".
I found a issue related to the non-existence of a plugdev group: https://github.com/UltimateHackingKeyboard/agent/issues/901, so I modified the udev rules accordingly, to no avail.