Power distribution unit for my school's FSAE team

Currently, my school's FSAE team uses a Bosch PBX90 to distribute power from the car's low-voltage battery to all low-voltage systems in the car. Its main purpose is to monitor for overcurrents, control the order in which boards are powered when the car is turned on, and control power to certain systems in response to commands it receives over a CAN bus. However, the PBX90 has several limitations that needed to be addressed. First of all, the team plans to use a 24-volt low-voltage battery next year, and the PBX90 only goes up to 20 volts. Additionally, the vertical connectors made packaging more difficult and are generally more difficult to use than the Ampseal connectors we use on the rest of our boards. Finally, the PBX90 costs several thousand dollars, so manufacturing an equivalent board in-house would also save money. Thus, I volunteered to design a power distribution unit (PDU) to replace the Bosch PBX90 in next year's and in future cars.

Requirements

The following requirements were agreed on by the team's electronics group:

1. The PDU must have 32 output channels.
2. The PDU must be able to work up to a supply voltage of 30 volts.
3. Each channel must be able to switch up to 10 amps.
4. Each channel must have a current sensor and a configurable current limit with a configurable timeout.
5. Some of the channels must also be able to support PWM output with a configurable frequency and duty cycle.
6. The user must be able to program startup sequences and CAN commands, and the PDU must then function similarly to the Bosch PBX90.

Overall architecture

All of the car's microcontrollers are from the STM32G4 line of parts. However, the standard chip that all of our firmware is based on, the STM32G473RET6, does not have enough pins to control all channels and read from all current sensors. I could just use a larger chip, however, this would require the current monitoring and PWM generation to run in parallel with the sequencing and CAN code, which would be quite difficult to program. Thus, I decided to use two STM32 chips. The first (or master) chip would be a standard STM32G473RET6 and would run the code that controls the behavior of the PDU. This chip would also communicate with other boards in the car over CAN. The second (or slave) chip would be an STM32G474VET6, which is firmware-compatible but has more IO pins. This chip would be responsible for monitoring channels for overcurrents and generating PWM signals to the outputs. The two chips would then communicate over SPI.

The output channels would also be divided into four banks, with eight channels each. Each bank would be independently powered, thus allowing one to operate at a different voltage if necessary.

A diagram of the overall architecture of the PDU is shown below:

The slave chip has five ADC modules, four of which will be used. The pinout and ADC channel assignment have been selected so that all current feedback signals from one bank will go to the same ADC. The pin assignment of the slave chip has also been optimized to keep the routing as clean as possible. The communication protocol between the master and slave chips is explained in a later section.

Channel design

The schematic for a single channel is shown below:

Each channel has a control input (CTL), a current sense output (SENSE), and a power output (OUT). The control input is driven externally by a gate driver and will either be near VCC or PGND. However, since VCC may be up to 30 volts, and magnitude of the Vgs of the MOSFET is limited to around 20 volts, I added aresistor divider (R1 and R2) between the CTL input and the gate of the MOSFET. However, this would also form an RC circuit with the MOSFET's gate to source capacitance, which would slow doen the turn on and turn off times and increase power dissipation in the MOSFET, especially when the channel is being driven with a PWM signal. Thus, I added C2, which forms a capacitive divider with the gate to source capacitance of the MOSFET. The capacitive divider is in roughly the same ratio as the resistive divider, so when CTL is pulled high or low, the gate voltage reaches its target voltage immediately.

Each channel also has a current sensing shunt (R3) and an MCP6C26-050 current sense amplifier (U1). The current sense amplifier has a gain of 50, so the overall circuit has gain of 0.25 volts per amp. Thus, when a channel is passing the maximum current of 10 amps, the output of the current sense amplifier will be 2.5 volts. Finally, each channel has a flyback diode to protect it when switching an inductive load, such as a pump for the car's cooling loop.

The CTL input to each channel is driven from an IX4426 gate driver. However, the IX4426 has two drivers inside, so channels are grouped into pairs and share a gate driver. To save space on the PCB, one channel will be on the top of the PCB, and the other channel will be on the bottom of the PCB. Furthermore, the PCB will have six layers, with the four internal layers reserved for power and ground.

The figure below shows three views of the initial design: one with all layers, one with only the top layer and components, and one with only the bottom layer and components.

Slave chip functionality and code

The slave chip on the PDU continuously scans the current feedback values from each channel to determine if any of them are over the set current limit. One scan cycle takes roughly 20 microseconds. All other operations, such as receiving commands from the master and updating the PWM state for each channel, occur once per cycle. Thus, all time values that can be configured are expressed as multiples of this cycle time.

After checking if a channel is within the configured current limit, the code must turn the channel on or off according to the specified PWM configuration. For each channel, the period and on-time can be configured. The code maintains a counter for each channel which increments every cycle and counts from 0 to the configured period and then resets. When the counter is less than the configured on-time, the channel is on; otherwise, it is off.

In the slave chip code, the state and configuration of a channel is stored in a 16-byte struct.

	0							8		16
0	TIMEOUT[15:0]
2	TIMEOUT[22:16]								EN		R
4	PWM_CNT[15:0]
6	I_LIMIT[11:0]
8	PWM_PERIOD[15:0]
A	PWM_ON[15:0]
C	PIN[3:0]				PORT[2:0]				COUNTER[7:0]
E	COUNTER[8:22]															F

The fields in this struct are described below:

TIMEOUT[22:0]	The maximum number of cycles the channel can be over the current limit for before the channel is shut off.
EN	Enable the channel
R	Reset the timeout counter when the current drops below the current limit.
PWM_CNT[15:0]	Current value of the PWM counter
I_LIMIT[11:0]	Current limit, expressed as a raw ADC value
PWM_PERIOD[15:0]	Period of the PWM output
PWM_ON[15:0]	On-time of the PWM output
PIN[3:0]	Pin number of the output for this channel
PORT[2:0]	Port on which the output for this channel is located
COUNTER[22:0]	Current value of the current limit timeout counter
F	Indicates if the channel was shut down due to an overcurrent. This bit can only be cleared by cycling EN.

The contents of this struct can be modified by the master chip using the SPI protocol as described below. This allows the master to turn a channel on or off and change the PWM settings. However, the last two registers containing the pin information and the timeout counter cannot be modified by the master.

Communication

The master and slave chips communicate over SPI. The slave chip acts as the SPI master, so the timing of the SPI transations can be optimized on the slave side. By default, the chip select signal is not asserted, so the SPI hardware on the master side is disabled. The master will also pull all three sync lines high. When the master wants to update the configuration for a channel, it pulls some of the sync lines low such that SYNC[2:0] specifies which 16-bit register it wants to write to. When the slave chip reaches the beginning of a scan cycle, it checks the value on SYNC[2:0]. If the value is less than 6, it pulls the chip select output to the master low and reads in a new value for that register for every channel. The slave will also transmit the measured current and the value of the fault bit for every channel on every cycle, even if the master is not listening.

CAN communication

When the PDU is running, only the master will be communicating over CAN with the rest of the car. However, all of the boards in the car run a custom bootloader that allows them to be programmed over CAN. The slave chip only transmits and receives data on the CAN bus when it is being programmed.

Test board and results

To test the basic circuit design of the PDU, I created a test board with only four channels. To simplify testing and construction, the board only has components mounted on one side. Thus, the stacked configuration shown above was "unfolded" and the top and bottom halves were placed side by side. The layout for the test board is shown below.

The test board also has an Arduino-compatible set of headers so the board can be plugged onto an STM32G4 Nucleo board to test code for the slave chip.

Test #1: Current sensor

First, I tested the current sensor by connecting the power input to 24 volts and loading the output of one channel with various resistors on the order of 5-10 ohms. The power supply was set to limit current to a fixed value, and the output of the current sense amplifier was measured. Due to the limited set of available resistors, the current was limited to 2 amps, but the current feedback was accurate (unfortunately I do not have any quantitative results.)

Test #2: PWM

Next, I tested how the circuit responds to a PWM control signal. Using the values from the schematic above, the turn-on and turn-off times of the circuit were rather slow. When the channel was turned off, the output would ramp down linearly as the MOSFET slowly turned off. To fix this, I increased the value of C2 to 15 nanofarads so the high-frequency response more closely matched the low-frequency response set by the resistor divider.

Test #3: Max current

To load the circuit at the maximum current of 10 amps, I connected a load resistor to the output of one of the channels and powered the test board from a power supply with an adjustable current limit. For this test, the load resistor consisted of a 9 ohm heater coil from a dryer. To reduce the resistance and increase the current, the coil was reconfigured into three sections connected in parallel for a total resistance of 1 ohm (plus the resistance of the cables).

Test #4: Temperature

Finally, I tested the thermal characteristics of the PDU circuit. This time, I had access to a second adjustable power supply. I used one power supply to supply 24V into the circuit, and the other was shorted through the current sense resistor and MOSFET. In this configuration, the input voltage and output current can be maintained without dissipating a large amount of power in a load.

The second power supply was set to output a constant current. The current was stepped from 1 to 10 amps in 1 amp increments and the temperature of the MOSFET and current sense resistor were measured with a thermal camera.

When the circuit was passing the maximum current the temperature of both increased to over 90 degrees C. For lower currents, the temperature in degrees Celsius can be approximated as 20 plus 0.73 times the square of the current in amps. Though I do not expect any channel to be passing 10 amps continuously when the PDU is installed in the car, I decided to add mounting holes for a set of heatsinks to the final PDU design.