2024-08-30 12:08 PM
Hello,my goal here to understand the TIM channel output behavior in different situations between generating one-pulse. Ultimately I need to make sure that I have a predictable output "0" level output at all times if not generating pulse.
I am using STM32H743 MCU TIM13 timer in PWM mode 2, one-pulse operation. After POR TIM13 is initialized and CCR channel is enabled, yet the counter is not enabled yet (CR1->CEN = 0) , assume that CCR register has value greater than 0 and output polarity is positive (outputs 1 when pulse is generated). What is the expected state at the output pin supposed to be as result of this?
For proper understanding of TIM, how the answer changes if the channel PWM mode changed to mode 1 instead of mode 2?
Also related, after the counter is enabled and software trigger generated one pulse event, then I disable the counter (CR1->CEN = 0 again), from then on what is expected to be the state of the output pin? "Output" at 0 ? At any PWM mode?
I asked this question from 3 leading AI sites and all of them gave contradictory answers based on the same user manual. Some AI were a complete mess. After I pointed to the contradictions, then only one of AI provided seemingly logical answer, but I want to verify here ... I think humans are still "more advanced" in their understanding of their made product documentation .:grinning_face:
Please help
Solved! Go to Solution.
2024-09-05 01:55 AM
0. The weak pull-up/pull-down functionality of GPIO, as controlled by GPIOx_PUPDR, is independent of any other setting of GPIO (except it is set to Analog in GPIOx_MODER). In other words, if set so in GPIOx_PUPDR, the weak (nominally 40kOhm) pullup or pulldown is connected to the pin, regardless of whether the pin is set to actively output any level or not. See the pin structure drawing in GPIO chapter in RM.
1. If a pin with TIMx_CHx functionality is set to Alternate Function (AF) in its respective GPIOx_MODER field, and the given TIMx is selected in its respective GPIOx_AFRx, then this pin is driven actively by the TIMx_CHx channel if that channel is set to Compare/Output in TIMx_CCMRx.CCxS, AND if it is enabled in TIMx_CCERx.CCxE (additionally, in timers with complementary outputs, such as TIM1/8/20 and TIM15/16/17, TIMx_BDTR.MOE has to be set, too; but that's not the case of TIM13).
2. Whether a TIMx_CHx pin is driven actively, is *not* dependent on TIMx_CR1.CEN bit's state. That bit only controls whether the timer's counter runs or not. One-pulse mode (TIMx_CR1.OPM=1) does nothing else just sets TIMx_CR1.CEN=0 upon Update event.
3. If TIMx_CHx drives the pin actively, its level is given by the OCxREF signal XOR TIMx_CCER.CCxP bit (output polarity). OCxREF is generated in a state machine, controlled by several inputs, but its basic operation is given by the TIMx_CNT-to-TIMx_CCRx comparator, according to TIMx_CCMRx.OCxM settings. The exact behaviour of individual TIMx_CCMRx.OCxM settings - including PWM1 and PWM2 modes - is given in the description of this field in the TIMx_CCMR1 register description in TIM chapter. Note also the footnote explaining, that in PWM1/PWM2 modes, OCxREF changes only when the output of the comparator changes, or when TIMx_CCMRx.OCxM changes from "frozen" (which is the reset default) to PWMx - the latter covers the "after configuration" case.
Please note, that the timer's/pin's behaviour is driven by the registers states, not by Cube source code or clicking in CubeMX. In other words, if you want to have control, you may be better off working directly with registers, rather than using Cube or any other library or tool.
JW
2024-08-30 01:55 PM
> I asked this question from 3 leading AI sites
And so the world goes to hell in a handbasket.
Off the top of my head, if the timer is disabled, I ***THINK*** that the output compare does not drive the pin. But I may well be wrong here, and most of my experience is on F4/G4/L4 parts and there is a chance the H7 is different. The best way to find out is to experiment. Do you have hardware (NUCLEO board, eval board, your "real" circuit board)?
2024-08-30 02:39 PM
Hi Bob, I am in the process of re-designing our board after the not-fully-understood circuits burn . It is important to fully understand the designed behavior of the output channel pin otherwise it's even hard to catch or understand the oscilloscope screenshot. The schematic is quite complex and dynamic driving the generated one-pulse that control bunch of boolean logic. When situation is either static or predictable I saw that the output was 0 until the counter was enabled, then ran and triggered one-pulse when crossing the CCR threshold. But sometimes the boolean logic was triggered when the TIM output supposed to be 0 yet I either failed to capture the TIM output or other time did not understand the reading.
Here is example of hard-to-see situation: if the TIM channel goes into "GPIO default state" which is probably "input" or "high impedance" then the output might depend mostly on EMI and my logic analyzer will jump anywhere ... while oscilloscope hard to catch a proper trigger moment that situation because it is rare... most of the time up and counting... go figure...
The easiest way is to fully understand how TIM suppose to work when everything is initialized to generate PWM pulse but the counter is "grounded". Then proper schematic and firmware are guaranteed to work.
2024-08-30 02:43 PM
I just realized that I can help myself to find of fix the problem if I pull-down the TIM13 channel output in the channel setup. I guess probably if TIM abandons the control of the output pin (switches from alternate TIM function to GPIO...input or output I don't know), then pull-down internal 40K might keep this pin from floating...
Is it good idea?
Still I'd prefer to know how TIM channel was designed to behave when the counter is grounded...
2024-09-04 11:39 AM
If you want to guarantee that the timer output pin be low when the timer isn't running, you could write a zero to that bit in the ODR (GPIO output data register). Then before disabling the timer, change the GPIO mode for that pin to "output" then set CEN=0. When you want to enable the timer, first change GPIO mode to "ALT", then set CEN=1. If you are using HAL, you can use the LL_GPIO_SetPinMode() function.
2024-09-04 06:44 PM
Thank you Bob, that will do but too many reconfigurations of the same pin... Wouldn't this give the same result if simply choose the channel output GPIO pin "pull-down" in configuration CubeMX for that timer ?
My understanding is that this option is specifically provided for all those output pin states when it is not driven by the timer as Alternate function (probably when channel is disabled), 'cause in all those "non-timer" states this pin is nothing but GPIO.
Is it so? Unless I am missing something... This probably applies to all STM32 general purpose timers which have Output Compare channels...and this configurable "pull-down" channel output pin probably was intended just for this purpose!
How 'bout this?
2024-09-05 01:55 AM
0. The weak pull-up/pull-down functionality of GPIO, as controlled by GPIOx_PUPDR, is independent of any other setting of GPIO (except it is set to Analog in GPIOx_MODER). In other words, if set so in GPIOx_PUPDR, the weak (nominally 40kOhm) pullup or pulldown is connected to the pin, regardless of whether the pin is set to actively output any level or not. See the pin structure drawing in GPIO chapter in RM.
1. If a pin with TIMx_CHx functionality is set to Alternate Function (AF) in its respective GPIOx_MODER field, and the given TIMx is selected in its respective GPIOx_AFRx, then this pin is driven actively by the TIMx_CHx channel if that channel is set to Compare/Output in TIMx_CCMRx.CCxS, AND if it is enabled in TIMx_CCERx.CCxE (additionally, in timers with complementary outputs, such as TIM1/8/20 and TIM15/16/17, TIMx_BDTR.MOE has to be set, too; but that's not the case of TIM13).
2. Whether a TIMx_CHx pin is driven actively, is *not* dependent on TIMx_CR1.CEN bit's state. That bit only controls whether the timer's counter runs or not. One-pulse mode (TIMx_CR1.OPM=1) does nothing else just sets TIMx_CR1.CEN=0 upon Update event.
3. If TIMx_CHx drives the pin actively, its level is given by the OCxREF signal XOR TIMx_CCER.CCxP bit (output polarity). OCxREF is generated in a state machine, controlled by several inputs, but its basic operation is given by the TIMx_CNT-to-TIMx_CCRx comparator, according to TIMx_CCMRx.OCxM settings. The exact behaviour of individual TIMx_CCMRx.OCxM settings - including PWM1 and PWM2 modes - is given in the description of this field in the TIMx_CCMR1 register description in TIM chapter. Note also the footnote explaining, that in PWM1/PWM2 modes, OCxREF changes only when the output of the comparator changes, or when TIMx_CCMRx.OCxM changes from "frozen" (which is the reset default) to PWMx - the latter covers the "after configuration" case.
Please note, that the timer's/pin's behaviour is driven by the registers states, not by Cube source code or clicking in CubeMX. In other words, if you want to have control, you may be better off working directly with registers, rather than using Cube or any other library or tool.
JW
2024-09-05 10:30 AM - edited 2024-09-05 10:35 AM
Thank you Jan, although you did not explicitly state that my last suggested solution will indeed guarantee "0" level at the output channel pin whenever channel is disabled but if I understood correctly all your information , you proved this will work fine. Is it right? Whenever timer channel is enabled it will override that weak GPIO pull-down, whenever channel is disabled GPIO will be "0" . And this solution is nothing more than a click in CubeMX timer's configuration choosing the "pull-down" for this channel output :grinning_face::grinning_face: The only disadvantage to this solution I see to be the flow of additional 82uA current adding a little to the thermal accumulation but we have a good forced cooling and this does not seem to be a concern at the moment while solution is so simple.
Thank you again
Vlad
2024-09-05 11:04 AM
Jan, please confirm (or deny) the following detail: If pin designated as a channel output for GP timer is disabled and GPIO setting for that pin is neither pull-up or pull-down, then is that pin configured as a default GPIO input ? High impedance?
2024-09-05 01:07 PM
> If pin designated as a channel output for GP timer is disabled
If a pin is set to AF in GPIO_MODER (and it's a pin which is assigned to TIMx_CHx in GPIO_AFR[]), and if in given timer the given channel is disabled by clearing the respective TIMx_CCER.CCxE bit, then given pin is not actively driven. And yes, that's the same behaviour as if that pin would be set to Input in GPIO_MODER.
Such pin can be considered floating/high-impedance.
If in that state the weak pullup or pulldown is switched on using GPIO_PUPDR, that may provide a defined logic level (1 or 0 respectively), provided any external circuitry won'd overload the nominally 40kOhm pullup/pulldown.
JW