Weird problem with WCH-LinkE programmer

• Weird problem with WCH-LinkE programmer
  Posted by HwAoRrDk on 29 Nov, 2023 07:02
• 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 is not powering 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 the WCH-LinkE to die and become completely unresponsive! And somehow this persists even 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?
• #1 Reply
  Posted by HwAoRrDk on 29 Nov, 2023 07:13
• 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 the schematic 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 off because the WCH-LinkE fails to enumerate, or the other way around - there is some other fault occurring that shuts off the USB port and that causes the enumeration failure error in Windows.
• #2 Reply
  Posted by HwAoRrDk on 29 Nov, 2023 12:47
• 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 up so badly that 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?