Community-PIO-CH32V / platform-ch32v

PlatformIO platform for CH32V RISC-V chips (CH32V003, CH32V103, CH32V20x, CH32V30x, CH32X035) and CH56x, CH57x, CH58x, CH59x
Apache License 2.0
203 stars 34 forks source link

WCH-LinkE not recongnized #47

Open RathBee opened 7 months ago

RathBee commented 7 months ago

As the title says, it seems like my WCH-LinkE is not recognized by openocd. openocd output:

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: 1

Warn : Transport "sdi" was already selected
Ready for Remote Connections
Error: open failed

*** [upload] Error 1

(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:

lsusb | grep WCH
Bus 003 Device 012: ID 1a86:8012 QinHeng Electronics WCH-Link

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.

maxgerhardt commented 7 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.

RathBee commented 7 months ago

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]

RathBee commented 7 months ago

Closed since this issue is resolved.

maxgerhardt commented 7 months ago
  1. What chip are you connecting to the WCH-LinkE with which exact wiring?
  2. Did you ever update the firmware of the WCH-Link(E) via Mounriver studio?
  3. Does ./wlink status recognize the programmer or even the chip it's conencted to?
RathBee commented 7 months ago
  1. What chip are you connecting to the WCH-LinkE with which exact wiring?

    1. Did you ever update the firmware of the WCH-Link(E) via Mounriver studio?

    2. Does ./wlink status recognize the programmer or even the chip it's conencted to?

  1. CH32X035. SWCLK->SWCLK, SWDIO->SWDIO
  2. No, will try
  3. Yes. Its output:

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

maxgerhardt commented 7 months ago

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.

maxgerhardt commented 7 months ago

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.

RathBee commented 7 months ago

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...

maxgerhardt commented 7 months ago

I've updated the example and added notes

https://github.com/Community-PIO-CH32V/platform-ch32v/blob/abb2e1d73cec5fbd58a2b69262f2adab7b4a691e/examples/uart-printf-none-os/platformio.ini#L65-L71

Maybe this helps?

RathBee commented 7 months ago

I've updated the example and added notes

https://github.com/Community-PIO-CH32V/platform-ch32v/blob/abb2e1d73cec5fbd58a2b69262f2adab7b4a691e/examples/uart-printf-none-os/platformio.ini#L65-L71

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.

RathBee commented 7 months ago

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))?

maxgerhardt commented 7 months ago

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.

RathBee commented 7 months ago

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.

maxgerhardt commented 7 months ago

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.