stm32 6 complementary pwm output problem for bldc

[Jason Jin]

Posted on August 09, 2017 at 14:24

Greeting,

I am debug the hall sensor based bldc controller. It use the traditional 6 N-MOSFET H-Bridge structure. I use stm32cubemx to configure TIM4 as the Hall sensor input, and the advanced TIM1 as the 6-complementary PWM output. The hall effect input is correctly detected and triggered. However, the complementary PWM doesn't work as I supposed to be. As the Channel 1 set to PWM1 output, CH1 and CH1N works fine as the complementary channel. Channel 2 set to CH2 inactive and CH2N active, it works fine. At the same time, I need to set Channel 3 to CH3 inactive and CH3N inactive, it doesn't work. The channel 3 always output the complementary result. The driving current is high and motor works unstable. I changed different output method with CCER and CCMR registers. I wonder to know if stm32f401 can generate the waveform like described in figure 82 of RM0368(reference manual interfacing with hall sensors example). How to deal with it? or if not, how could I deal with Channel 3. Thanks.

B.R.

Jason

[Vangelis Fortounas]

Posted on August 09, 2017 at 20:16

Hi Jason.

Post some more details about your hardware(nucleo, discovery , custom) and initialization code you use..

Do you mean to deactivate CH3 on the fly or on initialisation phase?

Take a look at theese settings on CubeMX (initialisation phase).

[Jason Jin]

Posted on August 10, 2017 at 01:45

Thanks Vangelis. I want to deactivate the whole CH3(both CH3 and CH3N) on the fly(when commutation occurred). I would like to post more detail configuration with cubemx. 

B.R.

Jason

[Jason Jin]

Posted on August 10, 2017 at 12:22

Greetings,

I would like to share my progress. I use the mode LL_TIM_OCMODE_INACTIVE instead of the mode LL_TIM_OCMODE_FORCED_INACTIVE and tried several combination of enable or disable channels. Now it works. But I am still confused with the following figure described in the reference manual

I can't catch up the logic to match Figure 67. Additionally, when I enable preload, the status change will occur before the COM interrupt happened for about 1.6ms. I use stm32f401, the main clock is 84MHz. 

In conclusion, after I can make the 3rd channel deactive on both side, the motor can run. But it seems it doesn't provide enough power though duty cycle is 10%. It will stopped sometime. I am not sure why, I guess the commutation time is not exactly correct. And I wonder to know why status change occurred before COM interrupt(Hall sensor changed)?

[Jason Jin]

Posted on August 10, 2017 at 13:01

Channel 3 : COM_INT indicates COM interrupt service routine called

Channel 1:  CH1 indicates PHASE A high side control signal

Channel 2:  CH1N indicates PHASE A low side control signal

It shows that the actual commutation signals are generated a little bit before Hall Sensor Event triggered for 1.54ms. Why?

B.R.

Jason

[Vangelis Fortounas]

Posted on August 10, 2017 at 12:12

Hi Jason!

Take a look at theese circled bits. to understand their meaning.  OIS1N, OIS1, OIS2N, OIS2, OIS3N, OIS3 bits are omitted  from figure (for some unknown reason)

If something of theese fits to your concept,  use it.

Last resort is to change the  GPIO MODER relevant  to your GPIO , register

[Vangelis Fortounas]

Posted on August 10, 2017 at 14:03

Hello again!!

I'm glad you realized you should use low(er)-level functions  or/and register level programming

The ''description'' here is as starter to further study the registers , flags and bits.

For the last question, you probable have some delay to the signal to LA.

If you use interrupts to make a GPIO as output , this delay is posible to occur.(but not sure ofcourse)

[Jason Jin]

Posted on August 11, 2017 at 04:28

Hi Vangelis, 

Appreciate for your guidance of Fig 67. It makes more clear than the reference manual.

For the last question, I don't agree GPIO toggling delay would be 1ms or more. After I changed the commutation table, it works better. As I would like to exactly control the commutation time. On the other hand, the commutation delay set to the master timer(TIM4) doesn't work. I am working on it.

B.R.

Jason

[Jason Jin · Accepted solution]

Posted on August 14, 2017 at 07:20

I would like to update the result after my debug. 1.5ms delay occurred between TIM1_TRG_COM_TIM11_IRQHandler() and HAL_TIMEx_CommutationCallback(). The project is generated by stm32Cubemx tools. I don't have time to debug why this delay happened. So I would close this topic and open another topic: why the commutation delay doesn't work at all.

Thanks to all.

B.R.

Jason