3.3V power being pulled low to 2.5V, M0 pin Z shorted to Gnd

TL;DR: I tried to do the ODrive motor calibration sequence on a “robotics motor”, heard a “pop”. Now ODrive is not connecting to odrivetool, 3.3V is only 2.3-2.5V, and M0 pin Z seems to be shorted to ground.

Hi everyone,

I am new to ODrive and recently bought two ODrive V3.6 24V version motor controllers. I successfully got one of the ODrives to do calibration and closed loop control ( odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE and AXIS_STATE_CLOSED_LOOP_CONTROL) by following the Getting Started guide with a Turnigy gimbal motor 5208 and an AMS 5047P encoder. So far so good.

I attempted to do the same with a “robotics motor” similar to this one from T-Motor with an AMS 5047P as the encoder. [As an aside, don’t get the T-Motor one if you’re looking for something similar, the gears don’t mesh well when I had the chance to try it out and it is overpriced. Let me know if you need suggestions!] What it is essentially is a large BLDC motor with a planetary gear set within the stator space. When I came to the full calibration sequence step, the motor would only jolt and move a tiny bit. Subsequent commands would not move the motor (despite the power led being on) until I power cycled the ODrive. With dump_errors(odrv0) in odrivetool, I see that the error is ERROR_MODULATION_MAGNITUDE. Thinking that maybe the issue is with motor.config.calibration_current and motor.config.current_lim, I repeated the above steps a few times with different values and got the motor to make the “thunk” sound a few more times.

That’s when I heard a “pop” sound and my hand immediately hit the E-Stop on my power supply. I felt all the components on the board but nothing felt very hot. When I tried to turn the ODrive back on, the power (PWR) led would turn on, but the board no longer connects to odrivetool. Using a multimeter, I found that the 3.3V output on the headers is only 2.3-2.5V. Also, pin Z (this is probably the encoder index signal pin?) of axis 0 (M0) is now shorted with ground.

I tried to address the 3.3V issue first. After looking through the V3.5 schematics and with my working ODrive, I verified that I could power the board externally with just a 3.3V power supply to the 3.3V and GND header pins. This leads to the PWR led lighting up and odrivetool connects to the working ODrive. When I tried this step with the non-working ODrive, the 3.3V pin remains stubbornly at 2.3-2.5V and odrivetool fails to connect. I de-soldered and removed the 3.3V regulator (U3) thinking that it might be the problem but the 3.3V power supply still remains at 2.3-2.5V and odrivetool fails to detect the ODrive board.

Does this mean that the microcontroller (STM32F405RGT6) is the issue and needs to be replaced? Or is something else the problem? Based on my understanding of the V3.5 schematics (I’m assuming no big changes in V3.6), the only thing connected to M0 pin Z (M0_ENC_Z in the schematics) is the microcontroller.

Also how did this happen and what steps should I take to avoid this in the future?

Thank you for reading so far and I appreciate all suggestions!

Interesting. I am also looking at using those t-motor robot actuators. Most of the stuff from t-motor is very good (though expensive). Interested to hear about alternatives!

  • What current limit did you set?
  • Did you have the brake resistor fitted?
  • Have you checked for any possible short circuits between your motor and encoder wiring? (or between motor and ground)

Try forcing (with an external power supply) 3.3V between the 3.3V pin and GND. It might power up, or else a damaged part might get warm or emit smoke, so you can replace that part (probably the micro as you suggest).

If you do replace the micro, obviously you will have to reflash using an ST-link.

ERROR_MODULATION_MAGNITUDE means the PWM duty for the current control hit 100%. Normally this means the motor is open-circuit or your DC bus is too low for the commanded speed, or the current loop controller is unstable. It may be that the motor calibration (did you hear the motor “beep”?) somehow misidentified the motor’s resistance and inductance, and built an unstable current controller (although this shouldn’t lead to smoke).
Next time run the MOTOR_CALIBRATION_SEQUENCE first and check the identified resistance and inductance against the motor’s datasheet.

Out of interest, why did you buy the 24V version for this motor and not the 56V?


Hi @towen,

Yes, I was surprised too when I visited their office and got a feel of their actuator. The reasoning I heard from locals on why it doesn’t feel as smooth is that while T-motor make really good BLDCs for drones, they have never worked with gears before and might have handed off that part to a 3rd party. I had the opportunity to get at tour of China motor manufacturers such as this company and this one. However, both companies have integrated their own motor driver that comes with little to no documentation. From a 3rd company, I got an unreleased motor that does not have a motor driver, so I thought of using ODrive to drive it since it seems to be mature and well-documented.

  • The current limit was set to the default 10A (odrv0.axis0.motor.config.current_lim)
  • Yes, the default 0.5 ohm brake resistor that came with the ODrive
  • Yes, I checked for short circuits between the motor, encoder, and housing.The only short is between M0 pin Z and Gnd on the board, not on the motor/encoder side

I tried forcing 3.3V again, and the microcontroller was indeed getting warm. I guess this means that it is dead and I’ll have to replace it. I have an ST-Link, so hopefully reflashing the firmware will be straightforward. I’ll update here once I get the parts and have tried replacing the STM32F4 microcontroller.

Using my remaining working ODrive and a gimbal motor, I tried running odrv0.axis0.requested_state = AXIS_STATE_MOTOR_CALIBRATION, but the motor doesn’t move (this is what you meant by MOTOR_CALIBRATION_SEQUENCE I presume). This is with odrv0.axis0.motor.config.motor_type = MOTOR_TYPE_GIMBAL. Then I tried odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE and now the motor jolts, then turns one direction and then the next. I never hear a “beep” though, is this a problem?

Running odrv0.axis0.motor after that gives me this:

p_gain = 0.0 (float)
max_allowed_current = 60.75 (float)
I_measured_report_filter_k = 1.0 (float)
overcurrent_trip_level = 67.5 (float)
Iq_setpoint = 0.0 (float)
final_v_beta = 0.0 (float)
Id_measured = 0.0 (float)
v_current_control_integral_d = 0.0 (float)
v_current_control_integral_q = 0.0 (float)
Iq_measured = 0.0 (float)
final_v_alpha = 0.0 (float)
i_gain = nan (float)
Ibus = 0.0 (float)
phase_current_rev_gain = 0.02500000037252903 (float)
current_meas_phB = 0.0853261649608612 (float)
drv_fault = 0 (int)
is_calibrated = True (bool)
thermal_current_lim = 45.943763732910156 (float)
TIMING_LOG_ADC_CB_DC = 12858 (int)
TIMING_LOG_ADC_CB_I = 2578 (int)
current_meas_phC = 0.12658464908599854 (float)
pole_pairs = 7 (int)
pre_calibrated = False (bool)
current_lim_tolerance = 1.25 (float)
resistance_calib_max_voltage = 2.0 (float)
inverter_temp_limit_lower = 100.0 (float)
calibration_current = 10.0 (float)
phase_resistance = 0.0 (float)
motor_type = 2 (int)
current_lim = 10.0 (float)
requested_current_range = 60.0 (float)
inverter_temp_limit_upper = 120.0 (float)
current_control_bandwidth = 1000.0 (float)
direction = -1 (int)
armed_state = 0 (int)
DC_calib_phB = 0.31971243023872375 (float)
error = 0x0000 (int)
DC_calib_phC = -1.817695140838623 (float)

The measured phase resistance of the gimbal motor is 11.3 ohms on each of the 3 phases, but phase_resistance = 0.0 (float) is wrong I guess? The robotics motor I have has a phase resistance of only 0.5 ohms. Is this something wrong with the calibration step? Strangely enough, odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL and odrv0.axis0.controller.pos_setpoint = 10000 both still work with the gimbal motor.

I got the 24V version as the motor’s rated voltage is 24V so I thought that was adequate. Was this a bad assumption?

What other steps could I take to hopefully not fry my remaining ODrive? Thanks for the help Tom!


Hi Michael,

Are you trying to drive the large motor as a gimbal motor (i.e. MOTOR_TYPE_GIMBAL) or in closed-loop current mode (MOTOR_TYPE_HIGH_CURRENT). They are obviously quite different. I would expect if you tried to drive a big, normal motor in “gimbal” mode, then something might go bang!

The difference between the two modes, as I understand it, is that the gimbal mode does NOT use the current sensors. Gimbal motors have a large winding resistance and are designed to be driven open-loop, on the assumption that an applied voltage roughly translates to a certain current (back EMF is not modeled, because they are only designed to go at very low speeds). Whereas normal motors are inductive but have an extremely low resistance, and they have a lot of back-EMF, so current is no longer proportional to voltage.

In terms of the calibration sequence - I’m not sure what MOTOR_CALIBRATION does for the gimbal types. In the normal motor mode, it would first measure the phase resistance using the current sensors, and then measure the inductance using a known frequency (that’s when it beeps).

If you tried to put a large, low-resistance motor on the odrive in gimbal mode, then the current might rise so quickly as to damage something, i’ve never tried it.

Honestly I think the MOTOR_TYPE_GIMBAL mode should be considered an experimental feature not for general use, and MOTOR_TYPE_HIGH_CURRENT is badly named and badly documented, because it should be obvious that this is the normal operating mode.
Gimbal motors work perfectly fine under the closed-loop FOC scheme provided by MOTOR_TYPE_HIGH_CURRENT.

And yeah, definitely go for the 56V version. Chinese motor manufacturers including T-motor specify their voltage ratings in a way which is inappropriate for servo motors. When they say 24V rating, they are really talking about the motor’s back-EMF at the mechanical velocity limit of the gearbox. You could put it on 100% demand with a standard dumb ESC, and it would hit its rated speed somewhere around 24V at the PSU.
For a servo motor, you always need voltage headroom to be able to change the torque quickly, i.e. to achieve a high current-control bandwidth against the motor’s inductance. This is why industrial servomotors tend to be rated for 600V DC (rectified 415V 3-phase mains) but you would never run them at a speed where their back-EMF gets anywhere near that.
Generally, for a servo motor, the higher the voltage you can use, the better. This is limited by the winding insulation of the motor (but most standard insulation is good up to the hundreds of volts) and by the controller both in terms of absolute voltage and in terms of dI/dt. Also beware of any transmission-line effects if you are running your motor on the end of a long cable. This gets worse at high voltages and high dI/dt but probably fine at <100V.

Hi Tom,

Thanks again for enlightening me! Just to clarify, I only set the MOTOR_TYPE_GIMBAL mode when I was using the gimbal motor, but I cannot discount the possibility that I had gotten careless and neglected to switch it back when using the robotics motor. If we can’t think of any other causes, I’ll chalk the cause of the fried ODrive up to this reason, and be more careful when I’m trying this again with my other working ODrive.

In terms of the calibration sequence - I’m not sure what MOTOR_CALIBRATION does for the gimbal types. In the normal motor mode, it would first measure the phase resistance using the current sensors, and then measure the inductance using a known frequency (that’s when it beeps).

I was wondering how the beeping occurs since I didn’t see anything on the ODrive itself that would produce sound! This makes more sense! So possibly the expected behavior of AXIS_STATE_MOTOR_CALIBRATION when using a gimbal motor is to skip over the phase resistance and inductance measurements and just turn the motor. That would also explain why phase_resistance = 0.0 (float) remains at zero if it is never measured for a gimbal motor. Maybe @madcowswe can verify that this is indeed the case? I’ll see if I have a normal BLDC lying around that I can try AXIS_STATE_MOTOR_CALIBRATION with again.

I’ll see if I can fit the 56V ODrive + power supply into my budget soon. Do you mean to say that even though the rated voltage of a BLDC is only 24V, I should run it at a higher voltage (i.e. supply 48V or 56V to the bus voltage?) or is there a setting on the ODrive to make the motor voltage lower than the bus voltage (to get the voltage headroom you mentioned)? Really glad to be able to chat with someone as knowledgeable about motors as you!


Do you mean to say that even though the rated voltage of a BLDC is only 24V, I should run it at a higher voltage (i.e. supply 48V or 56V to the bus voltage?) or is there a setting on the ODrive to make the motor voltage lower than the bus voltage (to get the voltage headroom you mentioned)?

Yes I mean to say that you can run it at a higher bus voltage than the voltage corresponding to the rated speed, provided that you set your vel_limit appropriately so as to not accidentally overspeed the gearbox.
The motor itself will tolerate much higher voltages (after all, it is only a coil of wire), and it only sees those voltages as transient spikes, because the ODrive is reducing the RMS voltage (by PWM switching) to push whatever current demand it is trying to achieve. There’s no settings needed to do this, it’s part of the control scheme.

Ok good to know, I’ll try it out when I get the 56V version of the ODrive.

Thanks Tom!

Yes this is probably what happened. This disables the current sensing entirely, and hence there is no good over current protection. I think there is some built into the DRV chips, but I don’t think we ever configured that correctly since we upgraded the FETs.

    } else if (config_.motor_type == MOTOR_TYPE_GIMBAL) {
        // no calibration needed
    is_calibrated_ = true;
    return true;

I.e. it does nothing. This is also why there is no beep for the gimbal motor setting.

The reason we added it is to bypass the current controllers and assume I = V/R. This is because the current sensors are too noisy to handle gimbal motors low nominal current. But I agree the terminology is confusing, and we should just have a setting to switch from closed loop current to open loop current, and say that you should do this for gimbal motors.

Indeed, they rate the voltage for “full throttle dumb ESC” use, rather than a controller with a velocity limit. I agree, it’s better to have voltage headroom, especially since there is a 80% modulation limit on the ODrive.

Yes, I’m starting to suspect that I had accidentally not switch the motor types back when I changed from using the gimbal motor to the robotics motor.

Ok that makes sense. Thanks for clarifying!

Sounds good, looks like I’ll be getting the 56V version in the future!

hopping in to ask more about your experience with the T-motor A80-6 and the 2 other motors you tried, I am very interested in these kind of compact high torque actuators for some projects im doing, which do you think is the best way to go?

Hey @Anshuman_Medhi,

I would say that the space for these compact high torque actuators is very hot right now with a bunch of actuators released in just the past few months from China. I’m still working on fixing my ODrive so I can get to testing them, I’ll post an update here when I’ve done so! For now these motors are brand new, so if you do buy any of them, be aware that there won’t be much documentation at all on how to use them.