40V 30A 2-Layer BLDC Driver w/ Hardware Protection

Introduction to the Project

As part of the Draco'S MG project, we needed to design four brushless motor drivers providing independent control per wheel for our Rover, which will operate in harsh terrain conditions. Our main goals in developing our own hardware instead of using off-the-shelf, closed-box drivers were to create a cost-effective architecture that can operate standalone without burdening the main controller (MCU), withstand a 30A continuous current, and be manufactured on a standard 2-layer PCB.

In this article, we will examine our driver board's hardware architecture, the reasoning behind our component selection, and the layout strategies we implemented in KiCad.

Component Selection Rationale

Every component in our hardware design was included in our BOM to solve a specific problem:

DRV8306HRSMR (BLDC Motor Pre-Driver):We opted for this IC, which provides hardware-based commutation, to avoid overburdening the system with complex FOC algorithms and an extra MCU. We can drive the motor simply by sending a PWM signal from the control board. Additionally, the FGOUT pin on the IC outputs the commutation frequency digitally, allowing the main MCU to calculate the motor speed (RPM) directly. By utilizing the IC's internal 3.3V LDO for the current sense amplifier and LEDs on the board, we saved on the cost and footprint of an external regulator.

Infineon BSC010N04LST (Power MOSFET):Our Rover motors are designed to draw a maximum of 30A at 12.6V. To tolerate potential stall conditions and high torque demands encountered in the field, we used these MOSFETs featuring a 40V / 100A rating and a very low RDS(on) value. This allows us to keep thermal stress to a minimum under 30A nominal operating conditions.

Texas Instruments INA138 (Current Shunt Monitor):The DRV8306 has its own built-in hardware current limiter. We integrated the INA138 amplifier into the circuit to read across the same shunt resistor connected to the driver IC. Thus, by using a single shunt resistor, we provided both hardware current protection and obtained the analog data necessary for the main MCU to monitor power consumption.

Hardware Fault Protection and Isolation

Although our motor driver board operates independently, we needed a hardware cutoff mechanism for safety while communicating with the main control board. The DRV8306's nFAULT pin is pulled LOW (0V) in the event of an overcurrent or thermal fault.

Leveraging this, we introduced a simple AND gate into the loop:

Input A: The PWM signal coming from the main MCU.

Input B: The nFAULT signal from the driver, supported by a pull-up resistor.

Operating Logic

When a fault occurs in the driver, the nFAULT pin goes LOW. Since one of the AND gate's inputs is LOW, the gate output immediately becomes LOW—even if the MCU continues to send a PWM signal—instantly stopping the motor at the hardware level.

The same nFAULT pin is also connected to the MCU. If the MCU software wants to ignore the fault and continue driving the motor, it switches its corresponding pin from Input mode to Digital High (Output) mode. A series resistor placed in between prevents signal collision, and by forcing Input B High, the driver can be forced to operate. This AND gate simultaneously acts as a buffer, physically isolating the MCU pins from the power stage.

PCB Design and 30A Load Distribution

We completed the design as a standard 2-layer PCB for the sake of cost and manufacturability. However, carrying a 30A current through PCB traces with standard copper thickness would lead to thermal issues.

To solve this problem, we removed the solder mask (solder mask expansion) on the high-current traces extending from the battery input to the motor outputs. After production, physical copper busbars/wires will be placed and soldered onto these exposed copper traces located on the bottom layer of the board. This way, the majority of the current will flow through these busbars rather than the PCB copper.

Project Files

(Note: Once the physical production, field tests, and thermal analyses of the driver boards are completed, the KiCad project files, Gerber outputs, and detailed BOM list will be added to this section as open-source.)