ODrive Pro PWM Control: Can You Drive the Gates Directly?

Layer one first. Pull up the connector pinout before writing a line of code. An integrated servo drive of this class brings out DC bus, three motor phases, feedback, and a comms/IO header — nothing else. The six gate signals that switch the bridge are generated by a timer peripheral inside the MCU and reach the gate driver as PCB traces. There is no pin, header, or test point where an external PWM source joins that path, so the question is not whether it is allowed but whether a physical hop exists. It does not.

Where does an external PWM signal stop?

Follow the packet from your application down to the motor and mark where each hop ends. Every stage above the modulator is addressable; everything at or below it is compiled into the firmware image and routed in copper.

The lowest setpoint the API exposes is a torque/current command. Read the actual carrier and current-loop rate out of the drive's configuration and datasheet rather than assuming them — those two numbers cap the bandwidth of anything you build on top.

Why is gate-level access withheld?

Four hardware mechanisms sit between the timer registers and a working inverter, and all four fail silently if an external source drives the gates.

• Shoot-through. If the high and low switch of one leg are asserted together, or separated by less than the driver's required dead time, that leg becomes a short across the DC bus limited only by R_DS(on) and bus impedance. The device fails in microseconds — far faster than any software trip.
• Current sampling phase. Phase-current acquisition is triggered from the PWM carrier so the ADC samples inside a known conduction window. Decouple the switching from that trigger and the current measurement becomes noise, which also takes out every protection derived from it.
• High-side gate supply. A bootstrapped high-side rail needs a minimum low-side on-time per cycle to recharge. Sustained near-100% duty starves the gate drive, the FET leaves full enhancement, and dissipation climbs before anything reports a fault.
• Fault handling has no actuator. Overcurrent, bus over/undervoltage, and thermal faults act by forcing the modulator to a safe state. If the modulator is driven from outside, the latch clears nothing — the drive reports an error and keeps switching.

Add regeneration: any deceleration pushes energy back into the bus capacitors, and the firmware's clamp or brake logic is what keeps them below rating. That is the reason gate-level access is a firmware-source conversation under NDA rather than an API parameter.

Which path fits the requirement?

Decide with one question: what does your algorithm actually output? If the output is a current or torque vector in the rotor frame, the modulator is not your problem and the first row solves it with the protection stack untouched. If the output is a switching sequence — six-step, discontinuous PWM, custom vector ordering, high-frequency injection with non-standard vectors — only rows three and four apply.

How do you implement the supported command path?

1. Complete motor and encoder calibration through the normal drive procedure. A miscalibrated electrical angle offset makes every torque command a partly reactive one, and no host-side algorithm compensates for that.
2. Set the axis to the lowest-level supported control mode — direct torque/current command — so the drive's position and velocity loops are out of the path and your law owns the outer loop.
3. Set the current limit low, well under the motor's continuous rating, and current-limit the bus supply. Raise limits only after each stage of the loop verifies.
4. Run your law at a fixed period on the host and timestamp every setpoint write. Measure command-to-response round-trip latency before touching a gain — on a non-real-time host, transport jitter dominates the loop's phase margin.
5. Enable the drive's command watchdog and refresh it in the same iteration that writes the setpoint. A stalled host process must drop the axis to idle, not hold the last torque command.
6. Clamp velocity and torque in your own code as well as in the drive, so a numerical blow-up in the host algorithm hits two independent limits.

If measured step response is dominated by link latency rather than by the current loop, the fix is not a higher gain. Move to the faster transport, reduce the loop period, or accept that the algorithm belongs inside the drive — which returns you to the firmware question.

How do you pursue firmware-level access?

Gate-level and modulator-level work is handled case by case as a firmware-source arrangement under NDA. Write to ODrive Robotics' official contact address ([email protected]) with the technical case, not a feature request. Include: the application and duty cycle; the motor's electrical parameters and the torque/speed envelope; precisely which layer you need to replace (modulator only, current regulator, or the full FOC chain); why the supported control modes cannot express the algorithm; and what protections you intend to retain versus reimplement.

Whatever you receive, the responsibilities transfer with the source. Dead-time enforcement, ADC trigger phasing, bootstrap minimum on-time, bus overvoltage clamping during regen, desaturation and thermal fault response, and the safe state on fault all become yours to maintain. Budget a dedicated bench supply with hard current limiting, a current probe, and a sacrificial motor for the first bring-up. The alternative — a separate gate-driver evaluation board and discrete power stage — costs more hardware but keeps a product drive out of the failure path when the modulation experiment misfires.

How do you verify the loop before loading it?

1. Probe one phase with a current clamp against the commanded torque. Ripple should sit at the carrier frequency (or twice it, depending on the modulation), with no DC offset drift as the rotor turns slowly.
2. Log the drive's measured current alongside your setpoint and compare step rise time to your host loop period. If they are the same number, you are measuring the transport, not the motor.
3. Record bus voltage through a hard deceleration at the highest inertia you will run. Confirm headroom to the capacitor and drive rating, with the brake path or battery absorbing the regenerated energy.
4. Force a fault deliberately — stall the rotor into the current limit — and confirm torque goes to zero, the error latches, and your host code detects the state change rather than continuing to stream setpoints.
5. Soak at the intended duty and check motor and drive temperatures until they plateau, not just until the test ends.
6. Last check: with the axis moving under command, pull the host link. The command watchdog must drop the axis to idle within the configured timeout and leave the mechanism where it stops.

FAQ