security, I didn't apply power to the motor controller's
+ 12 VDC power input. Things seemed to go well without
the BLDC motor and its power source. I tested with this
configuration without incident.
After coding what I thought was enough to try to spin
the BLDC motor shaft, the time had come to apply power to
the three phase driver. My goal was to simply nudge the motor
shaft by forcing it to assume the final (sixth) position in a BLDC
motor electrical cycle. Recall from our previous discussion
that the PWM outputs are selected using the PIC18F2431's
OVDCOND and OVDCONS registers as follows:
PDC0H = 0x01;
PDC0L = 0xFF;
PDC1H = 0x01;
PDC1L = 0xFF;
PDC2H = 0x01;
PDC2L = 0xFF;
OVDCOND = 0b00100000;
OVDCONS = 0b00000000;
//PWM0 and PWM1
//PWM2 and PWM3
//PWM4 and PWM5
//PMW5 active only
Upon applying + 12 VDC BLDC motor power along with
the + 5 VDC logic power, I noticed that the + 12 VDC power
indicator LED dimmed and started to pulsate. After quickly
powering everything down, I noticed that the TC4428s
were very warm. I simply noted this as "odd" and moved
on. I again applied full power and observed the pulsating
LEDs which seemed to be in rhythm with a jerking of the
BLDC motor shaft. After whiffing the aroma of "magic
smoke,” I decided to "finger test" the warm parts. The
TC4428s were hot enough to put a blister on my now-temperature-calibrated thumb. Something was wrong in a
bad way. I figured I was somehow pushing too much
current through the motor coils. Following some deep
meditation, I came to the conclusion that the pulsating
I was seeing was the wall wart switching power supply
attempting to save itself from an overcurrent condition by
discontinuing power to the load. As I'm trying to keep the
nasty thought of "bad design" out of my mind, I'm burning
up TC4428s at a fanatical rate. It came down to the fact
that simply applying full power to the motor controller
smoked the TC4428s. My feelings, my pride, and my thumb
were hurt. For the next few days, I was clueless as to what
was going on in a bad way with this project. Everything
that had to do with polarity of power supply voltages and
PWM signals looked fine on my CleverScope display and the
NDS9952A MOSFETs were never getting warm. How could
I be frying the TC4428s and not the MOSFET pairs?
More meditation led me to the conclusion that since
I was only releasing the "magic smoke" when + 12 VDC
was present, I was somehow overloading the TC4428's
push-pull outputs. To kill the outputs meant that I had to
be punching clean through the gates of the MOSFET pairs
causing them to present a short to the TC4428 outputs.
I whispered to myself, "No way."
Once again, I got down off of my donkey. The problem
had to lie in the way I was driving the TC4428 inputs with
the firmware. After a couple of days of intense datasheet
scrutiny, I found that the problem was embedded in this
set of firmware commutation patterns:
//* COMMUTATION PATTERNS
//* PHASES: USED OPEN
//*#define pos0 0b00111001 ;PWM1-PWM2 A-B (C)
//*#define pos1 0b00101101 ;PWM1-PWM4 A-C (B)
//*#define pos2 0b00100111 ;PMW3-PWM4 B-C (A)
//*#define pos3 0b00110110 ;PMW3-PWM0 B-A (C)
//*#define pos4 0b00011110 ;PWM5-PWM0 C-A (B)
//*#define pos5 0b00011011 ;PWM5-PWM2 C-B (A)
Do you see the problem? If you don't see the problem,
don't feel bad. It took me two days to discover the source
of my hardware pain. If you're still under the spell that was
cast upon me, look back at the OVDCOND/OVDCONS code
snippet I pulled from last month's discussion. Each and
every commutation pattern has not one, not two, but four
MOSFETs activated. I was lucky not to set fire to the bench!
Here's the commutation pattern set that removed the spell
and led me out of the magic-smoke-filled forest:
//* NEW COMMUTATION PATTERNS
//* PHASES: USED OPEN
//*#define pos0 0b00000110 ;PWM1-PWM2 A-B (C)
//*#define pos1 0b00010010 ;PWM1-PWM4 A-C (B)
//*#define pos2 0b00011000 ;PMW3-PWM4 B-C (A)
etc.
That's more like it! Now, only two PWMs are activated
per commutation position. One of the PWM signals is
always a + 12 VDC enabler and the other PWM is always
pulsing the ground return MOSFET. I am happy to report
that the + 12 VDC indicator LED no longer dances to the
beat of an overloaded wall wart and the TC4428s are no
longer burning holes in my thumb.
The Big Picture
The updated motor controller hardware is saying
"cheese" in Photo 1. During the firmware test period, I
discovered that the VM voltage output needed its own
dedicated analog-to-digital (A-to-D) input. So, I moved the
MOTOR_I voltage output point to the jumper block point
that was occupied by the VM voltage output. For the
purposes of a fault condition, there's no reason to keep up
with the motor current as the current op-amp/comparator
monitor circuit can be used to detect and report an
overcurrent condition to the PIC18F2431. The output of the
MCP6542 comparator feeds the PIC’s active-low FLTA pin.
When an overcurrent condition is sensed by the MCP6542,
its output falls to a logical low level, which kicks in the PIC's
automatic fault handler. Upon seeing a logical low at the
FLTA pin, the hardware PWM outputs are driven to an
inactive state until the fault condition is removed. With
some simple register programming, we can choose to
remain in a fault mode until the firmware clears the fault
indicators or exits fault mode automatically when the
overcurrent condition is removed. If you wish to monitor
the current with the A-to-D module, you'll be pleased to
find that the voltage in millivolts presented at the MOTOR_I
node is identical in value to the current being drawn. For
instance, if you read 37 mV at the MOTOR_I node, you're
pulling 37 mA of current through the three phase driver
SERVO 02.2009
47