6 PWM driver initialisation causes shoot through

developement
,
1

Hello!

I’ve recently joined the simplefoc community and I love whats going on here.
I have made a custom driver board based around an STM32F405 and is rated for 200 amps or so. It uses IR2181 drivers which have to be driven in 6 pwm mode and does not have an enable pin.

Everything is working great except shoot through occurs during the driver initialisation.
I have scoped the PWM outputs and i can see multiple of them toggle high very momentarily. Fortunately I have been using a current limited PSU which has likely saved the board.

After setting a few breakpoints and stepping through the code, I can see that this event is caused within init->_configure6PWM->_initHardware6PWMInterface->_initHardware6PWMPair->setMode

In which we now leave the simplefoc code scope.

Within setMode there is a call to pin_Pullconfig which is essentially a wrapper around LL_GPIO_SetPinPull which seems to configure the pin in pull up mode. This subsequently pulls the pin high for a short duration before it is set low, therefore causing shoot through.

I temporarily commented out setMode (not recommended as this could have negative effects else where) and this resolved the shoot through issue.

1 Like
2

Aha! Looks like the configuration that determines whether a pin is in pull up or pull down mode is defined within the PeripheralPins.c PinMap_TIM. I will experiment with this tonight. Fingers crossed this sorts out the issue, and if so then it may be worth adding a note on the 6 PWM docs to ensure that the pulldown mode is selected if your board does not have an enable pin on the gate drivers

3

Hey @Cdoel,

This problem arises if you don’t have a separate enable pin for the drivers.
I mean, if you’d have an enable pin, then you’d not have these issues?
Am I getting this right?

4

Hi @Antun_Skuric, Yep you’re absolutely right, an enable pin would allow the drivers to ignore any erroneous PWM signals until completely initialised.
However, a lot of widely used and low cost half bridge drivers such as the IR2101 and the IR2181, L6498, EG2181D, FAN7390, etc. require 6 PWM and do not have an enable pin. So anyone using a board based around such chips could end up blowing up their board

5

Sure, I just wanted to make sure that I understood. :slight_smile:
We need to investigate this for sure and try to avoid this in any way possible!
Thanks for reporting this.

1 Like
6

It’s very interesting and a little bit strange. Thanks for investigating it.

Please let us know the result with changing PinMapTIM if you have a chance to try it.

7

Hoverboard controllers use 6pwm without an enable pin, actually most of the boards have no driver. But I never faced any issue during the initialization.

They must be another reason.

[EDIT] maybe the pwm polarity?

8

Its my pleasure :slight_smile: hopefully we can get to the bottom of it

9

Awesome so changing all the PWM pins to pulldown within the pinmap_TIM has fixed the shoot through. So i think it is indeed caused by the pins being pulled up momentarily during initialisation

10

Hmmmm interesting. What MCU do these hover board drivers use? This problem seems to be limited to STM32s from the looks of it.

I dont think it can be PWM polarity because the shoot through only occurs for a very short amount of time during initialisation and then everything works perfectly afterwards

11

On stm32f1.
Yeah then it’s not the polarity, I missunderstood.

Maybe my mosfets are too slow lol

1 Like
12

Maybe there are external pull-downs? The internal pull-ups are quite weak…

Thank you very much for checking.
Based on where the problem occurs I am not 100% sure we can fix it, it might require a change in stm32duino.
But perhaps we can work around it in the init code, and certainly users can work around it by changing the pin map.

13

The only change I can think of is to cross reference the pins passed to the driver object and check whether theyre set to pulldown mode, if not then a warning is printed.

I dont think its essential but could be a nice warning for those who have similar hardware

14

@Cdoel I’m experiencing a similar issue. The details of my configuration are in this post.

Can you post your code changes?

Here are the changes I’ve tried for all of the pins in the PinMap_TIM array.

// Default Configuration
WEAK const PinMap PinMap_TIM[] = {
   {PA_0,       TIM2,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 1, 0)}, // TIM2_CH1
...

I tried this modification to the PinMap_TIM:

// Changed default configuration of pinmap to pull down vs pull up. 
WEAK const PinMap PinMap_TIM[] = {
  {PA_0,       TIM2,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLDOWN, GPIO_AF1_TIM2, 1, 0)}, // TIM2_CH1
...

I also tried this modification

// Changed default configuration of pinmap to no pull vs pull up. 
WEAK const PinMap PinMap_TIM[] = {
  {PA_0,       TIM2,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF1_TIM2, 1, 0)}, // TIM2_CH1
...

In both cases, there was still an in rush/shoot through current.

I’m using an Adafruit Feather STM32 F405 board. So I made the changes to the PeripheralPins_FEATHER_F405.c in the .platformio/packages/framework-arduinoststm32/variants/STM32F4xx/F405RGT_F415RGT directory. I even verified that the firmware.elf files is using the PinMap_TIM definition in PeripheralPins_FEATHER_F405.c.

I appreciate the help.

15

Hey @drummerhul

A good starting point is to scope up your low and high side pwm pins or gate pins during the shoot through event to be sure that this is the cause of it.

Your changes look like they should have fixed it, however i think i had to add a line into platformio.ini to ensure that it didnt use a cached version of the framework. You can also override the pin mappings just in one of your source files seen as it is weakly defined in the framework

16

@Cdoel I haven’t had a chance to hook up the scope yet. For now I have a separate power supply for the motors to allow my to continue development of the application logic. I’ll try out the scope early next week. Stay tune!

Thanks for your help so far.

17

Sweet let me know how you get on!

18

@Cdoel Good news. I solve the problem. Bad News. I solved the problem.

I have two motors (each using a separate TMC 6300). I could not find a pin combo for both sets of driver pins that had a good timer combo score. It looks like the Adafruit Feather STM32 F405 doesn’t expose the correct to drive two 6 PWM drivers (or at least I could not find one). I also tried an Adafruit M4 Express (SAMD51) but had the same issue with a bad pin/timer combo score.

I’ve instead switched to two separate Seeed Studio Xiao ESP32 S3 boards. I had them in stock and they fit inside the enclosure. There is no shoot through current with either of these boards.

Thanks for all the help.

19

Awesome I’m glad you were able to get something working in the end!