Reflashing a bricked WCH-LinkE

[wilhe_jo]

Any idea how I could get it working again?

Assume you want to upload CH32V307 devboard. You can set jumpers "boot0" to vcc, "boot1" to gnd, next you can connect directly via CH32V307 usb-HS-port (marked on devboard). WCHISPTool will recognize chip and work with it.

No, this is not what I want!
I want to use the wlink integrated in the dev board to flash & debug.
The problem is, I had to update the firmware on the CH549 for the new MRS. This failed in the Windows 10 virtual machine.

Now I'm left with a bricked wlink!

I found the isp55e0 tool that actually can flash the CH549.
However, all firmware files i found so far did not restore my wlink.
My thinking was, that one of the firmware files supplied with the MRS would fix this.. so I tried flashing WCH-Link_APP_IAP_RV.bin, FIRMWARE_CH549.bin, WCH-Link_APP_IAP_ARM.bin and FIRMWARE_DAP_CH549.bin.... but none of them worked.

Interestingly, I cannot get the ISP-bootloader of the CH549 to show up under virtualbox...seems some USB-IO-problem that prevents this .... I found comments, that the bootloader is a little picky, so I guess it's a firmware problem.

Any idea how to bring the device back to life??

Regards

[Postal2]

No, this is not what I want!
I want to use the wlink integrated in the dev board to flash & debug.

Buy very cheap wch-link on aliexpress and resolder CH549 to your board.
https://aliexpress.com/item/1005003346413532.html

[wilhe_jo]

No, this is not what I want!
I want to use the wlink integrated in the dev board to flash & debug.

Buy very cheap wch-link on aliexpress and resolder CH549 to your board.
https://aliexpress.com/item/1005003346413532.html

well, I would do that if I had time and I was sure that the one is flashed with a recent firmware!


But I finally (after a good day of hating WCH!), I got it to work.

The tool, that helped me is the CH552tool (https://github.com/MarsTechHAN/ch552tool/tree/master).

I first erased everything as suggested by the WCH-LinkUserManual (that pdf linked at the beginnin of this thread).

this can be done with

Code: [Select]

$ python3 ch55xtool.py -e -c

now flash the firmware and let it reset (I guess, the "-R" is optional if you power-cycle afterwards).

Code: [Select]

$ python3 ch55xtool.py -f /opt/wch/mounriver-studio-community/update/Firmware_Link/WCH-Link_APP_IAP_RV.bin -r
if you have the "-r" option, it would fail since the programmer resets after programming. Not nice, but it now shows up as a WLink instead of the bootloader.
Without "-r" it would finish correctly and you have to power-cycle manually.

Hope that helps some people out there!

I tried a good bunch of other programming tools and it seems none of them allow you to erase the flash/data memories...
I also tried basically every programming tool from the WCH website... non of them recognized the ISP bootloader (or I was simply too stupid getting them to work).
Virtualbox also "crashed"/has frozen several times when connecting/disconnection/reconnecting the programmer.
This may result from some bugs in the bootloader, that are mentioned somewhere on the web.
My best guess is, that these made the update fail in the VM...

However, my programmer now works

Regards

[Postal2]

well, I would do that if I had time and I was sure that the one is flashed with a recent firmware!

Mounriver under Windows 10 like it.

The tool, that helped me is the CH552tool (https://github.com/MarsTechHAN/ch552tool/tree/master).

WCHISPTool I showed above is much more reliable.

I tried a good bunch of other programming tools and it seems none of them allow you to erase the flash/data memories...
I also tried basically every programming tool from the WCH website... non of them recognized the ISP bootloader (or I was simply too stupid getting them to work).

I guarantee WCHISPTool I showed above can do that work perfectly, it's tested with CH549. CH549 has 64kB flash I need for tables, therefore I bought some wch-links because it's cheaper than naked chip.

[wilhe_jo]

well, I would do that if I had time and I was sure that the one is flashed with a recent firmware!

Mounriver under Windows 10 like it.

The tool, that helped me is the CH552tool (https://github.com/MarsTechHAN/ch552tool/tree/master).

WCHISPTool I showed above is much more reliable.

I tried a good bunch of other programming tools and it seems none of them allow you to erase the flash/data memories...
I also tried basically every programming tool from the WCH website... non of them recognized the ISP bootloader (or I was simply too stupid getting them to work).

I guarantee WCHISPTool I showed above can do that work perfectly, it's tested with CH549. CH549 has 64kB flash I need for tables, therefore I bought some wch-links because it's cheaper than naked chip.

Well not for me...

I had absolutely no luck with Win10 in a VM.
The tool does net even recognize the device even though it is present!

However, now I have the next problem... I get LibUSB timeouts .... AHHHH.... why is there no reliable programmer!!
Segger has its on problems, but their programmers/debuggers just always work.

73

[Postal2]

Well not for me...

I had absolutely no luck with Win10 in a VM.
The tool does net even recognize the device even though it is present!

As you can see on my screenshot above, WCHISPTool nicely working on Windows XP.

[MarkMLl]

So I followed the instructions, got a win10 virtual machine running, got the wch-link-tool and that asked me if it should update.
Now I'm left with a blnking blue LED...

I refuse to get drawn into a discussion of Windows and Windows-related VMs, but from earlier messages in the thread you will see that my problems were, by and large, related to the fact that when the role of the chip changed so did its vid:pid doublet.

Over the last year or so I've "played around" quite a lot with containerised microcontroller and FPGA development tools, and hardware access problems almost always boiled down to allowing the "guest" software, which should be running with limited access to "host" facilities, sufficient permissions to access arbitrary (USB etc.) devices and possibly to force re-enumeration of the (USB etc.) busses.

Simply moving from closed- to open-source tools won't fix this since it's the change-of-role that is significant. At the very least, you would need one set of tools to talk /through/ the programming device and another to talk /to/ it when it wanted its own firmware updated.

MarkMLl