STM32F3: TIM8 6-Step BLDC PWM Direction Change Output Error

[hemogloben]

Posted on June 02, 2017 at 19:36The original post was too long to process during our migration. Please click on the attachment to read the original post.

[hemogloben]

Posted on June 05, 2017 at 16:41

Updated Workaround:

Take the pair that is becoming the High-Side (in the example above, BLDC_V) and set its high-side to Forced Inactive for a short duration before configuring it for PWM Mode.  Steps:

• Set new Low-side to Forced Active and new High-side to Forced Inactive.
• Software Commutation
• Set new Low-side to Forced Active and new High-side to PWM Mode 1.
• Software Commutation

This works for me for now, but I'm curious if anyone knows of a section in the reference manual that I may have overlooked that explains why this extra step is necessary.

[waclawek.jan · Accepted solution]

Posted on June 06, 2017 at 00:36

It was quite a challenge to follow you. I've read the Notes and Apologies, but still - the waveform depicts the 'event' on channel W, the narrative talks about channel V and the log contained the problem in channel U... It would be hard to make it more confusing, even if you'd try... :)

if anyone knows of a section in the reference manual that I may have overlooked that explains why this extra step is necessary

This one:

Note: In PWM mode, the OCREF level changes only when the result of the comparison

changes or when the output compare mode switches from “frozen� mode to “PWM�mode.

Forced Active changes OC_REF to 1, and then mode is changed to PWM, and as the timer is stopped, the output of comparator does not change. And there was no 'frozen' mode (which I assume is mode 000 - the RMs are far from being crystal clear) in between, so the PWM is not taken into account until the next match of counter to the respective CCR.

A brutal gotcha, this one is. And don't ask me about ST's design decisions.

JW

[hemogloben]

Posted on June 06, 2017 at 16:37

Sorry, looking back I can definitely see that. 

:(

  Thanks for finding the note I'd missed and I would not have been offended if you'd basically replied with 'I wanna help, but fix your description first.'

http://www.st.com/content/ccc/resource/technical/document/reference_manual/4a/19/6e/18/9d/92/43/32/DM00043574.pdf/files/DM00043574.pdf/jcr:content/translations/en.DM00043574.pdf ♯ page=578

RM with the note you mentioned actually names 000 as 'Frozen'.  So it seems that currently I'm indirectly setting OCREF to 0 so I haven't actually solved the problem I've just hidden it so that the first cycle of PWM Mode 1 is 0 only because it hasn't been recalculated.  Might be best to do something similar but go through 'Frozen' instead so that I PWM Mode 1 will be re-calculated on the mode change, right?

How does 'Frozen' affect the outputs?  The RM says that the comparison of CNT CCR has no effect on the outputs but doesn't say what does affect the outputs; does that mean they're GPIO controlled or that they stay at whatever they were set at...?  Sorry, looking around I just find a bunch of ST Presentation PDFs that list 'frozen' in the OCM table without further description.

As a side-note: There's no way to see OCREF is there?  I'd been looking for a way to see it as it would have helped me further debug the issue and probably would've led me to the solution without having to post here.

Eitherway, thanks again.  :)

[waclawek.jan]

Posted on June 06, 2017 at 16:57

How does 'Frozen' affect the outputs?  The RM says that the comparison of CNT CCR has no effect on the outputs but doesn't say what does affect the outputs; does that mean they're GPIO controlled or that they stay at whatever they were set at...?

I'd say the latter. Frozen should not influence OCxREF, and the outputs should not change their state if OCxREF does not change (unless other control bits and signals are wiggled of course).

As a side-note: There's no way to see OCREF is there?  I'd been looking for a way to see it as it would have helped me further debug the issue and probably would've led me to the solution without having to post here.

I know of no direct way except through its 'native' outputs (but they are both in use in your application).

I'd try to visualize one OCxREF by setting it as TRGO (of course only one of the four OCxREF can be treated in this way), and then set another timer to accept that TRGO as its TRGI and set it to Gated mode and a high-frequency PWM output to a pin. There may be some better way I don't know of.

You may try to use the fourth unused channel, modify the software so that it undergoes the same mode changes than one of the used channels, and to output its OC4REF as directly as possible onto its respective pin.

JW