AN75813 H Bridge Based Motor Drive Protection Using PSoC 3.pdf

THIS SPEC IS OBSOLETE
Spec No: 001-75813
Spec Title: H BRIDGE BASED MOTOR DRIVE
PROTECTION USING PSOC(R)3 - AN75813
Sunset Owner: K Sanjeev Kumar (KUK)
Replaced by: None
AN75813
H Bridge Based Motor Drive Protection Using PSoC® 3
Author: Sudip Mondal
Associated Project: Yes
Associated Part Family: CY8C38xx
Software Version: PSoC ® Creator TM 2.0
Related Application Notes:
“For a complete list of the application notes, click here. ”
If you have a question, or need help with this application note, contact the author at
[email protected] .
Contents
Ob
so
let
e
AN75813 demonstrates the use of a PSoC 3 for brushed DC motor drive protection and diagnostics. The PSoC 3
protection system is optimized for the widely used H bridge, but it can easily be adapted to other DC motors. The
implementation emphasizes the use of digital logic present on the PSoC 3 to free the CPU for more involved tasks such
as motor control. This application note specifically addresses motor drive protection and diagnostics and does not
discuss motor control.
Introduction ....................................................................... 2
Smart Drivers and their limitations..................................... 2
Alternate Methods to Drive H Bridges ............................... 2
Capacitive Pump .......................................................... 3
Boost Converter ........................................................... 3
Common Faults in H Bridge Based Motor Drives .............. 4
Operation of H Bridge Based Motor Drives Outside the
Safe Operating Area.......................................................... 5
Finite Set of Valid Bridge Operations ................................ 6
High Level Architecture of Fault Detection and Protection
System .............................................................................. 9
Implementation of the Fault Detection and Protection
System ............................................................................ 11
The Half Bridge Interface Block .................................. 11
Over Current, Fault Detect and Diagnostic Blocks ..... 12
Blanking Timer ........................................................... 13
Over Current Block ..................................................... 14
Fault Detect Block ...................................................... 16
Diagnostic Block ......................................................... 18
Motor Drive Signals Block .......................................... 22
Firmware Block ........................................................... 24
User Interface .................................................................. 28
SPI Communication .................................................... 28
LCD Interface ............................................................. 33
LED Interface ............................................................. 33
www.cypress.com
Demonstration with CY8CKIT-001 PSoC Kit with PSoC 3
Processor Module, and Motor Control Board .................. 34
Demonstration Setup.................................................. 34
Demonstration of Operation ....................................... 35
Summary ......................................................................... 40
Related Application Notes ............................................... 40
Appendix ......................................................................... 41
Setup Details for CY8CKIT-030 ................................. 41
Motor Control Board ................................................... 42
Document No. 001-75813 Rev. *A
1
®
H Bridge Based Motor Drive Protection Using PSoC 3
Introduction
effectiveness for infrequently driven motors such as an
HVAC flap controller motor or a seat positioning motor.
DC motors are widely used in many automotive
applications such as HVAC, power seats, wipers, and
power windows. It is important to protect the motor drive
system, because failure to do so may result in damaged
components and, in some cases, hazardous conditions.
Motor drive systems consist of switching elements and
drivers. The switching elements (e.g. FETs, relays, IGBTs)
are typically arranged in the form of an H bridge. The
drivers turn the switching elements on and off according to
the commands from the controller. Drivers are required,
because microcontrollers typically cannot handle the
voltage and current levels required to operate the
switches. Fault detection, the protection mechanism, or
both are often built into the switches or the drivers to
signal an abnormal state such as over current or over
voltage to the controlling microprocessor. These “smart”
switches and drivers use different methods to report faults
ranging from simple digital pins to inter-device
2
communication channels such as SPI or I C. When they
detect a fault, they either disable the motor drive or leave
that task to the controlling microprocessor.
The PSoC 3 is an excellent solution in these cases.
Configurable precise analog and digital blocks inside the
device handle all fault detection and protection. This
removes the necessity to use expensive smart drivers and
switches. The system described in this application note is
capable of:
Easy and dynamic configuration of the definition of
fault parameters such as over current threshold,
blanking time and so on without the use of additional
components

Flexible fault reporting ranging from the presence of a
fault to a detailed status of the motor driving bridge

Continuous monitoring of inactive motors to reduce
the risk of failures and hazards
e

Ob
so
let
Because the PSoC 3 cannot handle the voltage and
current levels required for a high-side gate drive, we need
alternative methods to do so. In the next section, we
demonstrate two ways to implement level translation for a
high-side gate drive without the use of specialized drivers.
In this application note, we discuss an alternate approach
to fault detection and protection. Instead of using prepackaged motor drivers with built-in protection systems,
we use basic components such as FETs and gate drivers.
This method results in a larger number of available test
signals and hence better determination of fault conditions.
Combined with the configurability of PSoC 3 devices, this
method also leads to a scalable and programmable
system that can be easily shared across multiple bridges.
This eliminates the need to build a fault detection system
for each newly added motor. We briefly describe the
limitations of smart drivers and alternate methods to drive
gates. Then we discuss faults and ways to use the
PSoC 3 as a fault detection and protection system.
Smart Drivers and their limitations
Drivers are necessary to interface a microcontroller with a
switching device as most microcontrollers cannot handle
the voltage and current levels required to control switches.
Drivers with built-in, smart protection mechanisms are
generally more expensive than their less smart
counterparts. Smart drivers are attractive for two reasons:

They provide the level translation required for highside gate driving.

It is not easy to find microcontrollers with sufficient
programmable analog and digital capabilities to
implement a central fault detection and protection
system.
However, smart drivers have limited configurability and a
fixed set of fault detection abilities. The system designer
has limited control over the functional definition of a fault
and may have to resort to different devices for different
motors. Moreover, many of the drivers can only report a
fault when the motor is running. This reduces their
www.cypress.com
Alternate Methods to Drive H Bridges
It is difficult to drive the gates of high-side N-type FETs,
because the gate voltage must be higher than the
available battery voltage. Figure 1 illustrates the problem.
When the highlighted switch is turned on, its source
voltage VS is close to the battery voltage VBAT. Therefore,
its gate voltage must sufficiently exceed the sum of the
source voltage and the gate-to-source threshold. The
FETs used in motor drives are designed to handle
substantial current (commonly two to four amps) and often
have large threshold voltages. Therefore, we need a
method to generate a voltage higher than the available
battery voltage. Two common methods to generate the
higher voltage are:

Use a capacitive charge pump to drive the gate
voltage to almost double the battery voltage

Use of a boost converter
Figure 1. Gate Voltage Requirement for High Side Switch
VBAT
VG > VBAT
M
VS ≈ VBAT
Document No. 001-75813 Rev. *A
2
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 2 illustrates capacitive pumping of the voltage with
an example application. It requires a PWM on the high
side FET HS 1 while the low side FET LS 2 is kept ON.
Low side FETs are relatively easier to drive and are not
discussed in this application note. The other two switches
remain inactive during the operation. We use an FET M1
with a small threshold voltage to enable direct operation
by microcontroller pins.
In Figure 2.a, the microcontroller pin is high (HIGH SIDE
CONTROL = 1). As the gate of M1 goes high, it is turned
ON which leads to current flow through the resistors R1
and R2. The resistors R1 and R2 are appropriately sized
so that the gate voltage (VG) is near 0, and the FET HS 1
is OFF. As a result, the source voltage of HS1 (VS) is
close to ground. The capacitor (C) is charged to a voltage
(VBAT) less one diode drop. The dashed line traces the
path of the current.
Figure 2. Capacitive Pump Based High-Side Gate Drive
Vbat
VC ≈ VBAT
D
R1
C
R2
Ob
HS 1
VG ≈ 0
HIGH SIDE
CONTROL = 1
M1
M
VS ≈ 0
Extra drivers can be added in front of the FETs to supply
the required gate current in cases where the size of the
main FETs and the desired turn ON/turn OFF time require
it. Because the capacitor (C) supplies the gate current, it
must be correctly sized.
Boost Converter
Figure 3 illustrates the use of a boost converter. A boost
converter accepts the battery voltage (VBAT) as its input
and produces an output voltage (VBOOST) higher than VBAT.
This voltage is then used to drive the high-side switch.
When HIGH SIDE CONTROL is high (1), the FET M1 is
ON. This condition pulls the gate of HS 1 to ground and
turns it off. When HIGH SIDE CONTROL is low, the
voltage VBOOST raises the gate of HS 1 and turns it ON.
so
le
When the microcontroller pin is low (HIGH SIDE
CONTROL = 0). M1 turns OFF. This makes the voltage VG
= VC ≈ VBAT (the gate current of FET HS 1 is negligible).
The gate to source voltage exceeds the threshold voltage
of the FET HS 1, and it starts to turn ON.
As HS 1 turns ON, its source voltage rises. Since the
voltage
across
the
capacitor
cannot
change
instantaneously, VC also increases. In turn, VG increases
since the capacitor supplies the gate of HS 1. The Diode
(D) becomes reverse biased and no current flows through
it. This process continues until HS 1 is fully turned ON. At
this point, VC is almost equal to twice the battery voltage
(VBAT), as illustrated in Figure 2.b. The cycle repeats as
the controller pulls the HIGH SIDE CONTROL high again.
In this manner, switch HS 1 can be cycled ON and OFF.
te
Capacitive Pump
LS 2
LOW SIDE
CONTROL
Figure 2.a
The requirement to use additional components to monitor
and control the boost means that the boost converter
method is used infrequently. However, this method has
two advantages over the capacitive pump method:

The boost converter does not require replication for
each high side switch. This is an advantage in
applications which drive several motors such as an
HVAC.

The capacitive method can be used only when the
high side switch needs a PWM. The capacitor C must
be periodically charged so that it can supply the gate.
The configurable analog and digital peripherals in PSoC 3
allow us to build the boost control circuit inside the device.
This eliminates the need for external control components
Figure 3. Boost Converter Based High-Side Gate Drive
VBAT
VBOOST
BOOST
CONVERTER
VBAT
VC ≈ 2VBAT
D
R1
C
R
R2
HIGH SIDE
CONTROL = 0
HS 1
M1
VS ≈ VBAT
HS 1
HIGH SIDE
CONTROL=0/1
M
M1
M
LS 2
LS 2
LOW SIDE
CONTROL
LOW SIDE
CONTROL
Figure 2.b
www.cypress.com
Document No. 001-75813 Rev. *A
3
®
H Bridge Based Motor Drive Protection Using PSoC 3
Nevertheless, the fault detection and protection methods
are not limited to any particular implementation of high
side gate drive, and we demonstrate the functionality of
the system with both the capacitive pump and the boost
converter. We start with a discussion of the common faults
that occur on an H bridge based motor drive.
Common Faults in H Bridge Based
Motor Drives
H bridges are commonly used in motor drives as well as
many other applications. As such, the faults discussed in
this section are not limited to motor drives. The major
faults found with motor drives involve the switching
elements (e.g. MOSFETs, IGBTs, and so on). Each
switching element has its Safe Operating Area (SOA), and
faults lead to operations outside the SOA. Operations
outside the SOA reduce the life of the switches
significantly and may lead to hazardous conditions.
It should be noted that the SOA is specified for a particular
ambient temperature (25 ºC in the figure). For different
ambient temperatures, the allowable period of operations
become different (they decrease with increasing ambient
temperature). Therefore, it is useful to be able to change
the allowable ON-time with changing temperature. Most
smart drivers set this time using an external component
such as a resistor or a capacitor and therefore lack the
ability to change it according to temperature.
Different conditions may lead to excessive current through
the switches. One of the reasons may be excessive load
on the motor (a jammed motor for example). Motor
resistance limits the maximum amount of current from a
large load and is generally specified as the blocked rotor
current for a given voltage by the motor manufacturer.
Under certain circumstances, much larger currents may
flow. If a motor terminal is shorted to battery or ground and
a corresponding switch is turned on, hazardous shorts
may be created. Similar circumstances may arise due to a
shorted motor. Figure 5 shows a few examples, where the
highlighted switch is turned on for a pre-specified time as
part of normal operation (e.g. motor drive, active braking
and so on).
so
le
The SOA is estimated based on the junction temperature
of the switch. The junction temperature depends on the
ambient temperature, the power dissipation across the
switch, and the thermal resistance of the junction. Device
datasheets generally present a graphical representation of
the SOA and mandate that the operation be restricted to
the SOA. Figure 4 shows a typical example of the SOA for
a MOSFET switch, as presented in the datasheet.
current to a voltage signal. This voltage can then be
compared against a threshold for detection of over or
under current, or measured otherwise (e.g. using and
ADC). With the availability of continuously configurable
analog and digital hardware in PSoC 3, it becomes easy to
design a configurable current monitoring and limiting
system, which ensures that the switching elements
operate in their SOA.
te
and makes the boost converter method particularly easy to
implement.
Ob
The figure shows that the SOA is governed by the drain to
source voltage, the drain current and the duration of
operation. Generally, the voltage tolerances of the
switches are an order of magnitude higher than the
voltages applied in practice. Also, when the switch is
conducting, the voltage across the switch is close to zero.
The major parameter affecting the safe operation of the
switch is the current through the switch.
Current is generally measured using a low side or a high
side shunt resistor (sometimes both), which converts the
Figure 4. Example of the Safe Operating Area (SOA) of a
MOSFET Switch
200
100
10
I D DRAIN CURRENT (A)
0µ
s
N)
S
RD
LIM
Such conditions, if prolonged beyond safe limits, not only
lead to operations outside the SOA, but also to dangerous
conditions. It is necessary to detect and act upon such
conditions immediately; it is also advantageous to be able
to prevent such occurrences by periodically monitoring the
H bridges when the motor is not in operation.
An open load does not lead to operation outside the SOA
of the switches, as no current flows through the switches.
Therefore, this fault is less critical to the electrical safety of
the system. However, it leads to a functional fault (i.e. the
motor can no longer perform the task it is assigned) and
may be critical (e.g. in a wiper motor or door lock motor).
When we account for functional safety, this is also outside
the safe operating area in an extended sense. Therefore,
the load also must be monitored periodically to guarantee
IT
(O
10
10
Figure 5. Hazardous Short Conditions on an H Bridge
ms
VBAT
VBAT
VBAT
10
0m
s
1s
10
s
DC
Short
1
M
VGS = 10V
SINGLE PULSE
TA = 25ºC
M
M
Short
Short
0.1
1
10
100
300
VDS DRAIN TO SOURCE VOLTAGE (V)
www.cypress.com
Document No. 001-75813 Rev. *A
4
®
H Bridge Based Motor Drive Protection Using PSoC 3
In this application note, we consider the following faults:




Over Current
Shorts to Battery
Shorts to Ground
Load Open
Because a shorted motor can be treated as a
simultaneous short battery and ground, it is covered by
this fault list. In the next section, we discuss the effects of
the faults on electrical parameters of generic H bridge
based motor drives. These parameters indicate operation
outside SOA and are important for a fault detection and
protection system.
The fault detection system monitors the Motor Terminal
Left and Motor Terminal Right nodes. The state of the
bridge can be inferred from the voltages VA and VB.
Resistor dividers are generally used to reduce high
voltages close to VBAT (12 to 48 V) to a range that can be
read by the electronic control and protection system (for
example a microcontroller) which generally operates at a
lower voltage (3 to 5 V).
Under normal operating conditions (a spinning motor), VR
is limited to a finite range. The minimum current through
an unloaded motor sets the lower bound. The system
designer sets the upper bound as deemed safe for a
maximum allowable load. A measurement of VR less than
the lower bound indicates an open load (VR (LOAD OPEN)). A
measurement larger than the upper bound indicates over
current (VR (OVER CURRENT)).
let
Operation of H Bridge Based Motor
Drives Outside the Safe Operating
Area
of the bridge current. If one switch is suddenly turned
OFF, the current through the motor diverts through one of
the diodes across the switches until it drops to zero. This
may or may not be registered by the low side shunt since
the current may not be flowing through it, or it may reverse
its direction.
e
functionality.
Figure 6 illustrates a generic H bridge based motor drive.
The two main operation modes during which the motor
spins are:
The High Side Left and the Low Side Right switches
are ON; the other two switches are OFF.

The High Side Right and the Low Side Left switches
are ON; the other two switches are OFF.
so

Similarly, the signals VA and VB also have a normal
operating range. For example, with the High Side Left FET
turned ON, VA is pulled up close to VBAT. The minimum
value of VA is determined by the maximum drop across the
FET, which in turn is determined by the maximum
allowable current. The maximum value of VA is actually
VBAT (assuming zero drop across the FET). These two
voltages can be termed as VA (NO LOAD) and VA (FULL LOAD).
With the Low Side right FET turned ON, VB has a
maximum value of VB (FULL LOAD) and a minimum value of
VB (NO LOAD).
In most cases, one of the switches is not continuously ON.
It is pulse width modulated for better control of the amount
of current through the motor, and subsequently its speed.
Ob
The low side shunt is used to measure the instantaneous
current through the motor when one high side and one low
side switches are conducting. The voltage VR is indicative
Figure 6. Generic H Bridge Based Motor Drive with
Associated Electrical Parameters
VBAT
HIGH SIDE
LEFT
HIGH SIDE
RIGHT
MOTOR
TERMINAL
RIGHT
MOTOR
TERMINAL
LEFT
The definition of a faulty or hazardous condition is a state
where these signals are outside normal operating ranges.
Table 1 lists the various possibilities, with High Side left
switch turned ON (corresponding Low Side left switch
turned OFF) and Low Side right switch turned ON
(corresponding High Side right switch turned OFF).
The configuration shown in Table 1 can detect the
MOTOR TERMINAL LEFT shorted to ground and MOTOR
TERMINAL RIGHT shorted to VBAT faults. The
complimentary configuration (High Side Right ON and Low
Side Left ON) can detect MOTOR TERMINAL LEFT
shorted to VBAT and MOTOR TERMINAL RIGHT shorted
to ground.
M
VA
VB
LOW SIDE
RIGHT
LOW SIDE
LEFT
BRIDGE CURRENT
LOW SIDE
SHUNT
www.cypress.com
AMPLIFIER
AND FILTER
VR
Document No. 001-75813 Rev. *A
5
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 1. Monitor Signal States for Normal Operations and Fault Conditions
Case
1
High High Low Low
Side Side Side Side
Left Right Left Right
1
0
0
1
VA
VB
VA ≥ VA (FULL LOAD)
VR
VB ≤ VB (FULL LOAD)
VR (LOAD OPEN) ≤ VR ≤
Inference
VR (OVER CURRENT)
Normal Operation/ (VA shorted to
battery and VB shorted to ground
cannot be detected)
2
1
0
0
1
VA ≤ VA (FULL LOAD)
VB ≥ VB (FULL LOAD)
VR > VR (OVER CURRENT)
Over current condition
3
1
0
0
1
VA << VA (FULL LOAD)
VB ≤ VB (FULL LOAD)
X
VA possibly shorted to ground
4
1
0
0
1
VA ≥ VA (NO LOAD)
VB >> VB (FULL LOAD)
X
VB possibly shorted to battery
5
1
0
0
1
VA << VA (FULL LOAD)
VB >> VB (FULL LOAD)
VR > VR (OVER CURRENT)
The load is shorted
6
1
0
0
1
VA ≥ VA (NO LOAD)
VB ≤ VB (NO LOAD)
VR < VR (LOAD OPEN)
The load is open
monitor signals against a large number of thresholds.
Completing so many comparisons in a limited amount of
time requires a large number of comparators. To use an
Analog to Digital Converter, voltage comparisons and
corresponding corrective actions during faults must be
implemented in firmware. This may result in nondeterministic timing of operations due to uncertainties in
firmware execution, especially if it contains large number
of interrupts. A hardware solution is preferable.
Ob
so
let
Henceforth, for ease of reading, we often abbreviate the
names of the switches by the initials (High Side Left = HSL
and so on). A similar table can be prepared for
complimentary operation (HSL = 0, LSL =1, HSR =1 and
LSR = 0).
e
Similar conclusions can be drawn about the configuration High Side Left=0, High Side Right=1, Low Side Left=1 and Low Side Right=0
Over Current Condition: If the voltages VA and VB are
within normal operating range, then excess VR can be due
to over current conditions due to load malfunction, switch
malfunction, or excessive load. Case 2 in Table
1illustrates an example.
MOTOR TERMINAL LEFT Shorted to Ground: In this
case, the voltage at VA is much lower than its lower limit of
normal operation; in fact it is very close to ground. Thus, if
HSL is ON and VA is much lower than the threshold, then
VA can be assumed to be shorted to ground. Case 3 in
Table 1 illustrates an example.
MOTOR TERMINAL RIGHT Shorted to Battery: In this
case, the voltage at VB is not close to zero, in spite of LSR
being turned on. This indicates a short to battery. In such
cases, heavy current flows through the sense resistor, a
condition which provides additional identification. Case 4
in Table 1 illustrates an example.
Load is Shorted: A shorted load has its two terminals
connected through a wire or a very low resistance. Both
VA and VB are close to the mid-range voltage, and heavy
current flows through the sense resistor showing large VR.
Case 5 in Table 1 illustrates an example
Load is Open: In this case, the voltages VA, VB and VR
are all outside normal operating ranges. Case 6 in Table 1
illustrates example.
The battery voltage may drop due to excessive current
during a short condition. Because voltages VA and VB are
proportional to the battery voltage, their values might be
inappropriately measured in these cases. The car battery
is essentially a rather large capacitor, and therefore
changes in battery voltage are slow. Therefore, if the fault
detection is quick enough, we can avoid incorrect reading
of the voltages. Table 1 demonstrates that the
identification of the faults requires comparison of the three
www.cypress.com
The first corrective action for all of these fault conditions is
to deactivate the bridge and to suspend the current
operation; this simplifies the problem. It is often sufficient
to detect the existence of a fault and to deactivate the
bridge, without immediate identification of the exact fault.
This action requires a reduced set of observations to
detect the presence of a fault and preferably consumes
fewer resources than more comprehensive fault detection
methods. In the next section, we describe a method to
achieve that.
Finite Set of Valid Bridge Operations
The key to quickly determine the presence of a fault is to
reduce the number of possible comparisons without
sacrificing the detectability of any critical fault. To do this,
we group the faults into two sets:

Faults that affect the H bridge elements, lead to
hazardous condition, and so require immediate action
including: shorts to battery, shorts to ground and over
current condition.

Faults that affect functionality but do not lead to
hazardous condition on the H-bridge, and so do not
require immediate action such as the open load fault.
The modified detection requirements allow us to reduce
the necessary comparisons to three. With a single
threshold each for VA, VB, and VR, we have the simple,
three-comparator implementation shown in Figure 7. The
typical allowable ranges of VA and VB for the condition are
in Table 1.
Document No. 001-75813 Rev. *A
6
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 2. Allowable States of the Digital Signals Based on
the Direction of Motion
+
Threshold VA
MTL
_
VA
Threshold VA, VB
ALLOWED
RANGE
VA
FULL RANGE
Figure 7. Three Comparator Fault Condition Detection
VB
VB
+
Threshold VB
MTR
_
VR
Threshold VR
+
OC
_
Direction 1
Direction 2
HSL
1
0
HSR
0
1
LSL
0
1
LSR
1
0
MTL
1
0
MTR
0
1
OC
0
0
Table 3. Diagnostic Sequence
so
let
e
The MTL, MTR and OC are digital signals representative
of the voltages at nodes MOTOR TERMINAL LEFT,
MOTOR TERMINAL RIGHT and excessive current
through the bridge respectively. Table 4 depicts their
interpretations. In the presence of a fault, the deviation of
the voltages VA and VB from their allowable ranges is
large; this allows us to use only a single threshold for both
the voltages. A current threshold should be chosen based
on the motor and the allowable load. PSoC enables us to
configure the thresholds dynamically and cater to different
situations. For example, we can modify the current
threshold during motor start to prevent false over current
detection due to high inrush current.
Signal
The motor can either be driven or stationary, as required
by the application. Depending on the direction of rotation
of the motor, only certain combinations of these three
signals are allowable as shown in Table 2. The table
shows only the ON state of the switches (i.e. the OFF
periods in a PWM application are ignored).
Ob
Table 1 illustrates that certain faults are undetectable for
each direction of rotation. Also, it is not possible to infer
the existence of a load open fault from the digital signals
when the motor is running. To circumvent this difficulty, we
use a special Diagnostic Sequence (Table 3) to monitor
the H bridge periodically when the motor is stationary.
The Diagnostic sequence has the following characteristics:

A high side switch and a low side switch are not
simultaneously ON at any point of the sequence.

The sequence can successfully detect and identify the
presence of one fault. If the bridge suffers from
multiple faults then the sequence may not correctly
identify any single fault. However, it still detects at
least one fault.
The Diagnostic Sequence can both detect and identify a
fault. As a high side and a low side switch are never ON at
the same time, there should be no current through the
motor. This enables us to run this sequence whenever
required without driving the motor.
Although not explicitly shown in the table, there is a state
with all switches OFF inserted between two consecutive
www.cypress.com
HSL
HSR
LSL
LSR
Target Fault
Expected state of
MTL and MTR
0
0
0
0
Short to VBAT
MTL=0 MTR=0
1
0
0
0
Short to GND
MTL=1 MTR=X
0
0
1
1
Neutralize bridge
MTL=X MTR=X
0
1
0
0
Short to GND
MTL=X MTR =1
0
0
1
1
Neutralize bridge
MTL=X MTR=X
1
0
0
0
Load open
MTL=1 MTR=1
Table 4. Interpretation of Digital Signals
Digital
Signal
Set
Indicates
MTL
1
MOTOR TERMINAL LEFT closer to the battery
voltage than to ground
MTL
0
MOTOR TERMINAL LEFT closer to ground
than to battery voltage
MTR
1
MOTOR TERMINAL RIGHT closer to the
battery voltage than to ground
MTR
0
MOTOR TERMINAL RIGHT closer to ground
than to battery voltage
OC
1
Current through the bridge higher than allowed
OC
0
Current through the bridge within safe limits
steps. This ensures that an active switch is first turned
OFF before activating a different switch. If there are no
faults on the H bridge or the motor, both the signals MTL
and MTR have the same polarity because the motor
resistance is only a few ohms. When a high side switch is
turned ON, the motor terminals are close to VBAT, and
hence MTL and MTR are both HIGH. When a low side
switch is turned ON, they are both LOW. When all
switches are turned OFF, the two motor terminals would
start going LOW, as the resistor dividers on both sides will
pull them down (Figure 6). Therefore, with all switches
OFF, both MTL and MTR are LOW. Any deviations from
Document No. 001-75813 Rev. *A
7
®
H Bridge Based Motor Drive Protection Using PSoC 3
the behaviors mentioned in the table are indicative of
faults. Motor terminals may have large capacitances,
leading to slow transitions of MTL and MTR from HIGH to
Table 5. Select BSWs and Their Interpretation
BSW
LOW. The bridge is neutralized actively between high side
switch activations to bring both the signals LOW. The
sequence can be run at high speeds; in the associated
project the total sequence takes 200 µs. The designer can
decide how frequently the sequence needs to run based
on the application. In the associated project, it is run every
2 seconds on a stationary motor.
Table 2 and Table 3 demonstrate how we can interpret a
particular combination of digital signals as a fault
condition. Only a few of the combinations correspond to a
faultless bridge and motor. This enables us use only the
digital signals to encode the state of a bridge and allows
us to define the Bridge Status Word (BSW) described in
Table 6.
0x4C
The motor is running with HSL and LSR turned ON.
0x4D
The motor is running with HSL and LSR turned ON.
There is over current.
0x48
The motor is running with HSL and LSR turned ON.
There may be a possible short to ground.
0x4E
The motor is running with HSL and LSR turned ON.
There may be a possible short to battery.
0x4F
Same as above.
0x80
The motor is stationary. All switches are OFF. Bridge
is in expected condition.
e
The BSW is a snapshot of the voltage and current
conditions of the H bridge converted to a single byte. It
should be sampled at proper instants to obtain meaningful
information. Switches take finite time to turn ON or OFF,
and hence the BSW should be sampled only when
switches are in defined states and not in transition. A
correctly sampled BSW directly maps to either a normal
operating condition or a faulty state using a lookup table;
this makes fault identification straightforward. It also allows
the system to “log” the bridge activity through a sequence
of bytes. The system firmware may periodically store the
BSW in a circular buffer, maintaining a history for a
predetermined amount of time. Table 5 shows a few
BSWs and their interpretation. It is by no means an
exhaustive list.
Meaning
The motor is stationary. All switches are OFF. There is
a short to battery.
Ob
so
let
0x86
0xC6
The motor is OFF. HSL is turned ON. Motor is OK
0xC4
The motor is OFF. HSL is turned ON. Motor is open.
0xC0
The motor is OFF. HSL is turned ON. There is a short
to ground.
This reduces the load on the master. In the next section,
we present a high level architecture of a system which
can:
If any fault condition is detected when the motor is
running, then the motor is stopped and a diagnostic is
performed on the motor. It is also performed periodically
on stationary motors as a fault discovery mechanism.
From the above discussion, it is clear that the system
needs to monitor the control signals (HSL, HSR, LSL and
LSR), as well as the status signals (MTL, MTR and OC). If
it detects a fault, the system communicates appropriate
status to the master. It is advantageous for the system to
generate the control signals, as it can take the protective
action itself, rather than relying on the master to do so.

Communicate with a master and configure itself as
requested

Generate the control signals as per request from a
master


Generate the status signals, and the BSW
Process the BSW to analyze and report faults
Table 6. The Bridge Status Word
Bit Position
Bit Name
Description
7
6
5
4
3
2
1
0
Mode
HSL
HSR
LSL
LSR
MTL
MTR
OC
The gate of
the High
Side Left
transistor,
depicts
whether it is
ON (1) or
OFF (0).
The gate of
the High
Side Right
transistor,
depicts
whether it is
ON (1) or
OFF (0).
The gate of
the Low
Side Left
transistor,
depicts
whether it is
ON (1) or
OFF (0).
The gate of
the Low
Side Right
transistor,
depicts
whether it is
ON (1) or
OFF (0).
Depicts
whether
MOTOR
TERMINAL
LEFT is
pulled to
VBAT (1) or
to ground
(0)
Depicts
whether
MOTOR
TERMINAL
RIGHT is
pulled to
VBAT (1) or
to ground
(0)
Depicts
Over
Current
condition. 1
= Over
Current, 0 =
Normal
condition
0 = The
motor is
being
driven.
1 = The
motor is
stationary
www.cypress.com
Document No. 001-75813 Rev. *A
8
®
H Bridge Based Motor Drive Protection Using PSoC 3
High Level Architecture of Fault
Detection and Protection System
The availability of a large number of analog and digital
resources in the PSoC 3 allows one to easily design the
fault detection and protection system. A good architecture
Figure 8. Example Arrangements of H Bridge and Motors
VBAT
2
4
3
M1
6
5
7
Shunt
3
Shunt 2
The next major consideration is the ability to share
resources across multiple motors. The shared resource
paradigm is essentially based on time multiplexing. Figure
9 compares the shared resource paradigm against the
“unfolded” or dedicated resource paradigm.
The figure shows the inputs (BSW), the functional unit f1
required for the computation, the sharing mechanism (S
and S'), and the outputs. The unfolded mechanism
requires more functional units but requires no sharing
mechanism.
let
Shunt 1
8
M5
M4
M3
M2
The fault detection and protection system should work for
both isolated and connected motors. Each motor can be
uniquely identified by the two half bridges to which it
connect. Therefore, it is more useful to allocate resource
for each half-bridge rather than each motor, because halfbridges are shared in connected groups. Such an
allocation requires a mechanism for independent access
of each individual half-bridge, so that the motors can be
independently accessed irrespective of the way they
connect.
e
1
between the motors except through the battery or ground.
In Figure 8, M1 and M2 are isolated as are M2 and M4.
Connected motors are all motors which are not isolated.
M3, M4 and M5 are connected and belong to a connected
group.
is scalable, i.e. it allows the easy addition of a new
H bridge or a new motor. Also, a good architecture
minimizes resource usage to enable the implementation of
additional features if required.
Ob
so
The physical connection of the motors and the bridges
significantly influences architectural choices. In many
applications, H bridges are shared across motors. This is
often the case where the motors need not run both
simultaneously and independently as in the example
shown in Figure 8.
Motors M1 and M2 can run simultaneously and
independently with any speed and direction, but no two
motors among M3, M4 and M5 can be driven
independently at the same time. Isolated motors are those
where there are no connections with all the switches off
Figure 9. Dedicated vs. Shared Resource Paradigm
BSW_M1
BSW_M2
f1 (MN)
UNFOLDED
f1 (M1)
BSW_M1
f1 (M2)
f1
S'
f1 (MN)
BSW_MN
SHARED
www.cypress.com
Number of inputs N

Required rate of outputs
Resource requirement or cost of the functional unit
Resource requirement or cost of the sharing
mechanism
The major determinant of the architecture is the output
update rate. If new outputs are required every T unit time,
and the functional unit f1 requires fT unit time to compute
the output for every new input, then the maximum number
of inputs which a single functional unit can process is:
f1 (M2)
BSW_MN
S



f1 (M1)
f11 f12
f1N
BSW_M2
The choice between the two is influenced by the following
factors:
T 
 f T 
where x  denotes the greatest integer less than or equal
to x. This calculation neglects any delay introduced by the
sharing mechanism. This delay may become significant
with a large number of inputs.
The next factor which affects the architecture is the total
cost of the system. The cost of the functional units in both
architectures scales linearly with the number of inputs.
However, the time delay introduced by the sharing
mechanism scales logarithmically with the number of
inputs. Often, designers select a mixed architecture where
a functional unit is allocated for every m inputs out of a
total of N inputs.
Document No. 001-75813 Rev. *A
9
®
H Bridge Based Motor Drive Protection Using PSoC 3
One can further optimize the architecture with knowledge
of connected groups. As motors in a connected group do
not operate simultaneously and independently, they may
not require dedicated resources.
Calculation of the optimum cost based on a given motor
connection and a required output update rate is beyond
the scope of this application note. It is important to
carefully consider this issue when choosing a particular
connection.
We selected the architecture used in this application note
with consideration for the reusability of blocks, scalability
and modularity of functions. Resources are shared
wherever possible. Figure 10 depicts the architecture of
our example. It consists of six major blocks:
Bridge Interface
Over Current
Fault Detect
Diagnostic
Firmware
These six blocks, along with the user interface, make up
the complete system. The system designer can configure
these blocks using APIs.
The Bridge Interface block interfaces with the physical
H bridge. It configures the device pins correctly so as to
transmit the control signals from the device to the bridge
and the status signals from the bridge to the device. The
Bridge Interface block consists of multiple half-bridge
interface blocks. Each of these half-bridge interface blocks
receives the H_BRIDGE DRIVE SIGNALS from the
MOTOR DRIVE SIGNALS generation system or control
signals from the Diagnostic block. The Fault Detect block
observes the control signals incident on the bridge, and
the resultant status signal from the bridge. In case of an
abnormal condition, an invalid BSW is detected. The Fault
te






Motor Drive Signals generation
Figure 10. Example Operation of a Given Motor Configuration with the High Level Architecture
1
2
HALF BRIDGE
INTERFACE 1
ACTIVE
5
M2
6
M3
7
M4
8
M5
HALF BRIDGE HALF BRIDGE HALF BRIDGE HALF BRIDGE HALF BRIDGE HALF BRIDGE HALF BRIDGE
INTERFACE 2 INTERFACE 3 INTERFACE 4 INTERFACE 5 INTERFACE 6 INTERFACE 7 INTERFACE 8
ACTIVE
MOTOR DRIVE
SIGNALS
www.cypress.com
4
3
Ob
M1
so
le
VBAT
ACTIVE
ACTIVE
FAULT DETECT
OFF
DIAGNOSE
DIAGNOSE
OFF
DIAGNOSTIC
Document No. 001-75813 Rev. *A
10
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 7. Half-Bridge Interface Block Signals and Their Significance
Signal Name
Signal Type
Significance
Digital Input
The signal that controls the half-bridge drive signals. If this signal is 0, then the PIN_HS and
PIN_LS disable the gate drivers, thus deactivating both the high side and the low side switches.
HS_Ctrl
Digital Input
The signal that controls the high side switch through PIN_HS. If the bridge is enabled and HS_Ctrl
is high, the switch is turned ON; otherwise the switch is turned OFF.
LS_Ctrl
Digital Input
The signal that controls the low side switch through PIN_LS. If the bridge is enabled and LS_Ctrl
is high, the switch is turned ON; otherwise the switch is turned OFF.
PIN_HS
Digital Output
The pin that controls the high side gate driver.
PIN_LS
Digital Output
The pin that controls the low side gate driver.
Bridge
Digital Output
The digital state produced by comparing V_Bridge and Threshold, as seen in Figure 11.
PIN_BRIDGE
Analog Input
An input pin used to connect to the V_Bridge signal.
Threshold
Analog Input
The signal used as the reference for digitizing the V_Bridge signal, as seen in Figure 11.
PIN_ANALOG
Analog Input
An optional pin used to bring an analog signal into the system. In the present application, used
monitor the current through the bridge.
Analog Signal
Analog Output
e
Enable
let
An optional signal which might route into the system. It may be any analog signal deemed
necessary to be monitored. In the present application, used for over current detection and hence
connected to the low side shunt signal.
Figure 11. Conceptual Realization of the Half-Bridge
Interface Block
so
Detect block identifies this as a fault, and overrides the
control signals to deactivate the bridge. The Fault Detect
block can observe and alter the H_BRIDGE DRIVE
SIGNALS as depicted in the diagram by the bidirectional
lines between the block and the signals.
Ob
Figure 10 demonstrates an example of the architecture in
operation. The Motor Drive Signals block generates
signals for all motors which route to the half-bridge
interface blocks. The firmware configures the routing so
that each half-bridge interface block receives the correct
set of signals. The figure illustrates a case where motors
M1 and M2 are running, M3 and M5 are off, and M4 is
being diagnosed. The color coding shows the type of
signals received by each half-bridge and each motor. The
Over Current block is not shown in the figure. In this
scenario, it monitors motors M1 and M2.
Implementation of the Fault Detection
and Protection System
We used PSoC 3 to implement an example fault detection
and protection system based on the architecture
discussed in the previous section. For an introduction to
design with PSoC 3, please see AN54181. We designed
the system to drive, monitor and protect two isolated
motors.
The Half Bridge Interface Block
Conceptual Realization
This block interfaces the system with the physical H bridge
and the motors. Figure 11 illustrates the conceptual
realization of the block. Table 7 lists the inputs and outputs
of the Half-Bridge Interface block along with their
significance.
www.cypress.com
PIN HS
Enable
HS_ctrl
To VBAT/High
Side Shunt
HALF- BRIDGE
INTERFACE
BLOCK
HIGH
SIDE
GATE
DRIVE
LS_ctrl
Bridge
Threshold
Analog_Sig
PIN BRIDGE
+
PIN LS
V_Bridge
LOW
SIDE
GATE
DRIVE
PIN ANALOG
To VSS/Low
Side Shunt
We discussed two ways to drive a high side gate in the
section Alternate Methods to Drive H Bridges. The
V_Bridge is the resistor divided voltage at the middle of
the half-bridge, i.e. at the motor terminal. In this
application note, PIN ANALOG interfaces to the low side
shunt, but you may choose to connect it to the high side
shunt or to any other analog signal deemed necessary.
PSoC 3 Implementation
Figure 12 shows the PSoC3 implementation of the HalfBridge Interface block and the associated configuration
signals. We can drive the digital control signals (Enable,
HS_Ctrl, and LS_Ctrl) with either the normal mode signals,
marked by _N, or the diagnostic mode signals, marked by
_D. The project uses the signal MODE to select the
Document No. 001-75813 Rev. *A
11
®
H Bridge Based Motor Drive Protection Using PSoC 3
Ob
so
let
e
Figure 12. PSoC 3 Implementation of the Half Bridge Interface Block
correct set of signals that go into the half-bridge. The
project uses four instances of the Half-Bridge Interface
block.
The HS_Ctrl and LS_Ctrl signals are logically AND’d with
the Enable signal, so that they are ignored when Enable is
OFF. The NOT gates are used before the pins, because
the gate drivers are active low (i.e. they turn the switches
ON when their inputs are LOW).
If required, you can insert an analog buffer between the
Pin_Analog and the Analog signal to prevent loading of
the signal. The availability of analog buffers on PSoC 3
makes this easy to implement.
with hardware connection, and its Threshold is chosen to
be VREF. This effectively configures the pin as a
comparator, with the output as the digital state read by the
pin, and the VREF signal as the reference. A digital to
analog converter generates this reference (the Threshold
signal) to allow easy modification of the threshold.
Alternately, it can be driven by another analog signal
directly derived from the battery. For details on the SIO
implementation, please consult the pin component
datasheet and AN60580.
The block does not interact with firmware, and it does not
have any APIs. The Over Current, Fault Detect and
Diagnostic blocks use signals from this block.
The Serial IO (SIO) pins available in PSoC 3 allow us to
implement the Pin_BRIDGE and the comparator shown in
Figure 11. The SIO pin is configured as a digital input pin
Over Current, Fault Detect and Diagnostic
Blocks
Figure 13. Behavioral Differences Between Traditional and
Modified Blanking Timers
The Over Current, Fault Detect and Diagnostic blocks are
each divided into a few major parts:
www.cypress.com

Fault Signal Detection Block: Detects the actual
fault. The implementation varies according to the type
of fault being identified.

Blanking Timer: Verifies that the detected fault is a
true fault and not misidentified noise. This is common
to all three block types.

Fault Latch: Ensures that once a fault is verified by
the Blanking Timer, it is latched and cannot be cleared
even if the fault condition goes away. The latch must
be cleared in firmware and requires master
intervention to ensure that the master acknowledges
all faults.
Document No. 001-75813 Rev. *A
12
®
H Bridge Based Motor Drive Protection Using PSoC 3

Status Register: Records the fault signals at the time
of the occurrence of any fault. The firmware reads the
status register to determine the source of the fault.


Control Register: Interfaces to the firmware.
Application Programming Interface
Blanking Timer
For example, imagine a case where a switch undergoes
periodic fault conditions but with the period being less than
LIMIT. With a traditional blanking timer, the temperature
might increase slowly and eventually put the device
outside its SOA. However, the modified timer expires if the
fault persists more often than not. The disadvantage of the
modified approach is its reduced robustness to noise as
compared to the traditional realization. If noise has high
average persistence then it may be recognized as a true
fault.
so
let
e
The Blanking Timer “blanks” or becomes zero from some
non-zero starting value. Certain “events” trigger the timer.
Once triggered, it starts to count down. If it “blanks” or
reaches zero, then it may trigger an action. However, if it
is interrupted (the triggering event does not persist, or
otherwise), then it returns to the initial count and maintains
the count until triggered again. A Blanking Timer ensures
that a decision is made based on the occurrence of a true
event, as against temporary disturbance.
The COUNT variable of the modified timer is not reset to 0
as soon as the Fault signal disappears; rather, it smoothly
transitions from its present value to 0. Therefore, the
decision about the occurrence of the fault is not based on
its continuous persistence over a period of time, but by its
“average” persistence. The average persistence is better
suited to the present application, as faults, though not
continuously present, reduce the reliability of the H bridge
and the load as a whole.
In this application note, we modified the behavior of the
Blanking Timer to best suit the needs of the application.
We maintain the name as the essential purpose is the
same. Without loss of generality, we assume that both the
modified and the traditional timers start at 0 (instead of a
non-zero starting value) and count up to a pre-specified
limit.
Ob
Figure 14 describes the behavior of the modified timer.
The input signals RESET, ENABLE, SIGNAL_IN and
CLOCK control the timer. The output signal EXPIRED
indicates a fault. The firmware sets the internal parameter
LIMIT. This parameter determines the “blanking time”, or
the period for which the event needs to persist in order to
be acknowledged as a true event. The figure shows how
inputs affect the variable COUNT. It also shows how
COUNT, in turn, controls the output.
Figure 14. Functional Realization of the Blanking Timer
FW
We implement the blanking timer with datapaths.
Datapaths are hardware modules available in the
Universal Digital Blocks (UDB) in PSoC 3. Each UDB
contains one datapath element. PSoC Creator allows
these modules to be instantiated inside a user defined
Verilog module, as shown in Figure 15.
The datapath consists of several registers. We discuss
only the registers relevant to the implementation, A0 and
D0. The Datapath Configuration Tool allows eight possible
operations of the datapath. At a given clock cycle, the
value of STATE determines the particular operation to be
performed. For more detailed information on Verilog and
datapath based components, please refer to these
Figure 15. Datapath Based Implementation of the Blanking
Timer
A Verilog Module
module BT(...
(LIMIT)
RESET
ENABLE
SIGNAL_IN
CLOCK
COUNT
At every positive edge of the clock:
If (RESET is HIGH) COUNT = 0
Else If (ENABLE is HIGH)
case 1: SIGNAL_IN is HIGH
If(COUNT != LIMIT)
COUNT = COUNT + 1
Else
COUNT = LIMIT
case 2: SIGNAL_IN is LOW
If(COUNT != 0)
COUNT = COUNT - 1
Else
COUNT = 0
Else // {ENABLE is LOW}
COUNT = COUNT
State Machine
EXPIRED
(COUNT)
RESET
EXPIRED
Always
If (RESET == HIGH)
STATE = RESET
Else If ((ENABLE == HIGH) AND
(SIGNAL_IN == HIGH) AND (cl0 == 1))
STATE = INCREMENT
Else If ((ENABLE == HIGH) AND
(SIGNAL_IN == LOW) AND (z0 == 0))
STATE = DECREMENT
Else
STATE = MAINTAIN
ENABLE
EXPIRED
Output Generation
If (COUNT is LESS than LIMIT)
EXPIRED = LOW
Else // (COUNT is greater than or
equal to LIMIT)
EXPIRED = HIGH
SIGNAL_IN
Always:
If (cl0 == HIGH)
EXPIRED = 0
Else
EXPIRED = HIGH
z0
STATE
cl0
CLOCK
A0
The major difference between the present realization and
a traditional Blanking Timer is the symmetric movement of
the internal variable COUNT between its two terminal
values (0 and LIMIT). Figure 13 illustrates this point.
www.cypress.com
Document No. 001-75813 Rev. *A
D0
z0 = (A0 == 0) ? 1 : 0
cl0 = (A0 < D0) ? 1 : 0
An Instance of Datapath Module
13
®
H Bridge Based Motor Drive Protection Using PSoC 3
trainings (Verilog, Datapath).
The datapath operations used in this application note are:
Thresholding
RESET: Loads the register A0 with value 0.
Analog
Signal
+
INCREMENT: Increases the value of A0 by 1.
Blanking
Timer
_
DECREMENT: Decreases the value of A0 by 1.
Over Current
Fault
Threshold
Generation
MAINTAIN: Maintains the value of A0.
The implementation uses two outputs from the datapath:
z0 and cl0. Their significances are as follows:


Signal
Conditioning
Figure 17.Over Current Alarm Generation from
Thresholded Current Output
CURRENT SIGNAL 2
z0 = 1 if A0 is equal to 0; it is zero otherwise.
CURRENT SIGNAL 1
cl0 = 1 if A0 is less than D0; it is zero otherwise.
All three fault detection blocks use a blanking timer. The
Over Current, Fault Detect, and Diagnostic blocks use
their associated APIs to configure their own blanking
timers. There is no API particular to the blanking timers.
Over Current Block
Ob
The Over Current block monitors the current through the
bridge, and takes appropriate actions when the current
exceeds the set threshold for a significant amount of time.
A low side shunt converts the current into voltage, and
hence the over current block actually monitors voltage.
Conceptual Realization
As shown in Figure 16, the Over Current block consists of
three parts: the signal conditioning portion, the
thresholding portion and the blanking timer.
Depending on the nature of the signal and the
requirements, the analog signal from the Half-Bridge
Interface block may need amplification and . It may also
require differential amplifiers depending on the noise
levels. The implementation in this application note uses
single ended amplification.
The system compares the processed against a set
threshold. The result is a digital signal whose state
depends on the analog signal. Figure 17 shows how the
Blanking Timer accumulates the digital signal accumulates
over a period of time to determine the over current fault.
The system then compares the Current Signal, which is
actually the output from the Signal Processing block
against the over current threshold (OC threshold) to
produce the comparison result (ThC). This output
accumulates or integrates until it reaches another pre-set
threshold. At this point the Over Current alarm is set off.
The accumulation approach has three principle
advantages:
www.cypress.com
OVER CURRENT
THRESHOLD
THRESHOLDED
CURRENT (ThC)
ACCUMULATOR THRESHOLD
so
let
Using these two values and the input signals to the
Blanking Timer, a state machine is designed in Verilog
which controls the datapath operation at each clock cycle.
The A0 register essentially acts as the COUNT variable
and the DO register acts as the LIMIT parameter. The D0
register can be written in firmware, allowing us to
configure the Blanking Time.
e




Figure 16. Conceptual Realization of the Over Current
Block
∫ ThC
OVER
CURRENT
ALARM

The SOA of the switch suggests that it can tolerate a
specific amount of over current for a specific amount
of time based on the temperature. The accumulation
approach therefore leads to better use of the switch
rather than instantaneous over current.


It eliminates effect of spurious noise.
As the Blanking Timer does the integration in the
digital domain and the result compared against a
digital threshold (the blanking time), it is easy to
configure the system for different H bridges and
motors with different over current tolerance without
using external components such as capacitors.
A larger over current threshold implies that the switch can
tolerate over current for a shorter time the current without
violating the SOA. Therefore, the over current threshold
and the accumulator threshold are related and should be
set appropriately.
As seen in Figure 17, the current signal1 and current
signal 2, although indicative of different severity, produces
identical effect. This is a disadvantage of the discussed
approach. The current signal 2, however, is unlikely to be
encountered in a practical application. A carefully chosen
over current threshold, accumulator threshold, and slope
of accumulation can circumvent such problems.
PSoC 3 Implementation
Ready availability of configurable analog blocks makes the
PSoC 3 implementation of the Over Current block
straightforward. Figure 18 shows the implementation of
two Over Current blocks for two isolated motors. A
Programmable Gain Amplifier (PGA) amplifies the voltage
Document No. 001-75813 Rev. *A
14
®
H Bridge Based Motor Drive Protection Using PSoC 3
A voltage DAC generates the over current threshold. The
firmware can modify the DAC value at runtime to change
the threshold. Choose the range and value of the DAC
based on the current rating of the motor and the value of
the shunt resistor. As the threshold changes infrequently,
a slow speed setting is sufficient.
The amplified signal goes to the positive input of a
comparator, and the generated threshold to the negative
input. Configure the comparator with hysteresis enabled
and with non-inverting polarity (output is high when
positive input is greater than negative input). Each
comparator synchronizes to a clock with half the frequency
of the blanking timer clock to ensure that the SIGNAL_IN
input of the blanking timer is always stable at its clock
edges. For more information, see the PGA, DAC and,
Comparator datasheets.

Define the inrushPeriod for each motor as the
duration that inrush current is most likely to.

During this time, set the SoftStart_OC_x (x=1,2) to
HIGH. This gates the Blanking Timer output from the
Fault Latch. Instead, it feeds the output back to the
motor drive signal generation unit (Inrush_x) to turn
the bridge OFF.

The over current blanking time is set to the value
STARTING_BLANKING_TIME which is typically much
less than the normal operating conditions.
It is clear that the switches operate inside the SOA,
because the threshold is the same as that for regular
operating condition and the blanking time is less than the
regular blanking time. The following events lead to motor
start:
so
let
The over current signals Oc_Signal_1 and Oc_Signal_2
are input to the Blanking Timer blocks. A high signal for a
sufficiently long time triggers an Over Current fault. The
two EXPIRED signals from the Blanking Timers are
logically OR’d to produce the resultant Over Current fault.
The Fault Latch latches the fault. Once latched, only
firmware can clear the fault.
When a motor starts, a large amount of inrush current
flows through the motor until it reaches a stable speed. An
OC Threshold set for normal operating conditions will
misidentify the inrush current as an over current condition.
Similarly, an OC threshold set for the inrush current may
result in switches operating outside their SOA. Heavy
motors with large inertia are particularly prone to this
problem. A soft start strategy solves this problem. The soft
starting strategy works as follows:
e
signal which originates from the shunt resistor or from a
preconditioning circuit to allow a quick gain change without
change of any external components.
Ob
Figure 18. PSoC 3 Implementation of the Over Current Blocks
www.cypress.com
Document No. 001-75813 Rev. *A
15
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 8. API Functions of the Over Current Block
Function
Action
Starts and configures all the analog peripherals used by the OverCurrent _x block and
resets the Blanking Timer, Fault Latch and Status Register blocks.
OverCurrent_x_Stop()
Stops all the analog components associated with OverCurrent_x block and resets the
Blanking Timer, Fault Latch, and Status Register blocks.
OverCurrent_x_SetThershold
(uint8 threshold)
Sets the Over Current threshold by modifying the DAC value with the supplied
parameter threshold.
uint8 OverCurrent_x_GetThreshold()
Returns the current threshold for OverCurrent_x block.
OverCurrent_x_SetBlankingTime
(uint8 blankingTime)
Sets the blanking time for OverCurrent_x block by modifying the blanking timer D0
register according to the supplied parameter blankingTime.
uint8
OverCurrent_x_GetBlankingTime()
Returns the current blanking time.
OverCurrent_x_Enable()
Enables the OverCurrent_x block by enabling its blanking timer.
OverCurrent_x_Disable()
Disables the blanking timer of the OverCurrent_x block from counting.
OverCurrent_x_SoftStartEnable()
Enables the soft start function for OverCurrent_x block by setting the SoftStart_OC_x
signal HIGH, and changing the blanking time value to
STARTING_BLANKING_TIME_x.
Ob
so
let
OverCurrent_x_SoftStartDisable()

e
OverCurrent_x_Start()
Disables the soft start function for OverCurrent_x block by setting the SoftStart_OC_x
signal LOW, and changing the blanking time value to normal operating value.
The current through the motor increases till it exceeds
the OC threshold for the duration
STARTING_BLANKING_TIME.

The Blanking Timer expires, setting the Inrush_x
signal to high. This turns the bridge OFF.

The current through the motor decreases, and the
Blanking Timer output goes LOW. This sets Inrush_x
low, and the bridge turns ON again. This restarts the
cycle.
In this way the motor starts without transgressing the SOA
of the switches. After the inrushPeriod, the
SoftStart_OC_x signal turns OFF, and the blanking time is
set to its normal operating value.
A sudden and large increase in speed may also require
large current. The user may modify the threshold and
blanking time values for such events accordingly.
When the system detects any kind of fault, it sets the
ANY_FAULT signal to HIGH. On the occurrence of any
faults, the status register logs the Blanking Timer output.
The Over Current control register initializes and configures
the Over Current blocks. It controls the passage of the
clock to the blanking timers and handles their initialization
and configuration as required by the application. It is also
used as an interface between the firmware and the actual
hardware.
Fault Detect Block
The Fault Detect block detects any abnormal bridge
behavior while the motor is in operation.
Conceptual Realization
Table 9 lists the BSWs for particular faults. For each halfbridge, we can define the fault as a logical operation on
the high-side control signal, the low-side control signal,
and the state of the bridge. This enables us to easily map
the BSW to a specific fault condition. Figure 19 shows the
logical definition for both half-bridges.
Table 9. Abnormal Conditions and Associated BSW for
Fault Conditions with Active Motors
Signal 1 Signal 2 BSW(binary)
Meaning
HSL = 1 MTL = 0
01x0x0xx
High side left FET is on, but
the motor left terminal is close
to ground.
LSL = 1 MTL = 1
00x1x1xx
Low side left FET is on, but
the motor left terminal is close
to VBAT
HSR = 1 MTR = 0
0x1x0x0x
High side right FET is on, but
the motor right terminal is
close to ground.
LSR = 1 MTR = 1
0x0x1x1x
Low side right FET is on, but
the motor right terminal is
close to VBAT
The Over Current block offers a set of APIs listed in for
easy configuration of the system. The OverCurrent_x
prefix denotes that the API is particular to the Over
Current unit x (x = 1 or 2).
www.cypress.com
Document No. 001-75813 Rev. *A
16
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 19. Logical Definition of Bridge Fault
HIGH
SIDE
LEFT
VBat
D1
D2
Figure 20. The FD Component
HS1
HIGH
SIDE
RIGHT
LS1
BT CONTROL
BRIDGE 1
Fault
Fault
FAULT
LS2
M
BT_RESET
BT_ENABLE
HS2
FAULT LOGIC
BRIDGE 2
CLOCK
D3
D4
LOW
SIDE
LEFT
BT CONTROL
LOW
SIDE
RIGHT
If (HS1 or HS2 or LS1 or LS2 is HIGH)
BT_ENABLE = HIGH
Else
BT_ENABLE = LOW
At every positive edge of the clock:
If (HS1 or HS2 or LS1 or LS2 has changed)
BT_RESET = HIGH
Else
BT_RESET = LOW
If ( (HS1 is HIGH) AND (BRIDGE_1 is LOW))
FAULT = 1
Else If ( (LS1 is HIGH) AND (BRIDGE_1 is HIGH))
FAULT = 1
Else If ( (HS2 is HIGH) AND (BRIDGE_2 is LOW))
FAULT = 1
Else If ( (LS2 is HIGH) AND (BRIDGE_2 is HIGH))
FAULT = 1
Else
FAULT = 0
so
let
e
The logical definition in Figure 19 automatically protects
against turning on the high side and the low side switch of
the same half-bridge simultaneously. The availability of
digital logic gates on PSoC 3 makes it particularly easy to
implement the above fault detection circuit.
FAULT LOGIC
PSoC 3 Implementation
The heart of the Fault Detect block is the FD component.
We use Verilog to implement the FD component. Figure
20 describes it behavior.
The Fault Detect Control Register configures the system
initially and between system stalls due to any fault. The
Firmware block uses this as an interface to the Fault
Detect system. Table 10 lists the API functions of the Fault
Ob
The BT CONTROL portion generates the RESET and
ENABLE signals for the Blanking Timer block. The system
resets the Blanking Timer every time there is a transition
on any of the bridge drive signals. This ensures that the
system does not incorrectly detect any intermediate
condition during the transition of a switch as a fault. Also, it
disables the Blanking Timer unless at least one of the
switches on the H bridge is ON. The Fault Logic block is
the Verilog implementation of the fault definitions in Figure
19.
Figure 20 shows the complete implementation of two Fault
Detect blocks. During soft start, the bridge is continuously
in transition; therefore, the blanking timers are held in
RESET during this period. The EXPIRED signals from the
Blanking Timers are logically OR’d to produce the fault
signal to indicate that at least one of the H bridges
sustained a fault. The Fault Latch block then latches the
signal. The ANY_FAULT signal logs the status of the two
EXPIRED signals into the Status Register. The status is
used later to analyze the source of the fault.
Table 10. API Functions for the Fault Detect Block
Function
Action
FaultDetect_x_Start()
Starts the Fault Detect system by allowing the clock to FD_x component and
the Blanking Timer BT_FD_x. Resets the Blanking Timer internal count to 0.
Clears the Status Register and the Fault Latch flip-flop of any pre-existing
fault status.
FaultDetect_x_Stop()
Gates the clock to the FD_x component and the Blanking Timer BT_FD_x.
The Blanking Timer internal count is reset to 0. Clears the Status Register and
the Fault Latch flip-flop of any pre-existing fault status.
FaultDetect_x_Enable()
Enables the Fault Latch functionality.
FaultDetect_x_Disable()
Disables the Fault Latch functionality.
FaultDetect_x_AssertReset()
Resets the Blanking Timer BT_FD_x, the Status Register and the Fault Latch
flip flop. These are held in reset until released.
FaultDetect_x_ReleaseReset()
Releases the Blanking Timer BT_FD_x, the Status Register and the Fault
Latch from reset condition.
FaultDetect_x_SetBlankingTime
(uint8 blankingTime)
Configures the blanking timer BT_FD_x so that the blanking time is equal to
the provided parameter blankingTime. The Blanking Timer and the Fault
Latch are also reset.
uint8
FaultDetect_x_GetBlankingTime()
Returns the current blanking time of BT_FD_x.
www.cypress.com
Document No. 001-75813 Rev. *A
17
®
H Bridge Based Motor Drive Protection Using PSoC 3
Ob
so
let
e
Figure 21. PSoC3 implementation of the Fault Detection System
Detect_x (x= 1,2) block.
Diagnostic Block
The Diagnostic block:


Periodically monitors loads which are inactive.
Diagnoses a bridge reported by the Over Current or
the Fault Detect blocks.
Conceptual Realization
The Diagnostic block manages the sequence described in
Table 3. The Diagnostic sequence excites the H bridge,
Figure 22.Conceptual Realization of the Diagnostic Block
DIAGNOSTIC
SIGNAL
GENERATION
CONTROL
SIGNALS
DIAGNOSTIC
FAULT
DETECTION
DETECTED
FAULT
VBat
STATUS
SIGNALS
M
www.cypress.com
BLANKING TIMER
DIAGNOSTIC
FAULT
and the resulting status signals combine with the
sequence to form the BSW. The BSW maps to a normal
condition or a particular fault. The Diagnostic system as
shown in Figure 22 consists of two parts: signal generation
and BSW analysis. As usual, it uses the Blanking Timer to
distinguish true faults from noise.
The Diagnostic Signal Generation component generates
the control signals for two half-bridges: Half-bridge 1 and
Half-bridge 2 as well as a few configuration signals for the
Diagnostic Fault Detection component. For ease of
discussion, we assume that Half-bridge 1 is the left halfbridge. Table 11 shows the inputs and outputs of the
Diagnostic Signal Generation component. Figure 23
illustrates the corresponding timing diagram as well as the
clock-cycles, with 0 being the first cycle after ENABLE is
set high.
When a load is inactive, all the switches on the H bridge
are OFF. The resistor dividers on the Motor Left Terminal
(MLT) and Motor Right Terminal (MRT) passively pull the
half-bridges down to ground. Therefore, with all switches
off, MTL and MTR should both be LOW. The
short-to-battery fault checks these two signals before
turning ON any switches. The LV_B1 signal indicates the
Diagnostic Fault Detection block to sample the MTL
signal. If it is HIGH, a short-to-battery fault is reported.
Similarly, the LV_B2 checks for the MTR signal. If any one
Document No. 001-75813 Rev. *A
18
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 11. Input and Output Signals of the Diagnostic Signal Generation Block
Signal Name
Signal Type
Signal Description
MAIN_CLOCK
INPUT
This is the input clock to the signal generation system. All output signal changes are synchronized to
this clock
RESET
INPUT
If this signal is HIGH, then all the output signals are set logic low.
ABORT
INPUT
This signal is used for aborting an active sequence. It sets DONE to HIGH, and all the other outputs to
LOW.
OUTPUT
This is the signal to turn ON the High Side switch for Half-Bridge 1, as described in Table 3.
HS2
OUTPUT
This is the signal to turn ON the High Side switch for Half-Bridge 2, as described in Table 3.
LS1
OUTPUT
This is the signal to turn ON one of the Low Side switch for Half-Bridge 1, as described in Table 3.
LS2
OUTPUT
This is the signal to turn ON the Low Side switch for Half-Bridge 2, as described in Table 3.
LV_B1
OUTPUT
When this signal is HIGH, the Diagnostic Fault Detection component checks Half-Bridge 1 for possible
shorts-to-battery. The fault should be evaluated only when this signal is HIGH.
LV_B2
OUTPUT
When this signal is HIGH, the Diagnostic Fault Detection component checks Half-Bridge 2 for possible
shorts-to-battery. The fault should be evaluated only when this signal is HIGH.
LG_B1
OUTPUT
When this signal is HIGH, the Diagnostic Fault Detection component checks Half-Bridge 1 for possible
shorts-to-ground. The fault should be evaluated only when this signal is HIGH.
LG_B2
OUTPUT
When this signal is HIGH, the Diagnostic Fault Detection component checks Half-Bridge 2 for possible
shorts-to-ground. The fault should be evaluated only when this signal is HIGH.
LATCH_LO
OUTPUT
When this signal is HIGH, the Diagnostic Fault Detection component checks for possible open load.
The fault should be evaluated only when this signal is HIGH.
DONE
OUTPUT
This indicates that the Diagnostic Sequence is over, that is two half-bridges and its associated load has
been tested.
Ob
so
let
e
HS1
of the half-bridges is shorted to battery, both MTL and
MTR go HIGH. With this configuration, it is not possible to
determine exactly which half-bridge is shorted to battery.
Nevertheless, the system checks both sides, because, in
the case of an open load, only one side may be HIGH
while the other side stays close to ground.
If the system detects no shorts-to-battery, it checks for
shorts-to-ground. The Diagnostic Signal Generator turns
on a high side switch and checks whether the half-bridge
is pulled up accordingly. The system interprets the halfbridge at low as a short-to-ground fault. The LG_B1 signal
signals the Fault Detection block to check for polarity of
MTL. Similarly, it uses LG_B2 to check MTR. There is a
delay of one clock cycle between the turning ON of a high
side switch (for example, HS1) and the corresponding
fault-checking signal (LG_B1). This ensures that the
switch has turned ON and settled, and the system does
not interpret a transition condition as a fault. Unlike the
shorts-to-battery test, the shorts-to-ground test turns on a
switch to check for a fault. Therefore, if a fault exists, this
leads to heavy current through the switch for the entire
duration of the test. For example, if Half-bridge 1 is
shorted to ground, then excessive current flows through
HS1 for the entire duration it is on (i.e. during clock cycles
www.cypress.com
6, 7 and 8 in Figure 23). Increasing the clock frequency
reduces the duration.
If the system detects no shorts to either battery or ground,
then it checks for an open load. It turns ON HS1 which
pulls Half-bridge 1 to battery. It allows sufficient time for
the Half-bridge 2 to be pulled up through the motor. The
system then turns ON the LATCH_LO signal which signals
the Diagnostic Fault detection unit to check whether both
the motor terminals (MTL and MTR) are HIGH. It interprets
both not HIGH as a load open fault. When the sequence is
over, the system sets the DONE signal HIGH and the
sequence stops until restarted. Once started by setting
ENABLE high, the entire sequence completes in 26 clock
cycles (0 through 25). In the example project, we use a
clock frequency of 125 KHz which results in a sequence
time of 208 µs.
All signals mentioned in Table 11 are inputs to the
Diagnostic block. In addition, the block uses the MTL and
MTR signals to determine the existence of a fault. The
block also configures the Blanking Timer which verifies
that the faults reported by the Diagnostic block are
persistent. Whenever any of the control signals changes,
the block detects the transition and resets the internal
count of the Blanking Timer to 0. Table 12 lists the inputs
and outputs of the Diagnostic block.
Document No. 001-75813 Rev. *A
19
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 23. Timing Diagram of the Diagnostic Signals
0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
DONE
LATCH_LO
LG_B2
LG_B1
LV_B2
e
LV_B1
LS2
so
let
LS1
HS2
HS1
ABORT
ENABLE
RESET
Ob
MAIN CLOCK
Table 12. Inputs and Outputs of the Diagnostic Fault Detection block
Signal Name
CLOCK
RESET
Type
Signal Description
INPUT
This is the input clock to the fault detection system. It controls the timing of the BT_RESET signal
INPUT
The RESET signal is used for clearing the internal logic used for control signal transition detection.
B1
INPUT
This signal is same as MTL (we assume that Half-bridge 1 is the left half-bridge)
B2
INPUT
This signal is same as MTR (we assume that Half-bridge 2 is the right half-bridge)
HS1, HS2, LS1, LS2,
LV_B1, LV_B2, LG_B1,
LG_B2, LATCH_LO
INPUT
Described in Table 11. The HS1, HS2, LS1, LS2 make up the BSW along with B1 and B2. The
LV_B1, LV_B2, LG_B1, LG_B2 and LATCH_LO indicate when to sample the BSW for a particular
fault.
VBAT
OUTPUT
This indicates that a short to battery condition has been detected.
GND
OUTPUT
This indicates that a short to ground condition has been detected.
LO
OUTPUT
This indicates that an open load condition has been detected.
BT_RESET
OUTPUT
This signal goes high for one clock cycle whenever any of the control signals change state.
BT_ENABLE
OUTPUT
This signal is high, whenever a BSW is ready to be sampled for a fault. This enables the Blanking
Timer. This is kept low at other times to ensure that spurious signals from transitioning BSWs are not
treated as faults.
www.cypress.com
Document No. 001-75813 Rev. *A
20
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 24. Implementation of the Diagnostic Signal Generation and Fault Detection Components
DIAGNOSTIC SIGNAL
GENERATION
RESET
ABORT
ENABLE
MAIN CLOCK
At every positive edge of MAIN_CLOCK
If (RESET is HIGH)
STATE = 0
Else If (ABORT is HIGH)
STATE = 25
Else
If( (ENABLE is HIGH) and (STATE ≠ 25) )
STATE = STATE + 1
Else
STATE = STATE
At every change of STATE
OUTPUTS = f(STATE)
OUTPUTS
(HS1, LS1, …
,DONE)
RESET
STATUS
SIGNALS
(MTL, MTR)
CLOCK
At every positive edge of CLOCK:
If (RESET is HIGH)
OLD_CONTROL_SIGNAL = ALL ZEROS
Else
If (OLD_CONTROL_SIGNALS
≠ CURRENT_CONTROL_SIGNALS)
BT_RESET = HIGH
Else
BT_RESER = LOW
FAULT
(VBAT, GND,
LO)
BT_RESET
BT_ENABLE
Always:
Fault = F(CONTROL, STATUS)
BT_ENABLE = F(CONTROL)
Diagnostic System, as shown in Figure 25.
The Fault Latch, the Status Register and the Control
Register have purposes similar to those used in the Over
Current and the Fault Detect blocks. The ABORT signal is
asserted on any occurrence of a Diagnostic fault to ensure
that the sequence does not continue to run. This prevents
the system from entering further hazardous conditions.
The interrupt service routine DIAGNOSTIC_DONE sets a
flag to indicate that one Diagnostic Sequence is complete,
and the Diagnostic system is available to diagnose
another inactive motor.
so
let
e
PSoC 3 Implementation
Figure 24 shows the implementation of the Diagnostic
Signal Generation and Fault Detection components. We
use Verilog to implement both the components. The bulk
of the Diagnostic Signal generation component is a state
machine that counts the clock-cycles and sets the outputs
based on the clock-cycle. It consists mainly of sequential
logic. The outputs are computed as a function of the
current state.
DIAGNOSTIC FAULT
DETECTION
The Diagnostic Fault generation component consists
mostly of combinatorial logic. Sequential logic is used for
transition detection of the control signals. The
combinatorial logic extracts the faults information from the
control and status signals. The two components, the
Blanking Timer, the Control and Status Registers and the
Fault Latch are put together to implement the complete
Table 13 lists the API functions to control and configure
the system offered by the Diagnostic System.
Ob
Figure 25. Complete Diagnostic System
www.cypress.com
Document No. 001-75813 Rev. *A
21
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 13. API Functions of the Diagnostic Block
Function
Action
Resets and starts the signal generation, the fault detection components and the Fault Latch. It
also clears the Status Register. However, the Diagnostic Signal Generation component is not yet
enabled.
Diagnostic_Stop()
Resets and stops the Diagnostic Signal Generation, the Diagnostic Fault Detection components
and the Fault Latch. The status register is cleared.
Diagnostic_Enable()
Enables the signal generation block by setting its ENABLE signal high. The signal generation
starts, if the block has been previously started by calling Diagnostic_Start().
Diagnostic_Disable()
Disables the signal generation by setting its ENABLE signal low.
Diagnostic_Abort()
Aborts the sequence, sets DONE to HIGH, and clears the Status Register.
Diagnostic_SetBlankingTime
(uint8 blankingTime)
Resets the signal generation, fault detection and Blanking Timer blocks, sets the D0 register of
the Blanking Timer according to the value blankingTime, and clears the Status Register.
uint8
Diagnostic_GetBlankingTime()
Returns the current value of the diagnostic blanking time.
Diagnostic_AssertReset()
Holds the signal generation, fault detection, Blanking Timer, and Fault Latch in reset. Clears the
Status Register.
Diagnostic_ReleaseReset()
Removes the reset condition from the signal generation, fault detection, Blanking Timer and the
Fault Latch. Clears the Status Register.
Diagnostic_ClearInterrupt()
Clears any pending interrupt caused by the DONE signal.
let
e
Diagnostic_Start()
Motor Drive Signals Block
drivers. A capacitive pump drives the other H bridge.
Figure 26 shows the Boost converter implementation.
so
We have discussed the three main blocks (Over Current,
Fault Detect, and Diagnostic) shown in Figure 6. The
remaining blocks are simpler so we show their
implementation directly without a conceptual realization.
Ob
The Motor Drive Signals block generates the PWM signals
for the H bridge switches. It includes one Boost converter
which allows PSoC 3 to drive one H bridge without special
A resistor divider circuit produces the Observed Output,
which is proportional to the Boost output voltage. The
comparator Comp_Boost compares the Observed Output
to a reference set by a DAC. Whenever the boost output
voltage is less than expected, the Boost FET is activated.
A fixed period and duty cycle square wave (produced by
the PWM Boost block) cycles the FET. An extra hysteretic
inverter on the Motor Control Board prevents spurious
Figure 26. PSoC 3 Implementation of the Boost Converter
MOTOR CONTROL BOARD
Boost
Output
70K
MBRS340
30K
Observed
Output
L = 22uH
From
Battery
IRF530N
C=22uF
7414
Hysteritic
Inverter
PSoC®3
www.cypress.com
Document No. 001-75813 Rev. *A
22
®
H Bridge Based Motor Drive Protection Using PSoC 3
The Boost converter block provides two APIs to control the
converter:


Boost_Start()
Starts and configures the DAC, the comparator and
the PW then writes a 0 to the Control Register to allow
the PWM signal to reach the FET controlling pin (Pin
4_0 in this case).
Boost_Stop()
Stops the DAC, the comparator and the PWM. The
Control Register is written with the value 1, which sets
the FET controlling pin high. This effectively disables
the Boost converter.
We choose to modulate the low side switches for this
motor. The Control_Reg_HALFBRIDGE_CONTROL is a
control register that enables the particular half-bridges
based on the motor that we want to turn ON. In case of
any fault (indicated by the ANY_FAULT signal), the
ENABLE_N signals go LOW, disabling all half bridges.
Both the PWMs are 8 bit and implemented in UDB. The
PWMs are disabled unless the motors they drive need to
be ON. This leads to less switching in the UDBs and
consequently less power consumption. Once the ENABLE
signal of an active PWM turns OFF, the PWM completes
the period before becoming inactive. We further gate the
signals from the PWM with the half-bridge enable signals
so that the control signals turn OFF as soon as the halfbridge enable signals go LOW, without waiting for the
period to get over.
so
le
The output of the boost converter is then used as
described in the section Alternate Methods to Drive
H Bridges. More details about the Motor Control Board are
available in Appendix 1.
Figure 27 shows the implementation of the Motor Drive
Signals block. Two PWM blocks generate the drive signals
for the two motors. Motor 1 uses a capacitive pump based
high side gate drive that requires its high side switches to
be pulse width modulated. Motor 2 uses a Boost converter
based gate drive that can modulate both high side and low
side switches.
te
switching of the FET due to noise. Depending on the
circumstances, the Control Register allows or gates the
PWM signal from reaching the Motor Control Board.
The drive signals also depend upon the Inrush_x signals.
For example, if the Inrush_1 signal goes LOW, then the
signals HS_N_1, HS_N_2, LS_N_1 and LS_N_2 signals
are turned OFF. This is required for a soft start as
described in the Over Current Block section.
Control_Reg_DIRECTION_CONTROL sets the direction.
The two outputs from the control register control the select
lines of the de-multiplexers. The de-multiplexer selects the
switches that need to be ON for each half-bridge.
Ob
Figure 27. PSoC 3 Implementation for the Motor Drive Signals Generation Block
www.cypress.com
Document No. 001-75813 Rev. *A
23
®
H Bridge Based Motor Drive Protection Using PSoC 3
Firmware Block
The preceding discussion illustrates that our example
implements the virtually the entire fault detection and
protection system in hardware. What remains is for the
Firmware block to configure the blocks as requested by
the master and to periodically monitor the status of the
system. The Firmware block also maintains the status of
the motors and runs diagnostic on them whenever
possible. Figure 28 illustrates the top level firmware flow.
Figure 28.Top Level Firmware Flow
Start
Call SPI interface
Initializer
Call System
Initializer
let
When the system detects a fault, it triggers an interrupt
which sets the fault flag and stores the fault information for
the main loop to consider later. The main loop inspects
this flag, and calls the System Locker if a fault is indicated.
A locked system does not accept most commands, unless
the master releases it through a system release
command.
MAIN LOOP
NO
Central Timer
Tick received?
YES
NO
YES
Similarly, another flag lets the main loop know of new SPI
transaction. The main loop calls the Command Processor
to process any new SPI commands. As mentioned, most
commands are not processed if the system is locked by
the System Locker.
Call System
Locker
Call Command
Processor
Ob
New SPI
command?
so
YES
Fault
Occurred?
NO
Update the inrush
current duration for the
motors
Update the
Diagnostic
schedules for the
motors
Call Diagnostic
Manager
The firmware performs three tasks before entering the
main loop:


Starts the Central Timer

Initializes all hardware with default values through the
System Initializer
Sets up the interface with the host through the SPI
Interface Initializer
The main loop runs every 1 ms on the tick of the Central
timer. Please note that the fault detection and protection
www.cypress.com
The main loop can only run every 1 ms, if the loop time is
less than 1 ms. The LCD routines associated with the user
interface may take as long as 50-60 ms to execute. In
such cases, the main loop does not run on every timer
tick. The LCD routines are not an essential part of the
system and can be disabled in firmware. These routines
are for demonstration purposes. A change in system
configuration through the SPI or a fault condition uses
these routines to visually convey the status. All the
information displayed on the LCD is otherwise available to
the master through the SPI interface. The intended mode
of operation in a practical application is without the LCD. If
the LCD is disabled, the main loop time is always less
than 1 ms for any bus clock frequency greater than or
equal to 8 MHz.
e
Initiate Central
Timer (1ms tick)
latencies are not related to this period; they are handled in
hardware and hence their responses are in all practical
sense immediate. This allows the firmware designer
greater latitude, as it removes the tight time constraints for
responses to faults. The designer may reduce or increase
the central timer frequency per application requirements.
The main loop keeps track of the inrushPeriod of each
motor (as explained in Over Current Block) with 1 ms
resolution. Based on this, the main loop handles the
switch from a soft start to normal configuration of the Over
Current block.
The main loop also maintains a schedule for running the
diagnostic sequence on each motor. There are two
conditions for a motor to be able to run a diagnostic
sequence:

There must be a pending request for a diagnostic on
the particular motor.

The motor must be inactive for a pre-specified time.
The request for diagnostic may come from the master, or
the main loop may itself put in an automatic request if the
motor has been inactive but has not been diagnosed for
some duration. The minimum duration between two
successive automatic requests for a particular motor is
called the interDiagnosticInterval of the motor.
The value of the interDiagnosticInterval is set to
2 seconds in the example project.
As the diagnostic sequence can only work with an inactive
bridge, both the half-bridges must be pulled to ground
Document No. 001-75813 Rev. *A
24
®
H Bridge Based Motor Drive Protection Using PSoC 3
The main loop keeps track of the inactive period and the
diagnostic request for each motor. In other words, it
maintains the diagnostic schedule for each motor. It calls
the Diagnostic Manager with the schedule. The Diagnostic
Manager inspects the schedule and decides whether to
run diagnostic on any motor. It handles the connection of
the motor to the Diagnostic Block, and calls the Diagnostic
APIs to run the diagnostic on the motor.
In summary, the main loop maintains the system with the
help of the Central Timer, the SPI Interface Initializer, the
System Initializer, the System Locker, the Command
Processor, and the Diagnostic Manager.
The systemLocked variable (initialized to FALSE to
indicate that no fault has been detected and hence the
system is not locked)
Once initialized, the system enters the main loop. The
main loop examines the fault status of the system and
proceeds accordingly. An interrupt, triggered by any fault,
updates the fault status as illustrated in Figure 29.
Three kinds of faults generated by the Over Current
(OC_FAULT), Fault Detect (MOTOR_FAULT) and
Diagnostic (DG_FAULT) blocks are logically OR’d to
generate the ANY_FAULT signal. This fault triggers the
Fault interrupt (isr_FAULT). The fault interrupt sets the
systemLockRequest variable to TRUE and sets the
systemLocked variable to FALSE to indicate the logging
of a request to lock but that the request is not yet serviced.
It also reads the Status Register associated with each of
the fault generation blocks and stores their values.
The main loop calls the System Locker if it finds
systemLockRequest and systemLocked to be TRUE
and FALSE respectively.
so
let
System Initializer
The main task of the System Initializer is to initialize the
half-bridges, the motor driver, over current, fault detection
and diagnostic hardware to default states. It configures the
Motor Drive Signal Generation block to keep all halfbridges disabled, and it sets their initial mode to
Diagnostic (Figure 12). It loads default direction settings
into the Control_Reg_DIRECTION_CONTROL.

e
before the sequence can start. If the motor is rotating due
to inertia even after it is turned OFF, there might be
back-emf from the motor which will prevent the bridges
from settling to ground. Therefore, a minimum off-period of
the motors is required before a diagnostic can run on the
motor. The minimum off time is set to 1 second in the
example project.
A DAC generates the threshold signal for the half-bridge
interface blocks. The System Initializer starts the DAC and
loads the default threshold into it. Next, it starts the boost
converter through the Boost_Start() API.
Ob
The System Initializer configures the Over Current, Fault
Detect, and Diagnostic blocks with default values. It then
starts and enables all of the blocks with the exception of
the Diagnostic block. It does not start the Diagnostic block
as it is not in use until a diagnostic request is set for at
least one motor.
Finally, the System Initializer initializes a set of status
variables to maintain the following information:




The number of active motors (initialized to 0)
The active motors’ inrush period (initialized to 0)
The active motors’ off period (initialized to 0)
Time elapsed since the motors last underwent
Diagnostic (initialized to 0)

Status of the motors’ diagnostic request (initialized to
0)

Whether Diagnostic is running (initialized to FALSE,
as Diagnostic is not started)

The motor currently being diagnosed (initialized to one
more than the number of motors in the system, i.e. a
non-existing motor, to indicate that none of the motors
in the system are being diagnosed at the moment)
www.cypress.com
System Locker
Like the System Initializer, the System Locker brings the
system to a deactivated state. It disables all half-bridges
and sets their mode to Diagnostic. It then stops the Over
Current, Fault Detect and Diagnostic blocks as well as the
PWMs in the motor driver blocks. Unlike the System
Initializer, the System Locker does not load default
parameter values into the blocks, as the host may have
configured them in the course of operation with values
appropriate for the application. The System Locker
ascertains the source of the fault by checking the variables
written by the fault interrupt. It then updates the SPI
interface appropriately.
Similar to the System Initializer, the System Locker resets
the status variables with one important exception. If the
source of the fault is the Over Current or the Fault Detect
block, then the faulty motor must undergo a diagnostic. A
request for a diagnostic sequence is set for the faulty
motor, and any pre-existing request for any other motor is
ignored and deleted. In this way, the faulty motor has
priority above other motors. Nevertheless, it would still
have to stay OFF for the minimum amount of time
specified before the sequence can start.
A variable keeps count of consecutive calls to the System
Locker. Two calls to the System Locker are consecutive if
Figure 29. Fault Interrupt
Document No. 001-75813 Rev. *A
25
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 14. Motor Commands and the Associated Actions
Motor Command
Start/Stop
Actions Performed
For each motor:
The associated half-bridges are determined.
If the motor is under diagnostic, and it needs to be started then diagnostic is aborted. A variable is set to 0 indicating
that Diagnostic cannot be run on the motor.
If the motor needs to be started, then the inrushState variable for the motor is set to TRUE, indicating that it will
exhibit inrush current for some time. The Over Current block in charge of that motor is configured for soft start. A
variable is set to indicate that the particular motor is active.
The direction is set as requested. Then the half bridges are enabled or disabled as per the start/stop request.
For each motor:
1.
2.
Change Speed
A change in direction is not allowed on an active motor. For all active motors, the direction is kept unchanged,
regardless of the requested direction.
For all inactive motors, the direction is set as requested.
For each motor that needs speed change:
1.
2.
Ob
so
let
3.
It is determined whether speed needs to be increased or decreased.
If increase is requested, and motor is already not at maximum speed, the new duty-cycle is calculated by
adding a predetermined value to the current duty cycle. If this duty cycle is less than the maximum allowed
duty cycle, then the current duty cycle is updated with the new duty cycle; otherwise the current duty cycle is
updated with the maximum allowed duty cycle.
If reduction in speed is required, and motor is already not at minimum speed, the new duty-cycle is calculated
by subtracting a predetermined value from the current duty cycle. If this duty cycle is greater than the minimum
allowed duty cycle, then the current duty cycle is updated with the new duty cycle; otherwise the current duty
cycle is updated with the minimum allowed duty cycle.
e
Set Direction
the system has not been released from lock condition
between the two calls. The main loop uses this variable to
know the number of times a faulty motor’s diagnostic
request is set. If a faulty motor has already been
diagnosed, but the master has not released the system,
then the diagnostic system is turned off till further
intervention by the master. This ensures that we do not
unnecessarily run a diagnostic on a bridge known to be
faulty.
After exiting the System Locker, the main loop checks if a
new command is available and calls the Command
Processor to process the new command.
Command Processor
The Command Processor identifies and executes all the
SPI commands from the master. We divide the commands
c into two main categories based on their end result:

Motor Commands: Used to change the state
(ON/OFF), direction, and speed of motors.

Configuration Commands: Used to alter the system
configuration but not affect the motors such as to
change over current thresholds and blanking times,
send a diagnostic request, or to release the system
from a lock condition.
Changing the direction of a spinning motor can result in
heavy current. This is more likely with a heavy motor
running at high speed. Therefore, the example project
does not allow change in direction of an active motor.
The configuration commands call the respective APIs of
the Over Current, Fault Detect or Diagnostic blocks. They
check if the requested parameter value is within the
www.cypress.com
allowed range. If the value is outside range then it is
replaced by the closest allowable value.
The Diagnostic Request command sets the diagnostic
request variable for the particular motor to true.
A noteworthy configuration command is the System
Release command, which brings out the system from
locked condition. If the correct code is provided with the
command, then the System Release command is
executed. The System Release command restarts the
Motor Drive PWMs, and clears all existing fault status and
associated variables. It configures the Over Current, Fault
Detect and Diagnostic blocks similar to the System
Initializer.
If the system is locked then all commands, except the
Diagnostic Request and the System Release are ignored.
Also, though not specifically mentioned, all commands
update the SPI interface with the latest results from the
commands’ execution. This ensures that the master
receives updated values on reading a status.
Central Timer
The Command Processor, System Initializer and System
Locker set a group of variables to indicate the start of
certain periods (e.g. inrush current, motor-off and so on).
The Central Timer updates these variables. It updates
certain flags and variables every 1 ms to enable the
acquisition of the following information:


Whether or not the main loop can be run.
If any motor is outside its inrush current state and its
Over Current system can be switched to normal
configuration from a soft start configuration.
Document No. 001-75813 Rev. *A
26
®
H Bridge Based Motor Drive Protection Using PSoC 3

The elapsed time since a motor has undergone a
diagnostic sequence.

The elapsed time since a motor has gone from the
active to inactive state.
The system uses a hardware timer and interrupt to
implement the Central Timer as shown in Figure 30. It
uses a 16-bit, fixed function Timer block. A 1 MHz clock
drives the Timer with its period set to 1000. It reaches its
terminal count once every 1 ms and triggers the TimerTick
interrupt which:

When the motor is in inrush current state, increments
by 1 the timeSpentInInrushState variable. When
the variable value equals the inrushPeriod of the
motor, we can safely assume that the motor is
operating with normal current levels and switch its
Over Current unit from Soft Start to Normal mode.
When the motor is inactive, increments by 1 the
motorInactivePeriod variable. When the value of
the variable value equals the minimum off-period
required for diagnostic, it adds the motor to the list of
motors allowed to be diagnosed. Also, if the motor is
inactive, then it increments by 1 the
interDiagnosticInterval variable. If this interval
exceeds the default Diagnostic Interval of the system,
then an automatic request for a diagnostic sequence
of the motor is set. The Diagnostic Manager only
diagnoses a motor if it is on the list of allowable
motors, and there is a request for a diagnostic on the
motor.
Diagnostic Manager
The Diagnostic Manager diagnoses the motors. It checks
if a Diagnostic sequence is already in process, and then it
starts a diagnostic on an appropriate motor. When a
diagnostic
sequence
completes,
it
sets
the
interDiagnosticInterval variable of that motor to 0
to indicate that the motor has just completed a diagnostic.
so
let
e

Sets a flag to let the main loop know that 1 ms has
elapsed since last iteration of the main loop.

Ob
Figure 31. Routing for a Diagnostic System
Figure 30. Implementation of the Central Timer
It calls the APIs provided by the Diagnostic block to handle
the request. The system generally consists of multiple
motors and a single diagnostic system. Therefore, the
Diagnostic Manager also needs to set up the routing
between the Diagnostic block and the intended motor. In
Figure 31 we show the hardware setup for routing.
The motor selection register Control_Reg_MS determines
the routing. The LSB of the register acts as the select line
of the multiplexers and de-multiplexers which delegate the
www.cypress.com
Document No. 001-75813 Rev. *A
27
®
H Bridge Based Motor Drive Protection Using PSoC 3
The Control_Reg_MS further controls the ENABLE_D
signals of all the half-bridge interface blocks. The
Diagnostic Manager writes the appropriate value to the
control register to turn on the appropriate ENABLE_D
signals HIGH.
To summarize the actions of the Firmware block:


The main loop runs every 1 ms.

When a fault occurs, the System Locker locks the
system.
The System Initializer initializes the system with
default values.
The Command Processor handles commands from
the master to run the motors and to configure the
entire system.

The Central Timer maintains several variables
representing time between different events.
The Diagnostic Manager runs diagnostic on a
particular motor.
Read the Fault Status
Release the system after it locks up due to a fault
The above tasks can be partitioned into write and read
commands. A write command intends a change in the
behavior of the system. A read command observes an
existing configuration without changing it. After a write
command, the host may use a read command to verify
that the correct execution of the write command.
The current implementation uses a register map for
commands and their responses. The register map has two
sections: WRITE and READ. The WRITE section accepts
write commands from the host, while the READ section
stores the existing configuration for the host to read.
Figure 32 illustrates the register map. After executing a
write command, the system appropriately updates the
read portion to reflect that change.
Each
byte
in
the
register
All changes to the motor and the system are
communicated to the master by updating the SPI
interface. The LCD, if enabled, also conveys this
information. When a fault occurs, a digital signal is turned
ON as an indicator to the master. This ensures that the
master knows about the occurrence of a fault immediately,
as opposed to later through the SPI interface. In the
example project, we also connect an LED to this signal for
a visual detection of a fault condition.
User Interface
map
contains
specific
Figure 32. Description of SPI Register Map for a System
with M Motors
WRITE
State of All Motors
BYTE 0
Direction of All Motors
BYTE 1
Speed Change Request for All Motors
BYTE 2
Speed Increment/Decrement
BYTE 3
Over Current Threshold for Unit 1
BYTE 4
Ob
so

Start a diagnostic on a particular motor
let




e
signals to and from the Diagnostic block. The Diagnostic
Signal Generation block generates the DIAG_HS_x and
DIAG_LS_x signals (Figure 26). They are routed to the
correct Half-Bridge interface block based on the LSB. The
LSB also determines which half-bridge signals should be
used as the MTL and MTR (in Figure 26,
DIAG_BRIDGE_1 and DIAG_BRIDGE_2).
Over Current Threshold for Unit M
BYTE M+3
Over Current Blanking Time for Unit 1
BYTE M+4
Over Current Blanking Time for Unit M
BYTE 2M+3
Fault Detect Blanking Time for Motor 1
BYTE 2M+4
Fault Detect Blanking Time for Motor M
BYTE 3M+3
Diagnostic Blanking Time
BYTE 3M+4
The User Interface block allows a user and/or a host to
configure and communicate with the system. An LCD and
an LED enable visual communication, whereas a SPI
interface provides a link for a SPI master. The visual
interface is not necessary for the operation of the system;
we include it for demonstration purposes only.
BYTE 3M+5
RESERVED
BYTE 3M+6
Request for Diagnostic
BYTE 3M+7
Release System
BYTE 3M+8
BYTE 127
READ
SPI Communication
BYTE 128
The host device controls the H bridge protection and
diagnostic through a SPI interface. The interface is used
to:

Configure and verify parameters relevant to the
protection and diagnostic system

Control the states of the motors
www.cypress.com
Same as BYTE 0 through
BYTE 3M+4
BYTE 3M+132
Bridge Fault Status
BYTE 3M+133
Over Current Fault Status
BYTE 3M+134
Verification of Communication
Document No. 001-75813 Rev. *A
BYTE 0xDE
28
®
H Bridge Based Motor Drive Protection Using PSoC 3
information. Figure 32 shows how the system interprets
each byte meant for M motors. The system should have at
least one motor (i.e. M must be ≥1).
Table 15. SPI Register Map for a Two Motor System
Byte
Number
0x00
State of all motors (ON/OFF)
0x01
Direction of all motors (CW/CCW)
0x02
Speed Change Request for all motors
(Change/Do not Change)
0x03
Change of speed (positive/negative)
0x04
Over Current Threshold for Unit 1
0x05
Over Current Threshold for Unit 2
0x06
Over Current Blanking Time for Unit 1
0x07
Over Current Blanking Time for Unit 2
0x08
Fault Detect Blanking Time for Motor 1
0x09
Fault Detect Blanking Time for Motor 2
0x0A
Diagnostic Blanking Time
0x0D
Motor ID with Diagnostic Request
0x0E
Release code required after System Lock
0x8B
Bridge Fault Status
0x8C
Over Current Fault Status
0xDE
Communication Confirmation Byte
so
let
The next M bytes (BYTE 2M+4 through BYTE 3M+3) store
the Fault Detection Blanking Time information, while BYTE
3M+4 stores the Diagnostic Blanking Time. The Diagnostic
Blanking time is a system parameter and applies to all
motors. The next two bytes are reserved, while BYTE
3M+7 holds the Diagnostic request for a particular motor.
When the system locks up, most of the write commands
are disabled. The host needs to write the correct byte (the
System Release Code) into the BYTE 3M+8 to release the
system from lock. This is the last significant byte in the
WRITE portion of the register map.
Significance
e
The first two bytes in the register map (BYTE 0 and BYTE
1) contain information about the state of the motors
(whether they are ON or OFF) and the direction of rotation
(clockwise/counter clockwise). The third byte (BYTE 2)
implies whether the speed for a motor needs to change,
and the fourth byte (BYTE 3) implies how the speed needs
to change (increase or decrease). The next M bytes
(BYTE 4 through BYTE M+3) are the Over Current
thresholds for the M Over Current Detection Units. As
previously discussed, all systems with M motors need not
have M over current detection units. In such cases, the
user may modify the register map accordingly. Similarly,
the following M bytes (BYTE M+4 through 2M+3) contain
the Over Current Blanking Time information for each Over
Current unit.
Ob
The READ portion of the register map stores the same
information in the WRITE portion. However, it is not a copy
of the WRITE portion. The system updates the information
in the READ portion only after the system has been
configured according to the commands in the WRITE
portion. The system also reports the H bridge fault
information and the Over Current fault information in BYTE
3M+133 and BYTE 3M+134 respectively. BYTE 252 (or
0XDE) can hold one of two possible bytes; (0xAA) and its
complement 0x55. These two bytes are used to verify that:

The communication link between the master and the
system is intact

The main loop is running
When the master reads this location, the main loop
toggles the value at this location. On two successive reads
of this location (in two different transactions), the master
should receive 0xAA (0x55) and 0x55 (0xAA).
In this application note, we manage two motors.
Therefore, the register map used in this application note
can be derived from Figure 32 using M=2. Figure 34
illustrates the SPI transaction. For each byte sent by the
master a corresponding byte is received. The first received
byte is not dependent on the first transmitted byte of the
current command and can be treated as garbage; in fact, it
is dependent on the last sent byte of the previous
command. The first byte received after a system reset is
always 0x55. All other subsequent received bytes are
strictly dependent on the bytes transmitted by the master.
Table 15 shows the WRITE portion of this register map.
Figure 34 illustrates the SPI transaction. For each byte
sent by the master a corresponding byte is received. The
first received byte is not dependent on the first transmitted
byte of the current command and can be treated as
garbage; in fact, it is dependent on the last sent byte of the
previous command. The first byte received after a system
reset is always 0x55. All other subsequent received bytes
are strictly dependent on the bytes transmitted by the
master.
The figure shows that the received byte is actually the
information at location pointed to by the preceding sent
byte. Therefore, if the master wants to receive the
information at location L in the n+1-th received byte, the
n-th byte it should transmit must be L. For example, in
order to read the Over Current Threshold for Over Current
detection Unit 1, the master should send 0x84 followed by
Figure 33. Illustration of SPI Transaction
BYTES FROM
MASTER
ADDR 0
ADDR 1
BYTES FROM
SLAVE
GARBAGE
BYTE[ADDR 0]
www.cypress.com
ADDR N-2
BYTE[ADDR 1]
Document No. 001-75813 Rev. *A
ADDR N-1
ADDR N
BYTE[ADDR N-2]
BYTE[ADDR N-1]
29
®
H Bridge Based Motor Drive Protection Using PSoC 3
Table 16. Write Commands and Their Parameters
# of
Parameters
Description of Parameter
0x00
1
Intended motor state (ON/OFF)
0x01
1
Intended motor direction (CW/CC).
0x02
2
Intended speed change
(Increase/Decrease)
0x03
N/A
Invalid Command
0x04 - 0x0A
1
The respective parameters (e.g.
OC Threshold) intended to be set.
0x0D
1
Motor requiring a diagnostic
0x0E
1
Release code
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
MOTOR MOTOR
2
1
1=YES 1=YES
0=NO
0=NO
BYTE 2: MOTOR SPEED CHANGE REQUEST
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
MOTOR MOTOR
2
1
1= INC 1=INC
0=DEC 0=DEC
BYTE 3: MOTOR SPEED CHANGE TYPE (INC = INCREASE,
DEC = DECREASE)
Figure 34. Description of the MOTOR STATE Register
any other byte. The two bytes it would receive would be
garbage, and the Over Current Threshold respectively.
The above description applies to all commands, whether
read or write. If the first received byte is less than 128, it is
a write command. It is interpreted as follows:

The subsequent bytes are parameters for the
command. They are written into consecutive locations
of the register map, starting from location X.
NOT
USED
NOT
USED
NOT
USED
NOT
USED
For example if the command transmitted from the master
is 0x04 0xAB, then the byte 0xAB will be written into the
location 0x04.
Ob
The received bytes are meaningful only for read
commands, as the actual system status can be inferred
from those bytes. Received bytes for write commands
bear little significance.
Each write command has at least one parameter following
the command. Some commands require more than one
parameter. To avoid errors, the master must ensure that it
sends the correct number of parameters with each write
command. Table 16 shows the number and description of
parameters associated with each write command.
The first byte in the register map controls the motor states.
Figure 34 shows how the information is encoded into the
bytes. The bit positions identify the motors, while the bit
value (1/0) determines the state (ON/OFF). For example if
BYTE 0 contains 0x03 it means that both motors 1 and 2
should be ON.
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
MOTOR MOTOR
2
1
1 = ON 1 = ON
0 = OFF 0 = OFF
BYTE 0: MOTOR STATE
Similarly, the second byte in the register map stores the
direction information. This is shown in Figure 35.
so
le

The first byte is the address of the location to start
writing. Let the first received byte be X.
NOT
USED
NOT
USED
te
Write
Command
Figure 36. Description of MOTOR SPEED CHANGE
REQUEST and TYPE Registers
Figure 35. Description of the MOTOR DIRECTION
Register
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
MOTOR MOTOR
2
1
1=CW
1=CW
0=CCW 0=CCW
BYTE 1: MOTOR DIRECTION
The next two bytes, used for changing the speed of the
motors, follow similar encoding scheme. This is shown in
Figure 36.
For example, if the speed of Motor 1 must increase and
the speed of Motor 2 decrease, the master should transmit
the command 0x02 0x03 0x01. If any bit in the MOTOR
SPEED CHANGE REQUEST register is 0, then the
system ignores the corresponding bit in the MOTOR
SPEED CHANGE TYPE register.
Our example application uses two motors, so we do not
use the other bits in the register. They can be used when
more motors are added to the system.
No special encoding is required for BYTE 3 through BYTE
A. The value of the particular parameter is directly written
into the byte.
The Diagnostic request byte follows the same encoding as
the Motor State byte. The bit positions identify the motors,
and the bit value determine the request (1 = Diagnostic
Request, 0= No Diagnostic Request). At any instant, only
motor can have a Diagnostic request, so no more than
one bit can be 1 at a time.
www.cypress.com
Document No. 001-75813 Rev. *A
30
®
H Bridge Based Motor Drive Protection Using PSoC 3

Communication: It consists of the SPI Slave
component.

Data Transfer: This manages the transfer of data
between the register map and the SPI Slave
Component.

Book Keeping: This signals the firmware block about
a recently completed SPI transaction. It also
reconfigures the Data Transfer system for the next
SPI transaction.
The slave must process the current byte from the master
to load the correct byte into the TX register before the start
of the next byte. The minimum processing delay
determines the inter-byte time. The Direct Memory Access
(DMA) functionality available in PSoC 3 allows us to
minimize the inter-byte time. The complete data transfer is
carried out without any CPU involvement. This allows SPI
transaction without interrupting the CPU.
We use two DMA channels for the implementation. Each
channel consists of one or more Transaction Descriptors
(TDs). Each TD is characterized by:




Source address
Destination address
Number of Bytes
Next TD
For detailed information on the DMA components and how
to configure them, we recommend that you consult the
DMA component datasheet available in PSoC Creator and
the application note AN52705.
so
let
The SPI Slave is a Creator component and synthesized in
the UDB. Detailed information about the block and ways to
configure it are in the component datasheet in
PSoC Creator. It operates in mode 0 with a bit rate of
4 Mbps and a MSB first manner. The Receive and
Transmit Buffer sizes are both set to 4. The component is
also configured to generate an interrupt signal at the end
of each byte complete. This signal triggers the Data
Transfer block to execute the required transfers.
These transfers execute regardless of the type of
transaction (READ or WRITE).
e
Implementation of the SPI Interface
This project uses the SPI Slave component available in
PSoC Creator and some additional resources to
implement the SPI interface as shown in Figure 37. The
implementation consists of three parts:
The Data Transfer portion is responsible for two major
tasks:
Transfer the transmitted byte from the SPI slave RX
register (receive register) into a temporary location
called scratchpad in the main memory.

Transfer the correct data from the register map into
the SPI slave TX register (transmit register), so that
the behavior described in Figure 33 can be
guaranteed.
Ob

Figure 38 shows how the DMA channels and their TDs
can seamlessly carry out the data transfer between the
SPI slave component and the main memory.
Figure 37. PSoC Creator Implementation of the SPI Interface
www.cypress.com
Document No. 001-75813 Rev. *A
31
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 38. Configuration of DMA Channels and Transaction
Descriptors
Channel 1
SOURCE
DESTINATION
Clear BYTE COMPLETE
Interrupt
TD 0
TX Status Reg
ClearInterrupt
TD 1
RX Reg
TD 2 Source Offset
TD 2
Register Map
TX Reg
Channel 2
TD 3
SOURCE
TD 2 Source Offset
Set Up TD 2 source
address
Transfer from Register
Map to TX register
DESTINATION
Scratchpad
Transfer from RX Register
to ScratchPad
Step 1: When one byte transmission is complete, the
BYTE COMPLETE bit in the TX status register turns
HIGH which triggers the Channel 1 to start its first TD
(TD 0). The TX status register is “sticky”; thus the
BYTE COMPLETE bit stays HIGH, disabling the
detection of subsequent interrupts. The TD 0 reads
the register to clear this bit. It writes the content of the
register to the variable clearInterrupt. TD 0
triggers TD 1 as its next TD.
Step 2: The byte from the master is available in the
RX Register. TD 1 moves this byte from the RX
Register into the offset portion of the source address
register of TD 2. The TD 2 source address register
base is pre-filled with the base address of the register
map. Therefore, the source of the TD 2 now becomes
the register map location pointed to by the received
byte. For example if the received byte is 0x05, then
TD 2’s source is now the data at location 0x05 (i.e.
BYTE 05). With TD 2 thus configured, it is triggered
by TD 1.
Ob

The source address of a TD is a 16-bit value. The
least significant byte is the offset, and the most
significant byte is the base. In this project, the define
REGISTER_MAP_STARTING_ADDRESS contains the
base address.

The master pulls the slave-select line high when a
transaction is complete. This event triggers the
SPI_DONE interrupt service routine to perform the
necessary book keeping activities which consist of:

Set a flag to indicate availability of new data from
master

Set a flag to indicate that the new data has not yet
been processed

Reinitialize the TD 3 destination address to point to
scratchpad[0]
Remember that the main loop runs every 1 ms during
which the system processes all received write command.
Therefore, allow a minimum time of 1 ms between two
consecutive SPI transactions.
so

Data transfers without CPU intervention achieve very
small inter-byte times. A minimum 8 MHz master clock
frequency is needed to support a 4 Mbps SPI interface.
The corresponding inter-byte time is 5 µs. For a typical
master clock frequency of 48 MHz, the inter-byte time is
less than 1 µs.
let
e
Channel 1 consists of 3 transaction descriptions which
work in sequence:
Before any new transaction starts, the destination of TD 3
is set to the first location in the scratchpad
(scratchpad[0]). After every byte transfer in a
transaction, the destination address is incremented so that
the bytes do not get over-written.
Step 3: TD 2 transfers the byte from the register map
to the TX register of the SPI slave component. The
master receives the byte during the next byte transfer.
Once TD 2 completes, it sets the termination signal
which starts Channel 2.
Channel 2 has only one TD, which transfers the received
byte into the scratchpad. We recall that the received
byte has been transferred into the offset portion of the
TD 2 source address register in Step 2. The scratchpad
is an array in the main memory where received bytes are
collected for processing. Only a write command requires
the received bytes to be processed; a read command is
handled by the DMA channels.
www.cypress.com
The system does not count the received bytes to verify
correctness of a transfer. The master must follow Table 16
while sending write commands, or there may be lost
commands and erroneous behavior.
External 10K resistors pull up the Slave Select (SS), SCLK
and MOSI lines to the supply voltage (VDD). There is a
capacitor on the SS line to prevent a spike on the line due
to electromagnetic interference from the motor. The
resistor and capacitor values can be changed to support
different bit rates. The resistors may be eliminated if the
master has its own pull up resistors.
A part of the firmware called the SPI Interface Handler
sets up the initial Register Map, populates it with default
values, and sets up the DMA transactions. It also
constructs the commands and parameters from the
received bytes. The SPI Interface Handler consists of two
parts: the SPI Interface Initializer and the SPI Command
Constructor.
The SPI Interface Initializer performs the following tasks:

Initializes the READ and WRITE portions of the
Register Map with default values

Sets up the DMA channels and TDs for the data
transfer and enables them
The SPI Command Constructor extracts the command
information from the received bytes in the Scratchpad.
The SPI_DONE interrupt (Figure 37) sets a flag to indicate
completion of a new SPI transaction. Accordingly, the
Document No. 001-75813 Rev. *A
32
®
H Bridge Based Motor Drive Protection Using PSoC 3
Command Constructor reads the scratchpad. It
interprets the first byte (scratchpad[0]) as the
command and calculates the required number of
parameters based on Table 16. It reads these parameters
from successive locations of the scratchpad
(scratchpad[1], scratchpad[2],…). Finally, it
updates the write portion of the Register Map with the
parameters for later use by the Command Processor.
LED Interface
The LED provides a visual indication of a faulty state. A
digital signal controls the state of the LED. The same
signal should connect to the master to communicate a
fault condition. In the application project, the signal only
connects to the LED. You may connect the signal to the
master as needed.
Figure 40 shows the PSoC 3 implementation of the LED
interface. The flip-flop is set on the occurrence of any fault
which turns Pin_FAULT to HIGH. Pin_FAULT connects to
the LED which turns ON. When the master sends the
system release command, Control_Reg_FAULT_RESET
resets the flip-flop to 0.
LCD Interface
so
le
Figure 39. Character LCD Component
Figure 40.Implementation of the LED Interface
te
As already mentioned, we use the LCD interface purely for
demonstration purposes in this project. The information
visible on the LCD is also available through the SPI
interface. You can disable the LCD functionality in
firmware by setting the define LCD_ENABLED to 0 in the
file configuration.h. The project uses standard LCD
module available on CY8CKIT-001/CY8CKIT-030 along
with the PSoC Creator Character LCD component. The
LCD has two rows, each of which can display 16 ASCII
characters as shown in Figure 39.
Ob
Table 17 shows a list of all the information displayed
during the course of the application. The Demonstration
section shows these in more details.
Table 17. Description of LCD display for different system status
System Status
Startup
Motor Start/Stop
Motor Direction Set
LCD Display
When the System is powered on correctly, displays the introductory startup message.
Displays the Motors IDs, their states (ON/OFF), their direction settings, and the speed settings.
Same as Motor Start/Stop.
Motor Speed Change
Same as Motor Start/Stop.
Over Current/Bridge
Fault
On detection of an over current or bridge fault, displays the Motor IDs, associated H bridge status (faulty/ok) and
over current status (faulty/ok).
Diagnostic Fault
Appears only if the Diagnostic block detects a fault and then it displays the Motor ID, bridge status, over current
status and the fault detected.
Change Parameter
Displays the Motor ID (if applicable), the parameter name, and the new parameter value
System Locked
Appears only when the system is in locked condition following a fault and the master sends a motor or
configuration command.
System Released
Displays status when the master sends the correct system release command and code, to release the system
following a lock condition.
www.cypress.com
Document No. 001-75813 Rev. *A
33
®
H Bridge Based Motor Drive Protection Using PSoC 3
connects to the USB terminal on the computer and to the
SPI pins on the PSoC 3. We use the Aardvark I2C/SPI
ControlCenter software to communicate with the USB to
I2C/SPI adapter. You can download the software at
http://www.totalphase.com/products/control_center/
Demonstration with CY8CKIT-001
PSoC Kit with PSoC 3 Processor
Module, and Motor Control Board
In this section, we demonstrate use of the application,
using the CY8CKIT-001 development kit and the Motor
Control Board. The Motor Control Board houses the FETs
required to drive the motors, the associated gate drive
electronics, the boost converter, and a few other
components. Refer to the Appendix for details about the
Motor Control Board as well as a corresponding setup with
the CY8CKIT-030 kit.
Plug the Motor Control board into the Port A of the
CY8CKIT-001 development kit. The settings for kit and
board are as follows:






Demonstration Setup
External equipment used for the demonstration includes:
Power Supply (0-15 V, 0-3 A)

Buehler Motor (6 V-24 V DC), 0.5 A, 6.3 W, 3000 rpm
(Motor 2)



Aardvark USB to I2C/SPI host adapter
Computer with USB port
J8 set to VREG
All VDDIO jumpers (J2, J3, J4, and J5) set to VDD
J12 (LCD Power) set to ON
Motor Control Board



J2 and J4 are in place (connected)
J3 and J6 are in place (connected)
J5 is set to Vin1
Figure 44.
The grounds of the Motor Control Board and the kit must
connect externally as they do not connected through Port
A. Use the following sequence to connect and power up
the board and kit. Verify that power is removed from both
the CY8CKIT-001 dev kit and the motor control board.
so
Cables and wires for connection

J6 and J7 set to VDD
let
Dayton Motor, 12 V DC, 3.8 A, 21.4 W, 2350 rpm
(Motor 1)
VDD SELECT set to 3.3 V
e


CY8CKIT-001
The CY8CKIT-001 comes with an embedded whiteboard
prototype area for easy development. We use this
prototype area for the SPI bus setup and the connection to
the LED. Figure 41 shows the whiteboard connections.
Ob
VBUS
5V
GND
3.3V
GND
VADJ
Figure 41. CY8CKIT-001 Prototype Area Connection
VCC
P0_0
P0_1
P0_2
P0_3
P0_4
P0_5
1.
Plug the Motor Control Board into Port A of the
development kit. Connect the grounds externally.
2.
Power up the kit.
3.
Program the PSoC 3 device on the processor module
connected to the kit with the associated project.
4.
Power up the Motor Control Board.
If the motor control board is powered before the device is
programmed, it may result in heavy current being drawn
from the power supply. The motors used for demonstration
purposes are shown in Figure 42 with an inch scale added
for perspective.
P0_6
P0_7
10K
10K
10K
P1_0
P1_1
P1_2 Pin_FAULT
P1_3
P1_4 MOSI
P1_5 MISO
P1_6 SCLK
P1_7 SS
VADJ
3.3V
GND
GND
LED4
LED3
LED2
5V
SW2
LED1
VR
470pF
Ceramic
SW1
P2_7
We chose two different motors with large difference in
output power to demonstrate the easy configurability of the
system under a wide variety of loads. The computer acts
2
as the master. The Aardvark USB to I C/SPI adapter
www.cypress.com
Document No. 001-75813 Rev. *A
34
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 42. Motors Used for Demonstration
Demonstration of Operation
For the demonstration, we show how to start and stop the
motors, change their speed, and change a few
configuration parameters. Then, we show the response of
the system to faults.
We use the Aardvark Control Center software to send all
the commands to the system. Configure the adapter for a
SPI+GPIO configuration. Figure 43 shows the Control
Center software user interface.
Ob
so
let
e
Figure 43. Setup of the Control Center GUI
www.cypress.com
Document No. 001-75813 Rev. *A
35
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 44. Complete Setup of CY8CKIT-001 for Project
Connect Board and
Dev Kit Ground
To Motor 2
To Power Supply
To 9V Wall Wart
LCD Welcome
Message
Prototyping Area
Motor Control
Board
Fault LED
so
le
Processor Module
with PSoC3
After setting up the SPI Interface, reset the system to
prevent the effect of any spurious signals on the SPI bus
during setup. After reset, the LCD displays the status
shown in Figure 45.
M O T O R
Ob
Figure 45.System Startup Message
D R I V E
P R O T E C T I O N
At the start of operation, the first four bytes of the SPI
Register map are:




BYTE 0 = 00: All motors are off.

BYTE 2 = 00: No motors need speed change.
BYTE 3 = 00. Default Speed change, if needed, is
negative.
Transmitted Bytes 01 02: Set the direction of Motor 1
to CW and Motor 2 to CC.
www.cypress.com
Aardvark USB to
I2C/SPI Adapter
Received Bytes 55 00: The SPI TX register is loaded
with the value 55 at the time of setup. This is always
the first byte received for any command after system
reset The 00 was the initial value in the BYTE 1 of the
Register Map, which indicates that the default
direction for both motors is clockwise.
After this command, the first four bytes of the Register
Map are:




BYTE 1 = 00: Both motors’ direction set to CW.
Next, use the Aardvark Control Center Software to send
the command 01 02 to set the direction of Motor 1 to CW
and Motor 2 to CC.

te
To Motor 1
BYTE 0 = 00: All motors are off.
BYTE 1 = 02: Motor 1 CW, Motor 2 CC.
BYTE 2 = 00: No motors need speed change.
BYTE 3 = 00. Default Speed change, if needed, is
negative.
Next, we send a command to turn ON Motor 1.

Transmitted Bytes 00 01: Make Motor 1 state ON and
Motor 2 state OFF.

Received Bytes 00 00: The first 00 is the value
pointed to by the last transmitted byte of the previous
command (see SPI Communication, Page 34) i.e.
BYTE 2 (last command sent was 01 02). The second
00 comes from the byte pointed to by 00 i.e. BYTE 0.
After this command, the first four bytes of the Register
Map are:
Document No. 001-75813 Rev. *A
36
®
H Bridge Based Motor Drive Protection Using PSoC 3




BYTE 0 = 01: Motor 1 ON, Motor 2 OFF.
The LCD displays the status as shown in Figure 47.
BYTE 1 = 02: Motor 1 CW, Motor 2 CC.
Figure 47. LCD Display After Speed Change Command
BYTE 2 = 00: No motors need speed change.
Motor Id
BYTE 3 = 00. Default Speed change, if needed, is
negative.
Motor 1 turns on. The LCD displays the status as shown in
Figure 46.
Direction
M 1
O N
C W
5 5
M 2
O F F
C C
4 5
Figure 46. Motor Status Direction and Speed
Motor Speed
Motor State
Motor Id
Direction
C W
5 0
M 2
O F F
C C
5 0
Motor State
We demonstrate the change of parameter through SPI
and change the OverCurrent Threshold for Motor. First,
We read the default value.
Motor Speed
e
O N

Transmitted Bytes 84 80: Read location 84. The
second byte is a dummy used to extract the BYTE
132 (0x84 = 132).

Received Bytes 02 82: 02 comes from last transmitted
command and is ignored. 0x82 is the Over Current
threshold for Motor 1, i.e. 130.
let
M 1
In the next few commands, we no longer explain the
significance of the received bytes unless necessary. Refer
to Figure 32 for more information.
so
The Motor Speed parameter shows the ON times of the
PWM that drives the motors. The default ON time is set to
50 clock cycles (with the period being 100 clock cycles).
With each speed change request, the ON time increases
or decreases by 5 clock cycles, depending on the type of
request.
Next, we send a command to modify the threshold to 140.

Transmitted Bytes 04 8C: Write 140 (0x8C) into
location 04 (OC_Threshold of Motor 1).

Transmitted Bytes 02 03 01: Make Motor 1 state ON
and Motor 2 state OFF.


Received Bytes 02 00 00: The 02 comes from the
byte pointed to by the last transmitted byte of the
previous command i.e. BYTE 1. The first 00 (second
received byte) comes from the byte pointed to by the
first transmitted byte (02), i.e. BYTE 2, and the second
00 (third received byte) comes from the byte pointed
to by the second transmitted byte of the current
command, i.e. BYTE 3.
Received Bytes 01 82: 01 comes from last byte of
previous transmitted command (80) and is ignored.
0x82 was the value in BYTE 4, the default Over
Current threshold for Motor 1, as verified by previous
read command.
Ob
Next, we send a speed setting command to increase the
duty cycle of Motor 1 and reduce the duty cycle of Motor 2.
The command is 02 03 01.
Figure 48 shows the LCD display resulting from the
change of the OC_Threshold for Motor 1.
Figure 48. LCD Display After Change of OC_Threshold for
Motor 1
After this command the first three bytes of the Register
Map are:




BYTE 0 = 01: Motor 1 ON, Motor 2 OFF.
Motor Id
M O T O R
BYTE 1 = 02: Motor 1 CW, Motor 2 CC.
2
O C _ T H R S
8 C
BYTE 2 = 03: Both motors need speed change.
BYTE 3 = 01. Motor 1 needs speed increase and
Motor 2 needs speed decrease.
www.cypress.com
Parameter Name
Parameter Value
The same display format applies to all other parameters
applicable to the motors such as Over Current blanking
times (OC_BLNK) and Fault Detect blanking times
(FD_BLNK). The Diagnostic blanking time is not particular
to any motor. When we change the Diagnostic blanking
Document No. 001-75813 Rev. *A
37
®
H Bridge Based Motor Drive Protection Using PSoC 3
time, the LCD replaces the Motor ID with the text
DIAGNOSTIC and the parameter name BLNK_TM. The
parameter values are as set by the user.
block does not report a fault. The fault status is available
in the Register Map at BYTE 3M+133 and BYTE 3M+134.
Figure 51 shows how to interpret fault status bytes.
Next, we demonstrate the Fault Detection. Figure 49 and
Table 18 explain the faults and how we create the fault
conditions. We explain the respective observations: the
LCD messages, the LED and the Register Map contents.
Figure 50. LCD Display for Over Current Fault on Motor 1
Motor Id
Table 18. Demonstration of Faults and Methods to Create
the Fault Conditions
Fault
1
Description
Motor 1 Over
Current
Method to Create Fault
Condition
4
Run Motor 2 in CW direction.
Short MT2_1 to ground with a wire
connected to ground. Retain the
short for 3 seconds.
Motor 2 is
Open
Keep Motor 2 stopped. Motor 1
may be stopped or running.
Disconnect Motor 2.
MT2_2
NOT
USED
MOTOR MOTOR
1
2
NOT
USED
1 = FL
0 = OK
NOT
USED
NOT
USED
MT2_1
Motor 2
Suuply
MT2
MOTOR CONTROL BOARD REPRESENTATIVE VIEW
(NOT TO SCALE)
Motor 1
Suuply
MT1
MT1_2
MT1_1
To Motor 1
F a u l t 1 a ) M o t o r 1 O ve r C u r r e n t - M e t h o d 1
In this exercise, we use excessive mechanical load to
create an over current condition. To do this, we hold the
shaft with our hands. Motor 1 stops. If Motor 2 were
running, it would also stop. The Fault LED turns ON. The
LCD display is as shown in Figure 50. When the Over
Current fault occurs, a diagnostic sequence runs
automatically. However, the system detects no faults as
there are no faults on the bridge. Therefore, the Diagnostic
1 = FL
0 = OK
4
LOAD
OPEN
3
2
SHORT TO GND
1
0
SHORT TO BAT
BYTE 3M+133: BRIDGE FAULT
+
HEADER CONNECTOR
O C - O K
Figure 51. Interpretation of Fault Status Bytes
Ob
To Motor 2
www.cypress.com
B R - O K
The fault status is available in the Register Map at BYTE
3M+133 and BYTE 3M+134. Figure 51 shows how to
interpret fault status bytes.
Figure 49. Representative View of Motor Control Board
Vout2
M 2
e
Motor 2
Shorted to
ground
O C - F L
let
Run Motor 1 in CW direction.
Short MT1_2 to battery with a wire
connected to battery. Retain the
short for 3 seconds.
B R - O K
so
3
Motor 1
Shorted to
Battery
M 1
Over Current Status
Method 1: Run Motor 1, and hold
the shaft with one hand to
mechanically load.
Method 2: Run Motor 1 in CW
direction with 50% ON time, and
then use a piece of wire to firmly
short MT1_1 to battery. Retain the
short for 3 seconds.
2
Bridge Status
-
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
NOT
USED
MOTOR MOTOR
1
2
1 = FL
1 = FL
0 = OK 0 = OK
BYTE 3M+134: OVER CURRENT FAULT
With two motors, the bytes are BYTE 139 and BYTE 140.
We transmit the command: 0x8B 0x8C 0x80 to read these.
As usual, the last byte is a dummy byte. The received
bytes are 0x00 0x00 0x01. The first byte is ignored. The
second and third bytes indicate that there are no bridge
faults, no faults detected by Diagnostic, and there is Over
Current Fault on Motor 1.
F a u l t 1 b ) M o t o r 1 O ve r C u r r e n t – M e t h o d 2
In this exercise, we use a wire to firmly short MT1_1 to the
battery. This is equivalent to suddenly creating a 100%
duty cycle from a 50% duty cycle on Motor 1, and it results
in an over current condition. The same fault may not have
occurred if the motor was running close to 100% duty
cycle prior to the short.
The LCD initially displays the same status as shown in
Figure 50. But if we hold the wire in place to maintain the
short, the Diagnostic routine detects it. After the
Diagnostic sequence runs (around 2 seconds from the
occurrence of the fault), the display changes to as shown
in Figure 52.
Document No. 001-75813 Rev. *A
38
®
H Bridge Based Motor Drive Protection Using PSoC 3
Figure 54 shows a scope shot of the fault condition. The
figure shows the active gates of the two FETs and the
voltage at terminal MT1_2. Under normal circumstances,
the voltage should be close to ground. As soon as it is
shorted, the voltage starts to increase. The detection of
the fault and the resulting actuation (gate turn OFF) occur
within 11.2 µs from the occurrence of the fault. This is with
a Fault Detection blanking time of 10 µs. For faster
detection and actuation times, reduce the blanking time.
Figure 52. LCD Display Reporting Diagnostic Fault
Motor Id
M 1
Bridge Status
B R - F L
O C - F L
S H O R T _ T O _ B A T
Diagnostic Status
Figure 54. Scope Shot of Fault Detection and Actuation
Delay
It shows that the Diagnostic module detected a fault on the
H bridge that drives Motor 1. It indicates that the possible
cause is a Short to Battery. The Over Current status
shows that an Over Current fault was detected before
Diagnostic began.
Detection and
Actuation Delay
e
Gate of HIGH
Side FET
Short Starts
let
The Fault Status is read similarly as before by transmitting
0x8B 0x8C 0x80. The resulting received bytes are 0x00
0x21 0x01. The first byte is ignored. The second received
byte indicates that there is a Fault on the H bridge for
Motor 1, and it is a short to battery. The third received byte
indicates that an Over Current fault has been detected on
Motor 1.
Gates Turn OFF
Gate of Low
Side FET
Figure 53. LCD Display for Motor 1 Shorted to Battery
Motor Id
Fault 3 Motor 2 Shorted to Ground
In this exercise, Motor 2 starts with direction set to CW.
Then use a wire connected to ground to short the terminal
MT2_1 to ground. Retain the short for 3 seconds. All
motors stop immediately. The resulting LCD displays
before and after Diagnostic are shown in Figure 55.a and
Figure 55.b respectively.
Ob
so
Fault 2 Motor 1 Shorted to Battery
Motor 1 is run in CW direction, which sets MT1_2 LOW,
and a PWM is set on MT1_1. To create the fault, short
MT1_2 to battery. All motors stop, and the LCD display is
as shown in Figure 53.a. After the Diagnostic runs, the
display changes to Figure 53.b.
MT1_2
Figure 55. LCD Display for Motor 2 Shorted to Ground
Bridge Status
M 1
B R - F L
O C - O K
M 2
B R - O K
O C - O K
Over Current Status
Motor Id
Bridge Status
M 1
B R - O K
O C - O K
M 2
B R - F L
O C - O K
Figure 53.a
Motor Id
M 1
Over Current Status
Figure 55.a
Bridge Status
B R - F L
S H O R T _ T O _ B A T
M 2
B R - F L
O C - O K
S H O R T _ T O _ G N D
Diagnostic Status
Diagnostic Status
Figure 53.b
The fault status is read by transmitting 0x8B 0x8C 0x80.
The resulting received bytes are 0x00 0x21 0x00.
www.cypress.com
Bridge Status
Motor Id
O C - O K
Document No. 001-75813 Rev. *A
Figure 55.b
39
®
H Bridge Based Motor Drive Protection Using PSoC 3
The resulting status from the Register Map is extracted by
transmitting bytes 0x8B 0x8C 0x80. The received bytes
are 0x00 0x44 0x00. The significant part of the received
byte indicates that there are no over current faults and that
M2 is shorted to ground. During faults, over current
conditions may be created. So, in some cases, the Over
Current status may be set to Faulty in case of a short to
battery or Short to Ground faults.
Fault 4 Motor 2 is Open
Disconnect Motor 2 from the Motor Control Board. Motor 1
may be active or stopped. Within 2 seconds, all motors
stop. The LCD display is as shown in Figure 56. The
corresponding fault status read from the Register Map is
0x00 0x50 0x00 to indicate that there is a load open fault
on Motor 2.
Bridge Status
B R - O K
M 2
In this application note, we introduced an alternate method
to protect an H bridge based motor drive that does not
require smart drivers. We illustrated methods to use
simple components to drive high side. We discussed the
different faults that may occur in a motor drive, leading to
operations outside the safe operating area of the switches.
We proposed several methods to detect and prevent such
faults, particularly the use of the Diagnostic sequence to
periodically examine the H bridge and the load when not in
operation. We also presented a scalable architecture to
implement these methods as well as demonstrated a full
implementation of the system using PSoC 3. The example
exercise used a motor control board and two brushed DC
motors with significantly different electrical and mechanical
characteristics to fully demonstrate the ease of
configurability of the system for different motors.
O C - O K
let
Motor Id
Summary
e
Figure 56. LCD Display for a Load Open Fault on Motor 2
If any command other than a Diagnostic request or a
system release command is transmitted following a fault
condition, the LCD displays that the system is locked
(Figure 57.a). On sending the correct release command
with the correct release code (0x0E 0xCC for the
associated project), the LCD displays that the system has
been released (Figure 57.b). Table 19 shows the list of
faults that the system can detect.
L O A D _ I S _ O P E N
Diagnostic Status
so
Related Application Notes
Figure 57. LCD Display for System Lock and System
Release
S Y S T E M
AN60580 - SIO Tips and Tricks in PSoC® 3 / PSoC 5
L O C K E D
R E L E A S E
C O D E
Ob
T X
AN54181 - PSoC® 3 - Getting started with a PSoC® 3
design project
AN52705 - PSoC® 3 and PSoC® 5 - Getting Started with
DMA
Figure 57.a
S Y S T E M
S E N D
R E L E A S E D
C O M M A N D S
Figure 57.b
Table 19. Faults Detectable by the System
Fault
Motor 1 or 2
Condition
Shorted to
battery
Detectable when Motor 1 or 2 is either active or
stopped.
Shorted to
ground
Detectable when Motor 1 or 2 is either active or
stopped.
Over Current
Detectable when Motor 1 or 2 is either active or
stopped.
Open
Detectable only if the motor is stopped.
www.cypress.com
Document No. 001-75813 Rev. *A
40
®
H Bridge Based Motor Drive Protection Using PSoC 3
Appendix
The Appendix provides information about:


Demonstration Setup for CY8CKIT-030
Motor Control Board
Setup Details for CY8CKIT-030
You can substitute the CY8CKIT-030 kit for the CY8CKIT001 kit in the examples described in this. The
corresponding project is AN75813 CY8CKIT-030. The
Motor Control Board must plug into Port E of the kit. The
kit and Motor Control Board settings are as follows:

CY8CKIT-030


J11 (VDDA SEL) set to 3.3 V
e

Jumper J10 (VDDD SEL) set to 3.3 V
Motor Control Board



J3 and J6 are in place (connected)
J5 is set to Vin1
Set up the prototyping area as shown in Figure 58.
let
J2 and J4 are in place (connected)
P3_7
P3_6
P3_5
P3_4
SS
SCLK
Ob
RX
so
VDDA
VSSA
VDDD
VSSD
470pF
Ceramic
Figure 58. Prototyping Area Setup for CY8CKIT-030
10K
10K
TX
CTS
VSSA
MISO
P3_2
MOSI
P3_1
P3_0
10K
RTS
P3_3
P0_7
P0_6
VSSD
P0_5
LED2
LED1
P0_4
VR
P0_3
V3.3
P0_2
P0_1
V5.0
VDDA
P0_0
SOIC to DIP 8-pin
P12_4
P12_5
P12_6
P12_7
P6_0 Pin_FAULT
P6_6
VDDD
VSSD
+
The remaining procedure to set up the demonstration is
identical to what has been already presented in the
Demonstration section.
www.cypress.com
Document No. 001-75813 Rev. *A
41
®
H Bridge Based Motor Drive Protection Using PSoC 3
Motor Control Board
Ob
so
let
e
For reference, the schematic of the Motor Control Board is attached.
www.cypress.com
Document No. 001-75813 Rev. *A
42
®
Ob
so
let
e
H Bridge Based Motor Drive Protection Using PSoC 3
www.cypress.com
Document No. 001-75813 Rev. *A
43
®
H Bridge Based Motor Drive Protection Using PSoC 3
Document History
Document Title: H Bridge Based Motor Drive Protection Using PSoC® 3 - AN75813
Document Number: 001-75813
Revision
ECN
Orig. of Change
Submission
Date
Description of Change
3702878
SMON/VEDTMP2
08/06/2012
New application note.
*A
4719658
KUK
04/10/2015
Obsolete document.
Ob
so
let
e
**
www.cypress.com
Document No. 001-75813 Rev. *A
44
®
H Bridge Based Motor Drive Protection Using PSoC 3
Worldwide Sales and Design Support
Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find
the office closest to you, visit us at Cypress Locations.
Products
Clocks & Buffers
cypress.com/go/clocks
Interface
cypress.com/go/interface
Lighting & Power Control
cypress.com/go/powerpsoc
cypress.com/go/plc
Memory
cypress.com/go/memory
Optical Navigation Sensors
cypress.com/go/ons
PSoC
cypress.com/go/psoc
Touch Sensing
USB Controllers
Wireless/RF
PSoC® Solutions
psoc.cypress.com/solutions
PSoC 1 | PSoC 3 | PSoC 5
Cypress Developer Community
Community | Forums | Blogs | Video | Training
e
cypress.com/go/automotive
Technical Support
Ob
so
let
Automotive
cypress.com/go/touch
cypress.com/go/support
cypress.com/go/usb
cypress.com/go/wireless
PSoC is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property of
their respective owners.
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone
Fax
Website
: 408-943-2600
: 408-943-4730
: www.cypress.com
© Cypress Semiconductor Corporation, 2012-2015. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
www.cypress.com
Document No. 001-75813 Rev. *A
45
Similar pages