VESC Troubleshooting in the Field: 6 Real Faults We Actually Diagnosed & Fixed
VESC TROUBLESHOOTING · FIELD CASES
Real VESC troubleshooting cases from our repair bench: the no-fault-code ghost, 72V spark traps, 120V kills, unicycle gyro locks, 5V aux burnouts and more — with the exact fixes that worked.
By the ChatRobotic VESC Team · Updated 2026 · Field notes from customer support & pre-ship testing
Our complete VESC Troubleshooting Guide covers the fault-code table and the usual suspects — DRV faults, over-temp, detection failures. This article is the companion piece: the weird ones. The cases below don't announce themselves with a cleanFAULT_CODE_DRV. They show up as "it just won't work" or "it worked yesterday." Each one below is a problem we personally traced and fixed, with the exact step that cracked it.
How to use this article: read it like a diagnostic log. For every case we give you the symptom, what we tried first, the root cause that wasn't obvious, and the fix. If your board is doing something strange, skim the symptoms — you'll likely recognize yours.
Case 1 — The "No Fault Code" Ghost (Tronic X12 24S)
This is the single most misleading VESC troubleshooting situation we see, and it fools everyone the first time.
Symptom
• Customer applied 80 V main DC and connected a PMSM motor. No LED lit at all.
• Plugged in USB → a red LED on the left of the USB port lit and stayed solid.
• VESC Tool 6.02 connected fine, and "Setup Motors FOC" ran — but the motor would not spin and the detected values looked completely wrong.
• Terminal command
faultsreturnedFAULT_CODE_NONE.• Upgraded to VESC Tool 6.05 + newer firmware. Problem unchanged.
Solid red LED + FAULT_CODE_NONE is a signature, not a mystery.
What we tried first (the wrong turns)
Because the motor wouldn't spin and detection numbers were garbage, the obvious suspect was firmware or the detection routine. So we re-ran detection, changed USB cables, and even reflashed the firmware. None of it helped — because FAULT_CODE_NONE means the logic core is alive and talking. A dead board doesn't connect to VESC Tool and show a clean "no faults" report.
The root cause
The X12 has a power switch, and the power-switch harness wasn't connected. Without that enable line, the main power stage never biases up. The MCU and USB side still get power (that's why the red LED is on and VESC Tool connects), but the FET bridge can't drive the motor — so detection reads nonsense and the motor stays still. No fault code fires because, from the MCU's point of view, nothing has "faulted."
The fix
1. Locate the power-switch connector on the X12 and seat the harness.
2. Make sure the switch is in the ON position.
3. Re-apply main DC, then re-run motor detection — values come back sane, motor spins.
💡Lesson: A solid red LED + FAULT_CODE_NONE + bizarre detection numbers is the classic "main-power enable is missing" signature. Check the switch / enable wiring before you touch firmware. We've now seen this on X12 and SEVEN series boards.
Case 2 — Sparks at 72V & the 18V "Safe Test" Trap
A customer called because, at 72 V, connecting the pack made a spark so big it was melting the plug. Their "fix" was to test at 18 V instead. That "fix" created a new problem.
What's actually happening
The spark is inrush current charging the input capacitors. Every VESC with bulk capacitance does this the instant you connect a high-voltage pack — it's normal, expected, and not a defect. You can't "test around" it by dropping the voltage.
Why the 18V test was a dead end
• At 18 V the input caps barely charge, so motor calibration fails — the wizard can't properly characterize the motor.
• The customer was using thin test leads that can't carry real current, which also skews detection.
• Net result: a "successful" low-voltage test tells you nothing about whether the board works at 72 V.
The fix
1. Wire the pack with properly sized cables rated for the real current, not breadboard jumpers.
2. Stop hot-plugging the connector. Cycle the pack on/off using the controller's own power switch — the board's switch controls the contactor/enable cleanly, so the arc happens inside the rated switch, not at the plug.
3. Only then run full detection and calibration at the real pack voltage.
💡Lesson: Don't "test" a high-voltage VESC at low voltage to dodge sparks. Use the board's switch for clean power cycling, and size your wires for the actual current. The spark isn't the enemy — an undersized plug and hot-plugging are.
Case 3 — The Silent Kill: 120V Into a Lower-Rated Board
A customer couldn't connect to the nRF chip (assumed it was read-protected), fiddled with something else, and then by mistake fed 120 V into the controller. One small pop. The board never booted again.
Symptom (the diagnostic clue)
• At 40 V the board drew zero current.
• It would not turn on.
• Touching the PCB anywhere — nothing was warm.
What that tells you
A board that draws no current and stays stone-cold after a pop almost always means the power input section is blown — and over-voltage rarely stops there. It tends to take random companion parts with it (the regulator, surrounding components, sometimes the MCU itself).
💡Lesson: Always verify pack voltage against the board's rating before connecting. A 24S unit is not a 30S unit, and one wrong plug can take out the power stage and everything nearby. We've lost boards this way that were otherwise perfect.
Case 4 — Unicycle Locks Up Under Load (Vibration + Gyro Protection)
This one looked like a controller defect. It was actually mechanical.
Symptom
Under load, a self-balancing unicycle would briefly lock up. No obvious trigger — sometimes on a hill, sometimes on rough ground.
Field diagnosis (from the customer's video)
Watching the footage, the MCU suddenly stopped outputting. Two distinct mechanisms were in play:
• Vibration > gyro filter range. On a balance vehicle, the IMU gyroscope is everything. High-frequency vibration at speed — especially with weak damping — pushes the gyro past its vibration-filter window and trips a fault.
• Sudden-acceleration protection. When the wheel goes airborne (hits a bump, bounces up) and then suddenly free-spins, the controller sees an instant, violent RPM rise from zero and protects — it cuts output. We see this exact behavior in pre-ship testing on both X12 and SEVEN series: ramp the speed up gradually and it's fine; slam it from 0 and it shuts down. Because the balance controller's acceleration is tied to the gyro, a hard jolt = "sudden acceleration" = protection.
The fix
1. Add shock absorption / better damping to the build. This alone resolved most "random lockups."
2. Don't slam the throttle when the wheel is airborne — in practice, that means don't let the wheel catch air and then suddenly accelerate (e.g., wheel pops over an obstacle, lifts, then spins free).
💡Lesson: On self-balancing builds, mechanical damping is part of the electrical fix. A "mysterious controller fault" that correlates with bumps is usually a gyro/vibration problem, not a VESC hardware fault. Rule out the suspension before you RMA the board.
Case 5 — When a Customer's Add-on Board Burns Your VESC (5V Aux Rail)
A customer's Tronic X12 died. They'd hung a small external PCB off the board's 5V output.
The misunderstanding
The 5V rail on our VESCs is meant for hall sensors and the CAN bus only — it's a small-current rail. The protection capacitor on it only fails under a 5V short or over-voltage. So people assume "it's just 5V, what could go wrong?" Plenty.
What actually happened
• The external board produced a voltage surge above 6.3 V on that rail, or drew excessive current / was shorted.
• The capacitor's ESR + high current generated localized heat and burned it out — and took the VESC with it.
• Rule of thumb: sustained current much above ~1 A on that rail, or any wrong-polarity connection from the add-on, will cook it.
The 5V aux rail is for sensors and CAN, not for powering add-on boards.
💡Lesson: Never hang a load on the 5V aux output. Need 5V for an add-on? Use a separate regulated supply. Watch for surges > 6.3 V and current > ~1 A on that rail — either one means trouble is coming.
Case 6 — Power Supply Needs a Second Try to Start (LM5163 Soft-Start)
A buck regulator on the board wouldn't start on first power-up, but worked on the second attempt. Not a VESC logic problem at all.
The component
The LM5163DDAR is a TI synchronous buck with a fixed 3 ms internal soft-start, plus UVLO, thermal shutdown and current limit.
Why the first try failed
With a large output capacitor or a heavier load, the output voltage rises slowly on the first attempt and can trip UVLO (or another protection) before it settles. On the second attempt, residual charge in the caps or a smoother input rise lets it start cleanly. Feedback-loop stability and the input source's characteristics matter too.
💡Lesson: If a buck won't start first time but does on retry, look at output capacitance, load, and input rise time — not the VESC firmware. It's a power-stage timing issue, and solving it there fixes the symptom permanently.
{{ commentCount }} Comments