Debugging 101

Other Parts Discussed in Post: DRV8711EVM, DRV8711

There is an old saying that “You must learn to walk before you can run”. If you are not familiar with the saying, the Oxford Dictionary defines it to mean that you should not “attempt something difficult before one has grasped the basic skills.” In engineering, it applies in many situations, but here it’s applied to walking through the basic board debug steps prior to attempting to run the complete system.

                                           Figure 1: DRV8711EVM

                                      Figure 2: Debugging Flowchart

Basics are important

The board shown in Figure 1 is the DRV8711 evaluation module (EVM) and highlights the major sections. The micro section contains the code that controls the DRV8711. The DRV8711 controls the power FETs, which provide current to the motor.  Using the debugging flow chart in figure 2 for reference, follow the steps below to ensure success in spinning your motor. 

Consider partial assembly. Placing the minimum number of components required to check a portion of the board eliminates variables.  Using this technique allows the microcontroller code to be debugged prior to connecting the driver. If a problem arises when the driver is connected, it is now easier to debug because now the only variable is the driver.

Be sure to measure continuity across the motor voltage (VM) and ground (GND). Make sure there is no short that can cause problems when initially powering the system. For this, it is best to set a low current limit and slowly raise the voltage instead of setting a high current limit and the desired voltage.

Check control signals

If these first two steps are successful, it is time to check all the voltages on the system. The outputs of regulators are within tolerance at this point. The current limit is increased and the system debug can begin.

Are the charge pumps up? Two causes of this are either the SLEEP pin is asserted or the EN_GATE pin is de-asserted, preventing the device from working.

Are the outputs enabled? Is the output initially toggled low to charge a bootstrap capacitor? A quick method to determine if the output is enabled is to use a resistor divider. Create a resistor divider by connecting two 10kOhm or greater resistors in series from VM to GND. Measure the current by connecting an ammeter between the common point of the resistor divider and the output. If current is flowing, this will confirm that the output is enabled.

Following these steps will ensure your microcontroller is operating properly and  is sending the proper commands to the target device.  It also ensures the target device is awake and responding properly.  

Now it’s time to connect the motor and attempt to spin.

Go for it

Did the motor attempt to spin? Is there an audible noise? These are good and bad signs. It is good because the outputs are enabled for the motor to attempt to spin or to hear an audible noise. A possible cause is the power supply is not sufficient for the system’s needs. Often an undervoltage low fault (UVLO) occurs in this case. One cause of audible noise is the overcurrent circuit is tripping.

Did a UVLO fault occur? One cause is an insufficient bulk and decoupling capacitance on the board. These capacitors are required for operation. The recommended sizes are shown in the EVM schematics available at the EVM product folders. An example is found under the Software section of DRV8835EVM.  

For more information, check out a blog post on the decoupling capacitor and is it really necessary? If the device has an indexer mode, set the mode for full step, fast decay. This is simplest mode to run. Each step input corresponds to moving the stepper motor one step. Watch an Engineer It video on current regulation and decay for more info.

If all else fails, post to the Motor Drive forum in the TI E2E Support Community where you can ask questions, share knowledge, explore ideas, and help solve problems with fellow engineers.

Save your most important resource: TIME

The initial board design is a valuable debugging tool. Even if it does not work perfectly the first time, it is used to identify problems that must be fixed on the next revision.  I have found that spending a little time to edit the board can minimize the lost time. If additional problems are found, the problems can be fixed on the next revision. It will save a little money, but it saves the most important resource when trying to get a product to market; time.

In the end “walking” quite often can be faster than “running”.