Weird problem with WCH-LinkE programmer - Page 1
Forum section: electronics / general

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 29, 2023, 07:02:20 am
content: I've encountered a weird problem with my WCH-LinkE programming adapter that I'm at a loss to explain. I simply can't fathom what is going on.I've got this project involving a CH32V003 that I've been working with on-and-off for a while that involves it emulating an I2C EEPROM connected to a Raspberry Pi. I've been working towards allowing the emulated EEPROM contents to be written to from the Pi. Now I'm at the stage where I'm trying to test my code.The weird problem I ran into with the WCH-LinkE is as follows:1. The CH32V003 is connected via I2C to the Raspberry Pi. The WCH-LinkE is connected to SWIO, RST, UART TX, UART RX, and GND. It isnotpowering my device. I also have a Saleae clone logic analyser connected to the I2C bus.2. When I attempt to write to the emulated EEPROM from the Pi, I have some kind of bug in my code (yet to be determined) that causes the MCU to crash or lock-up (possibly an exception occurs or maybe it gets stuck in a loop, I dunno).3. For some reason, this causes theWCH-LinkEto die and become completely unresponsive!And somehow thispersistseven when I un-plug and re-plug its USB connection to my PC, because it fails to enumerate when I do so (with error message popup from Windows - "USB device not recognised").And as if that wasn't weird enough, there's more:The WCH-LinkE only refuses to enumerate with the two specific USB2 ports on the front of my PC (one of which it was originally connected to). I can re-connect it to one of the USB3 ports on the front, and it works fine straight away. And I can un-plug from there straight back to a USB2 port and it doesn't work again. But after an indeterminate amount of time, it will work again in the USB2 ports.I don't know WTF is going on here. Anyone got any ideas?

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 29, 2023, 07:13:15 am
content: Oh, one other thing I noticed: when the WCH-LinkE fails to USB enumerate, I noticed that the red LED on-board comes on for a second, then goes off again. Looking at theschematic for the WCH-LinkE, I see that the red LED is tied directly to 3v3 (that is, it's not GPIO controlled). The 3v3 is generated by a linear regulator, which is fed directly by VBUS. So if the red LED is not lit, then that means there is no VBUS being supplied to the WCH-LinkE...I'm wondering if the VBUS is being shut offbecausethe WCH-LinkE fails to enumerate, or the other way around - there is some other fault occurring that shuts off the USB port andthatcauses the enumeration failure error in Windows.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 29, 2023, 12:47:27 pm
content: I figured out what the bug in my code was. When specifying the flash addresses to be erased or written to, I was using addresses based at 0x0 (where flash is mapped when booting normally - i.e. not bootloader) rather than the non-remapped addresses based at 0x08000000. Just by making that change, everything works without incident now.But I am still mystified as to how instructing the flash controller to erase or write to an incorrect 0x0-based address could mess things upso badlythat not only the MCU crashes but the WCH-LinkE is also K-O'ed.I wonder if it's anything to do with the flash controller documented as generating a "bus error" if you do something wrong like not unlocking the flash for writing or writing to an incorrectly-aligned address, etc. But surely that manifests as a handle-able hard-fault IRQ and not something that totally discombobulates everything?