To ensure that every Spectral Micro BLDC driver we produce is fully tested before reaching the customer, we needed to design a test jig. Unlike regular PCBs used in test jigs, our BLDC driver PCBs need to spin and move motors, which presented unique challenges. We wrote a blog post outlining design guidelines we discovered through research, discussions with others experienced in building test jigs, and our own trial-and-error process.
Design and Build Process
First, we designed a pogo pin PCB with a hole pattern that matches the layout of our Spectral BLDC driver. Then, we created a 3D-printed body that allows the PCB to align with the pogo pins and includes a clamp to hold the PCB securely in place. A key design consideration was leaving a hole in the middle of the pogo PCB to allow the motor's diametrical encoder to pass through, enabling the BLDC controller's magnetic encoder to sense it correctly.
Test Jig Workflow
The test jig performs the following tasks in order:
- Relay enables 24V power supply
- Flash firmware to the BLDC driver
- Send a serial command to load the default configuration
- Run the calibration process
- Test CAN communication
- Relay disables the 24V power supply
- The jig is ready for a new PCB
Connectivity and Components
To connect everything to a PC, we used the following components:
- ST-Link V2: To flash the code to the motor driver
- USB-to-Serial adapter: To test the driver's serial port and send commands, such as calibrating the motor and loading the default configuration
- Arduino board: To control the relay that toggles the 24V supply (connected to the PC via USB)
- USB-to-CAN adapter: For testing CAN communication (we used our own CANvas adapter)
In total, the test jig requires four USB ports on the PC:
- One for the serial adapter
- One for the Arduino
- One for the ST-Link
- One for the CAN adapter
Automation
To flash the code, we used the STM32cubeprogrammer tool, a powerful utility for automating firmware flashing on STM32 microcontrollers. It also provides a Python API, making it easy to integrate into our workflow.
Once the firmware is successfully flashed, the next step is automated. A serial command is sent to the motor driver to load a default configuration from flash memory into its EEPROM and save it. This step is essential because, after production, the BLDC drivers have nothing stored in their EEPROM. While the firmware resides in flash, the driver loads its configuration from EEPROM on startup. Without this step, the EEPROM would contain garbage values, causing the driver to malfunction and report errors.
This process ensures that every driver is fully configured and tested before it leaves our facility.
The full code can be found here: Link