Bringing a drive up
Everything else on this site is about getting the control law right. This page is about the order you switch it on in, which is a separate skill and the one that decides whether a fault is diagnosable.
The governing idea is not caution. It is that a regression should have exactly one candidate cause. Every step below exists because it isolates one thing, and the sequence is chosen so that when something breaks you already know what changed.
Nothing drives the bridge until something else has
The instinct when replacing a working control stack is to swap it in and see. That gives you a firmware that has never run, and a first bench test with a hundred candidate causes.
The alternative costs almost nothing:
The new code consumes the same inputs as the incumbent, every cycle, and its outputs go nowhere. Differences accumulate in RAM and are read out over a debug probe while the machine runs. Only when they agree is the flag flipped — and the flag is switchable mid-run, which turns a live takeover into a routine test rather than a gamble.
On the rig behind these pages that is exactly what happened: a takeover from the vendor current loop to a new one at 800 rpm, and a handback, without stopping.
On the bench Compare pure functions and stateful ones differently, or the comparison will mislead you in both directions.
Pure functions must match to numerical noise. Clarke, Park and the modulator have no memory, so given the same inputs they either agree or one of them is wrong. On the rig the new modulator matched the vendor’s to 0.009% — which is the vendor’s Q1.15 quantisation floor, not a tolerance anyone chose.
Stateful ones cannot. Two regulators with different integrator histories will not agree sample by sample even when both are correct, so compare them as envelopes. Demanding bitwise agreement from a PI pair is how you spend a day chasing a difference that means nothing.
The order
Each step turns on exactly one new thing, and ends with a run.
| Step | What a failure here means | |
|---|---|---|
| 1 | Clocks, pins, PWM outputs — no power to the bridge | wiring or pinmux, nothing else |
| 2 | Gate signals on a scope: deadtime, complementary pairs, alignment | the modulator or the PWM configuration |
| 3 | ADC triggered and converting, motor disconnected | the trigger chain or the sample instant |
| 4 | Offsets calibrated, currents scaled and plausible at zero | gain, bias or a shunt |
| 5 | Bridge powered at a low bus, open loop, no rotation | the power stage |
| 6 | Current loop closed, rotor locked | the regulator, in isolation from the machine |
| 7 | Rotor released, angle from a sensor | the angle, and only the angle |
| 8 | Speed loop, then the outer loops | the cascade |
Steps 6 and 7 are the pair worth defending. Closing the current loop on a locked rotor removes back-EMF, the angle, and the mechanical system from the experiment all at once: what is left is a first-order electrical plant and a PI controller, which is the only configuration in which a current-loop problem is unambiguous. It is also the configuration that measures the machine, so the step pays for itself.
Low bus first, and why it is not just caution
Every failure mode of a bridge scales with the DC link. A shoot-through at 12 V is a warm transistor; at 400 V it is a crater and no evidence. Bring the bus up at the lowest voltage that will produce measurable current.
The same applies to the current limit. Set it to something the machine can survive indefinitely rather than to the value the drive will eventually use — you want the first fifty faults to be recoverable, because there will be fifty.
Instrument before you need to
The single most useful decision on the rig behind these pages was forced by a defect: the serial console’s receive path was dead, so every measurement was taken by reading and writing target memory over SWD while the motor ran.
That turned out to be better than the console would have been, and it is worth choosing deliberately:
- Keep the drive’s state in a small number of known globals, so a probe can find them by symbol.
- Make tuning parameters plain variables you can write live, not compile-time constants.
- Accumulate counters and error sums in the fast loop; sample them asynchronously.
A debug probe then becomes an oscilloscope for your control law, and the alternative — rebuilding to change a gain — is slow enough that you will stop trying things, which is the real cost.
Keep a witness
Mentioned on the architecture page and worth repeating in a bring-up context, because bring-up is when it earns its keep: an independent measurement the control law does not use.
On the rig, a sensorless start once reported a healthy RUN state at 435 electrical rad/s while the shaft stood still. The observer had locked onto a phantom. The frozen encoder count — a value nothing in the control path consumed — was the only thing on the board that disagreed.
What to take away
- Order the steps so a regression has exactly one candidate cause. That is the whole principle; the specific sequence follows from it.
- Run the new code alongside the incumbent before it drives anything, and make the switch a runtime flag rather than a build.
- Pure functions must agree to numerical noise. Stateful ones must not be expected to — compare envelopes.
- Close the current loop on a locked rotor first. It is the only configuration where a current-loop fault is unambiguous, and it doubles as parameter identification.
- Low bus, low current limit. The first fifty faults should be survivable.
- Put the state in known globals and read it with a probe. Rebuilding to change a gain is slow enough that you will stop experimenting.
- Keep one measurement the control law never uses.