Have a Heltec V3 ESP32-S3 Meshtastic radio which works but cannot update and the usual "use a good cable" and "has drivers installed" questions have amply been verified in your testing? So did I! Here's how I resolved this annoying issue, (and surprise surprise, it had nothing to do with the cable or driver...).
The affected device is the Heltec V3 radio with an ESP32-S3 CPU designed for use on the Meshtastic network. The specific hardware version is 3.2.
The symptom of this issue is that the radio works as expected and can be connected via clients and phones during normal operation.
USB communication via the built-in UART-to-USB controller even works during standard use.
The issue arises when attempting to perform a firmware update.
The flashing utility will reset the device into DFU mode to start the transfer, but then the radio will simply refuse to respond to any commands.
The USB controller on the radio is still working as it is visible in lsusb
(or device manager if that's your jam), but just will not respond with any serial messages.
Restarting the radio to place it back into standard mode re-enables the USB interface and communication works as expected again.
Even manually placing the radio into DFU mode, (via holding PRG
while pressing RST
) results in the same problematic behaviour.
Following the Meshtastic guides, the only answers are "use a better cable" and "just install the drivers". In my case, both answers got rather annoying real quick, as I flashed the original firmware with the specific cable just days prior and the driver for serial communication has been baked into the Linux kernel for decades.
To verify though, I used multiple cables and even multiple host computers in an attempt to yield a different result. Luckily to simplify my testing, I had 3 radios, all the same model and hardware version. 2 of the radios suffered from the same issue whereas a third accepted new firmware without any complication.
This allowed me to rule out user error and hardware incompatibility.
Since the Meshtastic documentation was a loss and Heltec documentation fared no better, I opted to dive deeper into the hardware to see if I could find any clues to assist me.
Espressif, the actual manufacturer of the CPU that powers the Heltec radio, offered throughout and detailed documentation for utilizing the internal JTAG controller bundled with the CPU.
In addition to the USB controller which Heltec implemented, the CPU also has a USB-compatible JTAG interface built directly into the CPU that Espressif wired to pins 19 and 20 on their reference development board. Luckily Heltec was nice enough to directly wire this same interface to GPIO 19 and GPIO20, (verified with a microscope and manually following the traces).
GPIO | USB |
---|---|
20 | D+ (green) |
19 | D- (white) |
GND | GND (black) |
5V | +5V (red) |
These pins map to the first 2 pins for GND and VCC and last 2 pins for Data. I soldered some pin headers to these 4 connectors so I can attach/detach a USB cable as needed.
Additionally I took a USB cable, lobbed off the client side, and soldered some jumpers in place of the connector. This allowed me to quickly use the same cable to flash multiple radios when needed.
Once plugged in, the device powered up thanks to ground and 5v being applied via the USB cable and it was exposed to the host workstation via /dev/ttyACM0
, (vs ttyUSB* that the normal USB interface creates).
This was my first clue that it may have a chance, as that port is the Abstract Control Model
which indicated it was a different device on the radio side and should allow raw data to be able to be transmitted directly to the ESP32 CPU on the radio.
Loading up the flasher in Chromium and running through the normal updating procedure, (albeit selecting /dev/ttyACM0 instead of /dev/ttyUSB0), worked flawlessly and allowed me to flash the radios!
I have no f...ing idea why this occurred in the first place. I was able to flash the radios when they first arrived, but any subsequent attempt just failed. My suspicion is that whatever USB controller Heltec opted to use failed to communicate with the device CPU, probably due to a hardware bug. (It wouldn't be the first hardware bug this V3 has...).
Even stranger is I have 3 radios and only 2 of which had this issue. The third was able to flash normally via the provided USB-C connector. (Although now I know how to resolve that should that radio ever decide to stop accepting firmware updates.)