Pololu Robotics & Electronics
Menu
My account Comments or questions? About Pololu Contact Ordering information Distributors

Pololu Forum

Dual MC33926 Motor Driver Carrier issues

Hi,

Please excuse my lack of electronics knowledge.

I’ve wired up my MC33926 motor controller to a Pi Zero W, The linked library from the product page I purchased it was actually for the RPI HAT version however the only difference seems to be two logic pins to control reverse or forward operation instead of 1 toggle pin.

I wrote up some software to control the MC33926 as per the logic truth table in the official doc.

I’m not a pro at soldering so checked all the RPI pin connections to the breadboard are indeed high or low based on my wiringpi commands in the Python interactive interpreter I can also see some voltage blipping on the PWM pin when it should be sending voltage.

The displayed pin status using the wiring pi CLI tool gpio readall indicates the RPI thinks its pins are doing as my python app is telling it to.

I must admit I’ve had to resolder a few pins as when pushing the MC33926 into the bread board they popped out. However I did this on the Pi Zero’s pins also and every time I’ve tested the ones in use they show voltage on logic 1 and - or none on logic 0 as expected, same as PWM. Although without further options I think ditching the breadboard and re-re-soldering /re-assembling a lot gentler will be the option.

the SF pin is on HIGH during the app running, Which if its connected properly is meant to indicate no fault.

I wrote a little one liner to monitor changes to the pins every second and it shows that the logic is being set matching the truth table;

slew pin: high
enable pin: high
IN1, IN2: high/low respectively
PWM/D2: high/low depending on when reading pin.

It then appears to show how PWM would look with my 1 second sleep on the CLI tool, With voltage showing 0 then 1

Does anyone have any tips, Maybe how I might use a multi-meter to tell if I melted the motor controller when I was soldering like a noob?

In case your interested this is the two liner its not perfect.:

alias rall="gpio -g readall | grep -P '{|5|6|26|28|27|23|25|24|Physical|}'"
touch current.txt; while true; do rall > new.txt; diff current.txt new.txt; mv new.txt current.txt;sleep 1;  done

Part of the output as the Python code runs.

>  | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
>  |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
>  |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5v      |     |     |
>  |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |
>  |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 0 | IN   | TxD     | 15  | 14  |
>  |     |     |      0v |      |   |  9 || 10 | 1 | IN   | RxD     | 16  | 15  |
>  |  27 |   2 | GPIO. 2 |  OUT | 1 | 13 || 14 |   |      | 0v      |     |     |
>  |  22 |   3 | GPIO. 3 |  OUT | 1 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
>  |     |     |    3.3v |      |   | 17 || 18 | 1 | OUT  | GPIO. 5 | 5   | 24  |
>  |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 0 | OUT  | GPIO. 6 | 6   | 25  |
>  |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
>  |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
>  |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
>  |   5 |  21 | GPIO.21 |  OUT | 0 | 29 || 30 |   |      | 0v      |     |     |
>  |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 0 | ALT0 | GPIO.26 | 26  | 12  |
>  |  13 |  23 | GPIO.23 | ALT0 | 0 | 33 || 34 |   |      | 0v      |     |     |
>  |  19 |  24 | GPIO.24 |  OUT | 0 | 35 || 36 | 0 | OUT  | GPIO.27 | 27  | 16  |
>  |  26 |  25 | GPIO.25 |  OUT | 1 | 37 || 38 | 1 | OUT  | GPIO.28 | 28  | 20  |
>  | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
14,15c14,15
<  |   5 |  21 | GPIO.21 |  OUT | 0 | 29 || 30 |   |      | 0v      |     |     |
<  |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 0 | ALT0 | GPIO.26 | 26  | 12  |
---
>  |   5 |  21 | GPIO.21 |  OUT | 1 | 29 || 30 |   |      | 0v      |     |     |
>  |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 1 | ALT0 | GPIO.26 | 26  | 12  |
17,18c17,18
<  |  19 |  24 | GPIO.24 |  OUT | 0 | 35 || 36 | 0 | OUT  | GPIO.27 | 27  | 16  |
<  |  26 |  25 | GPIO.25 |  OUT | 1 | 37 || 38 | 1 | OUT  | GPIO.28 | 28  | 20  |
---
>  |  19 |  24 | GPIO.24 |  OUT | 1 | 35 || 36 | 0 | OUT  | GPIO.27 | 27  | 16  |
>  |  26 |  25 | GPIO.25 |  OUT | 0 | 37 || 38 | 1 | OUT  | GPIO.28 | 28  | 20  |
15c15
<  |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 1 | ALT0 | GPIO.26 | 26  | 12  |
---
>  |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 0 | ALT0 | GPIO.26 | 26  | 12  |
17,18c17,18
<  |  19 |  24 | GPIO.24 |  OUT | 1 | 35 || 36 | 0 | OUT  | GPIO.27 | 27  | 16  |
<  |  26 |  25 | GPIO.25 |  OUT | 0 | 37 || 38 | 1 | OUT  | GPIO.28 | 28  | 20  |
---
>  |  19 |  24 | GPIO.24 |  OUT | 1 | 35 || 36 | 1 | OUT  | GPIO.27 | 27  | 16  |
>  |  26 |  25 | GPIO.25 |  OUT | 0 | 37 || 38 | 0 | OUT  | GPIO.28 | 28  | 20  |
16c16
<  |  13 |  23 | GPIO.23 | ALT0 | 0 | 33 || 34 |   |      | 0v      |     |     |
---
>  |  13 |  23 | GPIO.23 | ALT0 | 1 | 33 || 34 |   |      | 0v      |     |     |
16c16
<  |  13 |  23 | GPIO.23 | ALT0 | 1 | 33 || 34 |   |      | 0v      |     |     |
---
>  |  13 |  23 | GPIO.23 | ALT0 | 0 | 33 || 34 |   |      | 0v      |     |     |
16c16
<  |  13 |  23 | GPIO.23 | ALT0 | 0 | 33 || 34 |   |      | 0v      |     |     |
---
>  |  13 |  23 | GPIO.23 | ALT0 | 1 | 33 || 34 |   |      | 0v      |     |     |
16c16
<  |  13 |  23 | GPIO.23 | ALT0 | 1 | 33 || 34 |   |      | 0v      |     |     |
---
>  |  13 |  23 | GPIO.23 | ALT0 | 0 | 33 || 34 |   |      | 0v      |     |     |
14c14
<  |   5 |  21 | GPIO.21 |  OUT | 1 | 29 || 30 |   |      | 0v      |     |     |
---
>  |   5 |  21 | GPIO.21 |  OUT | 0 | 29 || 30 |   |      | 0v      |     |     |
14c14
<  |   5 |  21 | GPIO.21 |  OUT | 0 | 29 || 30 |   |      | 0v      |     |     |
---
>  |   5 |  21 | GPIO.21 |  OUT | 1 | 29 || 30 |   |      | 0v      |     |     |

Here is the associated python code:

import wiringpi
from time import sleep


class Motor:
    def __init__(self,
                 pwm_pin: int,
                 forward_pin: int,
                 reverse_pin,
                 en_pin: int = 5,
                 slew_pin: int = 22,
                 sf_pin: int = 10
                 ):
        self.pwm_pin = pwm_pin
        self.forward_pin = forward_pin
        self.reverse_pin = reverse_pin
        self.en_pin = en_pin
        self.slew_pin = slew_pin
        self.sf_pin = sf_pin
        self.max_speed = 480
        wiringpi.wiringPiSetupGpio()
        wiringpi.pwmSetMode(wiringpi.GPIO.PWM_MODE_MS)
        wiringpi.pwmSetRange(self.max_speed)
        wiringpi.pwmSetClock(2)
        wiringpi.pinMode(self.pwm_pin, wiringpi.GPIO.PWM_OUTPUT)
        wiringpi.pinMode(self.forward_pin, wiringpi.GPIO.OUTPUT)
        wiringpi.pinMode(self.reverse_pin, wiringpi.GPIO.OUTPUT)
        wiringpi.pinMode(self.en_pin, wiringpi.GPIO.OUTPUT)
        wiringpi.pinMode(self.slew_pin, wiringpi.GPIO.OUTPUT)
        wiringpi.pinMode(self.sf_pin, wiringpi.GPIO.INPUT)

    def enable(self):
        wiringpi.digitalWrite(self.en_pin, 1)

    def disable(self):
        wiringpi.digitalWrite(self.en_pin, 0)

    def move(self, direction: int, speed: int = 200):
        if speed > self.max_speed:
            speed = self.max_speed
        if direction is 1:
            print('Attempting to move forward')
            self.enable()
            wiringpi.digitalWrite(self.slew_pin, 1)
            wiringpi.digitalWrite(self.reverse_pin, 0)
            wiringpi.digitalWrite(self.forward_pin, 1)
            print(f'Sending PWM to pin {self.pwm_pin}')
            wiringpi.pwmWrite(self.pwm_pin, speed)
            sleep(10)
            self.disable()
            print(f'Switching off PWM to pin {self.pwm_pin}')
            wiringpi.pwmWrite(self.pwm_pin, 0)
        elif direction is 0:
            print('Attempting to move reverse')
            self.enable()
            wiringpi.digitalWrite(self.slew_pin, 1)
            wiringpi.digitalWrite(self.forward_pin, 0)
            wiringpi.digitalWrite(self.reverse_pin, 1)
            print(f'Sending PWM to pin {self.pwm_pin}')
            wiringpi.pwmWrite(self.pwm_pin, speed)
            sleep(10)
            self.disable()
            print(f'Switching off PWM to pin {self.pwm_pin}')
            wiringpi.pwmWrite(self.pwm_pin, 0)


motor0 = Motor(12, 19, 26)
motor1 = Motor(13, 16, 20)

motor0.move(1)
motor1.move(1)
sleep(5)
motor0.move(0)
motor1.move(0)
print('Finished')

Hello.

Do your motors move with your script? Can you provide more details on what exactly is the issue you’re having? Can you post pictures clearly showing how everything is connecting in your setup or a wiring diagram? Also, can you post close-up pictures of your solder joints on the Dual MC33926 Motor Driver Carrier board?

Did you check for continuity using your multimeter between the Dual MC33926 Motor Driver Carrier board and the Raspberry Pi Zero? If not, can you please do so? If you’re not familiar with checking for continuity using a multimeter, you can find lots of tutorials online (like this one). When doing the continuity test, touch one of the multimeter’s probes to the soldering joint on the top-side of the motor driver board and the other probe to the connecting pin on the bottom-side of Raspberry Pi Zero.

- Amanda

Hi Amanda,

Thank you for taking the time to respond.

My answers to these questions are after I twice re-soldered the motor driver and pi zero (after reading this is usually the problem) first using awful (“non corrosive”) hardware store flux which caused some corrosion and then with a proper rosin flux from Jaycar, I then cleaned the boards meticulously with %99.99 isopropyl and a soft brush although it appears the first flux caused some corrosion you may see, Its on a resistor? Of the m1 outputs next to the capacitors. I’ve debugged everything using both the m1 and m2 outputs to rule that out. The pi zero had the same treatment but is 100% operational with no hardware errors reported to Kernel.

As it turns out, Wiringpi has a bug where setting the pin numbers as per the doc does not work at all. I have switched to RPi.GPIO

Do your motors move with your script?

No, I have a second multi-meter clipped to the motor controller output to rule the motors out.

Can you provide more details on what exactly is the issue you’re having?

Currently, I have confirmed every motor controller pin is receiving 0 when it should and 3.3v when it should matching my code. Or at least the solder blobs on the back of the motor controller are. So up to that point the logic in my code and the voltage on the pins being transferred to the controller are correct.

I then swapped to the motor 2 pins (obv leaving enable and slew the same) to rule that out. Same no voltage to motor outputs. The voltage input from the battery pack is just over 5v detected on solder blobs on motor controller board.

I used a newer multi-meter which PWM detection on the PWM pin/solder blob on the motor controller It detected the frequency matching the specified GPIO PWM configuration of 10,000 and 20,000 hz when set in the code. I am using a 50% duty cycle.

I’ve tried both D1 and D2 for PWM on both motor output pin configurations.

Can you post pictures clearly showing how everything is connecting in your setup or a wiring diagram? Also, can you post close-up pictures of your solder joints on the Dual MC33926 Motor Driver Carrier board?



Sure, Colour coding is as follows;
Grey: IN1
Brown: IN2
Yellow: PWM
White: SF
Purple: SLEW
Orange: EN
Red: VIN
Black: GROUND

Did you check for continuity using your multimeter between the Dual MC33926 Motor Driver Carrier board and the Raspberry Pi Zero? If not, can you please do so? If you’re not familiar with checking for continuity using a multimeter, you can find lots of tutorials online (like this one). When doing the continuity test, touch one of the multimeter’s probes to the soldering joint on the top-side of the motor driver board and the other probe to the connecting pin on the bottom-side of Raspberry Pi Zero.

I think testing the 3.3v and 0v on the solder blobs on motor board matching logic in the code inclusively tests continuity so I have not done this seperately. When the pins/blobs were set 3.3v/0v they stayed stable.

from RPi import GPIO
from time import sleep


class Motor:
    def __init__(self,
                 pwm_pin: int,
                 forward_pin: int,
                 reverse_pin: int,
                 sf_pin: int,
                 en_pin: int = 17,
                 slew_pin: int = 27,
                 ):
        GPIO.setwarnings(False)
        GPIO.cleanup()
        self.pwm_pin = pwm_pin
        self.forward_pin = forward_pin
        self.reverse_pin = reverse_pin
        self.en_pin = en_pin
        self.slew_pin = slew_pin
        self.sf_pin = sf_pin
        self.max_speed = 480
        GPIO.setmode(GPIO.BCM)
        GPIO.setup(self.pwm_pin, GPIO.OUT)
        self.motor_pwm = GPIO.PWM(self.pwm_pin, 10000)
        GPIO.setup(self.forward_pin, GPIO.OUT)
        GPIO.setup(self.reverse_pin, GPIO.OUT)
        GPIO.setup(self.en_pin, GPIO.OUT)
        GPIO.setup(self.slew_pin, GPIO.OUT)
        GPIO.setup(self.sf_pin, GPIO.IN)

    def enable(self):
        GPIO.output(self.en_pin, GPIO.HIGH)
        GPIO.output(self.slew_pin, GPIO.HIGH)

    def disable(self):
        GPIO.output(self.en_pin, GPIO.LOW)
        GPIO.output(self.slew_pin, GPIO.LOW)

    def move(self, direction: int, speed: int = 200):
        if speed > self.max_speed:
            speed = self.max_speed
        if direction is 1:
            print('Attempting to move forward')
            self.enable()
            GPIO.output(self.reverse_pin, GPIO.LOW)
            GPIO.output(self.forward_pin, GPIO.HIGH)
            print(f'Sending PWM to pin {self.pwm_pin}')
            self.motor_pwm.start(50)
            sleep(10)
            self.motor_pwm.stop()
            self.disable()
            print(f'Switching off PWM to pin {self.pwm_pin}')
            print(f'State Flag: {GPIO.input(self.sf_pin)}')
        elif direction is 0:
            print('Attempting to move reverse')
            self.enable()
            GPIO.output(self.forward_pin, GPIO.LOW)
            GPIO.output(self.reverse_pin, GPIO.HIGH)
            print(f'Sending PWM to pin {self.pwm_pin}')
            self.motor_pwm.start(50)
            sleep(10)
            self.motor_pwm.stop()
            self.disable()
            print(f'Switching off PWM to pin {self.pwm_pin}')
            print(f'State Flag: {GPIO.input(self.sf_pin)}')


motor0 = Motor(12, 16, 20, 26)


motor0.move(1)
# motor1.move(1)
sleep(5)
motor0.move(0)
# motor1.move(0)

print('Finished')



Looks like M2D2 is not connected in your setup. If you do not already know, both of the disable pins (D1 and D2) are active by default. Since you are using M2D1 for the PWM input, you would need to pull M2D2 high (which is active low), to prevent it from disabling the motor driver. You can find that information under the “Pinout” heading on the Dual MC33926 Motor Driver Carrier’s product page. The board provides convenient jumper points for overriding the driver’s defaults without having to make more external connections, but the default-overriding jumpers are tied to VDD, which is also not connected in your current setup. I think an easier solution is to use M2D2 for the PWM input and then jumper M2D1 to the adjacent GND pin. M2D2 is treated as a non-inverted PWM input, which is probably what you want. You can also find the default-overriding jumpers marked in the picture under the “Pinout” section on the product page.

- Amanda

2 Likes

Hi Amanda,

As mentioned I’ve actually tried both D1 and D2 for every test just in case I misunderstood something. The photo was after my final test. I understood the truth table required D2 so I used it, And when that failed tried D1 on the chance I was confused.

I’m trying it again with m2d2 but this time also connecting the other motor to try to observe any different behavior. Ill report back.

Second motor now inputs now connected to GPIO

The same behavior, No movement on the motors. As far as I know from reading through the manual the SF HIGH indicates no error detected by the chipset? Or is it high even if its broken.

PWM: 13,
IN1: 5
IN2: 6
SF: 11

root@raspberrypi:~# python3 motor.py 
Attempting to move forward
Sending PWM to pin 12
Switching off PWM to pin 12
State Flag: 1
Attempting to move forward
Sending PWM to pin 13
Switching off PWM to pin 13
State Flag: 1
Attempting to move reverse
Sending PWM to pin 12
Switching off PWM to pin 12
State Flag: 1
Attempting to move reverse
Sending PWM to pin 13
Switching off PWM to pin 13
State Flag: 1
Finished

You need to use both MxD1 and MxD2 at the same time; you need to pull D1 low to enable the driver while supplying D2 with your PWM signal. By default, MxD1 is pulled high when left disconnected, disabling the driver.

- Amanda

Apologies I only just had time to look at this again now and your advice resolved the issue entirely.

Thank you very much. I’ve since soldered the ground jumper to D1 for m1 and m2 to reduce the wire count as well.

1 Like