Request for Design Feedback: STM32G4 + DRV8316 BLDC Controller PCB

Request for Design Feedback: STM32G4 + DRV8316 BLDC Controller PCB

Greetings everyone,

I’m seeking design feedback on a BLDC controller PCB I’m working on, based on the STM32G4 and DRV8316. This is my first hardware project—my background is in software—so I’d really appreciate input from more experienced members of the community.

This design draws heavily from several excellent projects shared on this forum, including:


Planned Features

  • USB-C programming
  • Closed-loop control using a magnetic encoder and current sensing
  • USB and CAN communication interfaces
  • Power input from 2S or 3S LiPo batteries
  • Support for controlling an A2212 motor

Not Yet Implemented

  • Reverse polarity protection
  • I2C and PWM interfaces
  • SPI connector for an external encoder (similar to ODrive Micro)

Design

Schematic

STM32 Pinout

The kicad file, STM Cube file, Reference Documents, and Block Diagram are on the project’s GitHub.

I haven’t yet started the PCB layout, as I want to ensure the schematic is correct before proceeding. I do have a few technical questions I hope the community can help with:


Questions

  1. SPI Interface Conflict

    The STM32G431C6 provides three SPI interfaces. Two are used—for the encoder and the DRV8316. I’d like to use the third SPI for an external encoder (as seen on the ODrive Micro), but this one shares PF0 and PF1, which are also used for the external crystal.

    • Is it possible to use this SPI interface and an external crystal?
    • Alternatively, is it viable to omit the external crystal and rely on the internal oscillator while still maintaining full functionality?
  2. Adding I2C via Qwiic Connector

    I’d like to include a Qwiic connector for I2C communication, but I’ve noticed most BLDC controller designs favor CAN due to its robustness in noisy, high-EMF environments.

    • Would adding I2C be useful, or is it likely unnecessary or unreliable in this context?
  3. Flashing via USB-C vs ST-Link

    I haven’t exposed the ST-Link debug/programming pins, as I was under the impression the controller could be flashed directly over USB-C.

    • Is this assumption correct, or will I need ST-Link access to flash the firmware (especially during early development)?

Any comments, corrections, or suggestions would be greatly appreciated. Thank you all in advance!

SPI Pin Conflict

  • Theres some flexibility with STM32 peripherals. Some are exposed on more than one pin. In your case, the SPI2 can be configured like this

  • You can share an SPI Interface between the internal encoder and external encoder if you wont use both simultaneously.

  • This mcu can be configured without external crystal also. Here’s a thread discussing the speed variation without the HSE Arduino Mini R4 poor performance - #39 by jazzboy

I2C reliability

  • I2C was developed for intra board communication. So it does not have the noise resilience as other protocols such as CAN or USB.

  • If you’re using it in a gimbal setup or a mini robot arm, it shouldn’t be a problem.

  • So if you have extra pins, you can add an I2C connector

  • These references might be helpful:

Flashing via USB-C

  • I had the same doubt when designing MicroSpora. The MCU has factory bootloader, it can be directly programmed from the Arduino IDE using USB DRV8316 + STM32G431 design request for comments - #4 by runger

  • Pressing RST while holding the BOOT button will put the MCU in upload mode. Code can then be uploaded from Arduino IDE.

  • Using ST-link or USB during development is your choice, but it is a good practice to expose SWDIO and SWCLK pins.

Notes and Suggestions:

  • The DRV8316 is low current driver. It is not suitable for driving A2212 motor with high loads. Microspora was tested on A2212 motor with light loads and slow speeds.
  • If this is your first PCB, I would suggest to make the board at a comfortable size and not too compact. Exposing test pins can be helpful for troubleshooting

I wish you good luck on this project. Since you’re from Software background, the firmware part shouldn’t be an issue for you.

My case was the opposite, It took me two days just to get the motor running. Without the guidance from Runger, it would have been impossible.

Can you share more info about your project and use case

Ok, great point. I will be exposing the appropriate ST-Link pins using a Tag connector so I don’t have to add another component I might not use.

I am working on a robotic actuator controlled via the CAN interface. The A2212 motor will be coupled with an 8:1 planetary gearbox for torque multiplication. I plan to power the motor using a 2- or 3-cell LiPo battery.

To evaluate power requirements, I conducted power draw tests using a benchtop power supply and a drone ESC. The results were as follows:

Voltage No Load Light Load High Load (Near Stall)
6V 0.52 A 1.5 A 2.5 A
9V 0.65 A 2.5 A 3.5 A
12V 0.71 A 3.0 A 8.0 A

Based on this testing, I believe the DRV8316 motor driver can handle the expected current. However, unlike drone applications where the motor is actively cooled by airflow, in my use case it will be enclosed in a 3D-printed housing. Therefore, I will avoid running the motor at full throttle for extended periods to mitigate heat buildup.