SimpleFOC code causing STM32G4 to short on custom PCB

I’ve received my custom motor driver PCBs today with the STM32G431CBU6 and DRV8316CT. The motor is a 1 pp 24V BLDC inrunner with a max amp of 0.6A. There are two test LEDs connected to PA11 and PA12 which blink fine when uploaded to the STM.

This is part of the schematic:

However, when uploading the 6PWM SimpleFOC code (e.g., openloop velocity), the STM seems to break and 3.3V is now shorted to GND (I measure 3 Ohms resistance between 3.3V and GND). When the STM is removed the short is gone. I upload the code using ArduinoIDE with the ‘generic STM32G4 series’ and board part ‘Generic G431CBUx’. This is the code:

// Open loop motor control example
#include <SimpleFOC.h>

// BLDC motor & driver instance
// BLDCMotor motor = BLDCMotor(pole pair number);
BLDCMotor motor = BLDCMotor(1);
//  BLDCDriver6PWM( int phU_h, int phU_l, int phV_h, int phV_l, int phW_h, int phW_l, int en)
BLDCDriver6PWM driver = BLDCDriver6PWM(PA10,PB15,PA9,PB14,PA8,PB13, PB11);

//target variable
float target_velocity = 20;

// instantiate the commander
Commander command = Commander(Serial);
void doTarget(char* cmd) { command.scalar(&target_velocity, cmd); }

void setup() {

  // use monitoring with serial 
  Serial.begin(115200);
  // enable more verbose output for debugging
  // comment out if not needed
  SimpleFOCDebug::enable(&Serial);

  // driver config
  // power supply voltage [V]
  driver.voltage_power_supply = 24;
  // limit the maximal dc voltage the driver can set
  // as a protection measure for the low-resistance motors
  // this value is fixed on startup
    driver.voltage_limit = 24;
  if(!driver.init()){
    Serial.println("Driver init failed!");
    return;
  }
  // link the motor and the driver
  motor.linkDriver(&driver);

  // limiting motor movements
  // limit the voltage to be set to the motor
  // start very low for high resistance motors
  // current = voltage / resistance, so try to be well under 1Amp
  motor.voltage_limit = 12;   // [V]
 
  // open loop control config
  motor.controller = MotionControlType::velocity_openloop;

  // init motor hardware
  if(!motor.init()){
    Serial.println("Motor init failed!");
    return;
  }

  // add target command T
  command.add('T', doTarget, "target velocity");

  Serial.println("Motor ready!");
  Serial.println("Set target velocity [rad/s]");
  _delay(1000);
}

void loop() {

  // open loop velocity movement
  // using motor.voltage_limit and motor.velocity_limit
  // to turn the motor "backwards", just set a negative target_velocity
  motor.move(target_velocity);

  // user communication
  command.run();
}

The motor seems to work fine with a Nucleo STM32G431 and the evaluation board for the DRV8316. In the last iteration of this custom PCB with a DRV8317H and the same STM32 I had the exact same issue. However, I had to do some other soldering modifications to it which turned out messy so I assumed the shorting was due to faulty reflow of some components. Now it turns out this is not the case.

What could be going on here?

TBH I don’t see anything wrong anywhere in the schematics.

Not normally. Any errors in the clock setup usually just lock up the MCU, so you have to refresh it. And the DRV8316 has sophisticated protections that protect you from any kind of shoot-through situation during initialization.

It’s theoretically possible that you could configure the DRV8316’s buck converter for 5.7V and fry something, but its not connected to anything in your driver, and anyway you’re using the HW configured version of the chip.

So in terms of the generic board definition, it comes with a clock setup that uses the internal 16MHz HSI oscillator and configures the MCU core clock for 170MHz. Since you put a 24MHz crystal on your board, you probably want to add a clock setup function that uses it.
Otherwise the generic configuration should be fine for your needs.

One thing to verify in situations like these is that all the footprints are really correct. Depending on their sources, and the evolution of your project, sometimes components end up with a footprint that fits, but has the wrong pin assignment or isn’t up-to-date for the version of the chip used in the final design?

can you share your motor name and specs?

Hey @Daan87423,

Looking at your schematics I don’t immediately see the problem.
Perhaps the problem is in a different part of the schematics, could you share the rest of it?

The motor you’re using has a winding resistance of at least 3.3A, so its not likely to be the problem - but when testing a new board its better to leave the motor and motor power disconnected for the first tests.

The only problem I potentially see is the nFAULT/PB12 pin. If this were to be driven high while the driver is in fault state, a large current could flow from PB12 to nFAULT (open drain), potentially damaging the MCU.
But in practice this probably won’t occur or be a problem if you’re not setting PB12 high in your code.

So I suspect the problem lies perhaps in another part of the schematic, or perhaps something to do with the wiring… if the 24V power or motor phase wires come into contact with the digital logic section that’s probably bad news for the MCU.

Have you measured the motors phase to phase resistance, to make sure it is close to what you expect?

Hi @runger thanks for your reply!

Of course, here is the rest of the schematic:

FYI the MT6701 is not used as position feedback for the motor, it’s tracking another component in the system. The motor itself uses hall sensors.

For my next attempt I’ll make sure to leave the motor disconnected at first. Perhaps it’s also wise to first directly power the STM32 using an external 3.3V power and try the code.

I measured the motor resistance correctly at 39 Ohms. I think your suspicion is correct. I replicated the setup using a Nucleo G431 and DRV8316C with the same code and so far I haven’t been able to get any failures. I’ll have to order some new STM32s and reflow them before I can try again though. Could it be caused by the ‘generic G4’ configuration (timers, etc.) not exactly matching the setup I have?