Dual MC33926 Motor Driver Carrier - Application

I have ordered the Dual MC33926 Motor Driver Carrier, but upon a review of the available documentation I’m not sure I know how to use it. I am not an EE and my hardware skills are limited.

Is there a document that describes how to set up and use the device in various scenarios, i.e. various jumper settings and corresponding wiring diagrams? Invalid/destructive combinations of jumpers to avoid?

The devices I’m familiar with have inputs for speed (PWM) and direction for each motor. I would also like to implement coast and stop.


I have now received the Dual MC33926. There are no instructions and no jumpers. Am I misunderstanding the idea that jumpers are available to limit the number of control lines required?

I have just about figured out everything except the reason for two PWM inputs on each motor. Why two? How should they be used? I would really appreciate it if someone could explain this.


The truth table on page 17 of the datasheet for the MC33926 shows the output status for various input configurations. If you use only the IN1 and IN2 pins, you can put the motor in forward, reverse, or brake mode. Either D1 or D2 can be used to coast. The table should be useful for determining what state the various jumpers will put the motor driver into as well. If you think you would like to use a particular configuration of the driver, but are not sure what it will do, we can look at it if you post about it here.


Thanks for your reply. I think I have IN1 and IN2 figured out, but I’m still puzzling over the two PWM inputs (D1 /D2). Why are there two? Why are they referred to as “disable” pins? Why is one of them inverted? Does it require a different kind of PWM input than the other one? Why would I want a PWM duty cycle of 70% to result in a motor duty cycle of 30%? Sorry to be dense, I’m just trying to understand.

Also, I find this statement from the product description difficult to understand: “The control lines can be reduced to two pins per channel if PWM signals are applied directly to the two input pins with both disable pins held inactive.” Does this mean that D1 and D2 should be held low and the PWM signals applied to IN1 and IN2? Sounds unlikely, but what does it mean.

Finally, I’m still in the woods about the “jumpers”. Since there are no actual jumpers, I’m assuming that various pins should be tied together or grounded, but it’s not clear which ones or what the result of a particular “jump” would be.

If you can point me to some relevant reference material or a practical tutorial I would appreciate it.

The two disable pins (D1 and D2) have very similar functions, though the logic for them is inverted. When activated in a certain manner (either pulling D1 HIGH or D2 LOW), they will turn off all of the FETs in the H-Bridge, which will allow the attached motor to coast. Generally when we build a carrier board for an IC like this, we break out all of the features that the manufacturer has made available on the IC. Having inverted logic can be handy for many things, for instance if you wanted one motor to speed up as another slows down, and in general, this driver is set up to be very versatile.

The “Free Wheeling High” and “Free Wheeling Low” modes in the truth table I mentioned before both short the leads of the attached motor together, which will cause it to brake. If D1 is jumpered LOW, D2 is jumpered HIGH, PWM is applied to IN1, and IN2 is pulled LOW, the motor will operate in a PWM drive forward/brake cycle (drive forward when IN1 is HIGH, brake when IN1 is LOW). For a drive reverse/brake cycle, IN1 is held LOW and PWM is applied to IN2, instead.

Just to illustrate an alternate usage, if, instead of a drive/brake PWM cycle you wanted a drive/coast PWM cycle, you could jumper D1 LOW, apply PWM to D2 and run forward by pulling IN1 HIGH and IN2 LOW or in reverse by pulling IN1 LOW and IN2 HIGH.

There are no jumpers included with the board, however, we have placed the headers in a manner where it is easy to use standard jumpers to pull pins in directions that might make sense. For instance most applications will only use D1 or D2, not both, so there is a GND pin next to D1 to make it easy to pull LOW and a VDD pin next to D2 to make it easy to pull HIGH.


Thanks, that helps a lot.
I appreciate your patience.


Borrowing this old thread if thats ok?

I’ve just hooked up this board. Bought it to “get around” a braking problem using simpler L9110S h-bridge.
Read that mosfet h-bridges was better at braking.

So coasting is when you let the motor stop by itself if I understood correctly. Not what I want.

Using the MC33926 together with a Micro Metal Gearmotors 298:1 HP extended shaft and optical encoders.

I have created a moveSteps() command that is supposed to do x number of steps and then brake. But I’m consistently overshooting all the time by a number of steps that seems to be somewhat relative to the speed.

My config is the following:

  digitalWrite(MYMOTOR_PIN_ENABLE, HIGH); 
  digitalWrite(MYMOTOR_PIN_SLEW, LOW);    
  digitalWrite(MYMOTOR_PIN_D2, HIGH);
  digitalWrite(MYMOTOR_PIN_D1, LOW);

Steps are counted in an interrupt routine

//Starting motor, move_yes/no depends on direction:
  pwmWrite(move_yes, speed );
  digitalWrite(move_no, LOW );  

Looping for x number of steps 
End Loop if steps reached

// Stop motor using hard brake
  digitalWrite(move_yes, LOW );
  digitalWrite(move_no, LOW );

What I’m seeing is that:

Steps vs overshoot
1 4-13
10 30-32
100 77-79

Maybe this is a too simplistic approach. Been looking PD/PID controllers but not sure…

Soo the question really is. Am I coasting or really braking. There is a twitch of the motor that indicates to me that I’m braking and its just not enough. Off course this will probably vary by load. Testing using no load.

I tried calculating a “pre-brake” factor where I try to estimate the overshoot using a pre-calculated table and simply stopping x-number of steps early. Not by any means consistent.

Starting to understand that braking a DC motor is somewhat complicated…


You are missing pin assignments, so I could not follow all of your code, but in general, using active braking on an H-bridge will stop the motor quicker than coasting, but not instantly. When coasting, you are relying primarily on mechanical friction in your system to slow the rotation. Braking with an H-bridge typically shorts the positive and negative leads of the motor together so that the motor behaves as a generator with an electric load.

Generally, if you are trying to do some precise position control with a motor, you will get much better results from using a closed-loop feedback system. It sounds like you are on the right track with a PID controller.


Thanks for the quick reply Nathan!

Ok you are right, move_yes and move_no goes to IN1 and IN2.
I made a calibration routine that fills a table with steps and speed vs overshoot for some “important numbers”.
And in between I interpolate. The table then better reflects overshoot based on load.

But when I do my moveStep(10steps, fullspeed) I overshoot by 35 steps. So trying to account for the overshoot does not work… moveStep calls a private version which reduces the 10steps with the calculated overshoot. But in some cases that yields 10steps - 35steps. Simply not possible.

Offcourse that function could also take into account that for few steps the speed could be reduced.

Think I will have look into PID Library. For Servo functionality i.e going back and forth to hold a given position would I run a single PID controller using -255 to 255 as the output? Undestand that might be abit out of scope for the pololu support on the motor and dc driver :slight_smile:

It sounds like you are trying to replicate the functionality of a stepper motor using a DC motor and encoder. Is there some reason you are not using a stepper motor?

In general, tuning a system like this can be pretty complex and is a bit beyond what I can really help with. If you are overshooting your target position by several times the amount of desired change, it sounds like you might be sending too much power to the motors and trying to move too fast. As you might have read, PD scales its output based on position error and the speed with which that error is changing and is generally a good place to start. You will want the output of the PD or PID scaled to the range of motor input, so -255 to 255 could work, so long as you transform that into a direction and a PWM duty cycle for the motor controller.