Skip to main content
EGrom
Associate
October 24, 2018
Question

Glitch free duty cycle update

  • October 24, 2018
  • 6 replies
  • 1293 views

Hi, I am trying to update the duty cycle output on a STM32F107 MCU, glitch free of course. I know I have to set the appropriate PE bit in the TIMx->CCMRx register. This can be done with the library function TIM_OCxPreloadConfig(). At the time I make this call no lock level has been set on the timer in question. BTW, I tried directly modifying the register and using this function. I also verify the register contents after the operation and the desired bit is set. Still, I am getting glitches when modifying the duty cycle. Now every time, but a lot. Is there anything else I might be overlooking?

Thanks for any ideas.

    This topic has been closed for replies.

    6 replies

    waclawek.jan
    Super User
    October 24, 2018

    Read out and post the content of relevant registers.

    How exactly do you modify the duty cycle?

    JW

    EGrom
    EGromAuthor
    Associate
    October 24, 2018

    I am updating by writing to TIMx->CCRx. I'll do a complete register readout and post. That'll take a little...

    EGrom
    EGromAuthor
    Associate
    October 24, 2018

    These should be the relevant registers. We are talking TIM4 channel 2 in this case.

    TIM4->CR1 = 0x0081

    TIM4->CCER = 0x0031

    TIM4->EGR = 0x0000

    TIM4->CCMR1 = 0x6800

    TIM4->SR = 0x0001

    Tesla DeLorean
    Guru
    October 24, 2018

    If you don't have it "preloading" the shadow for CCRx should get copied to the active CCRx at the Update (CNT==0) event.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    EGrom
    EGromAuthor
    Associate
    October 24, 2018

    Hmmm, not sure I understand. You appear to be saying the opposite of the data sheet. Anyway, I just tried that (PEx bit 0 instead of 1 -> TIM4->CCMR1 = 0x6000) and get the exact same behavior.

    BTW, there may be a clue in that there seems to be an impact on the period as well. I.e. sometimes the period is shorter than it should be sometimes longer, but always just for the screwed up cycle. On the following cycle the period is correct again. I am not touching the ARR register. I am also calling TIM_ARRPreloadConfig (TIM4, ENABLE); So period values should be double buffered as well, even though I am not changing them.

    EGrom
    EGromAuthor
    Associate
    October 24, 2018

    Guys, thanks for your help. I think I pulled a fast one on myself. The more I look at the signal, the more I am convinced the glitch is only happening at a very specific time, when something else is going on in my circuit. I think two signals have a potential of interfering at that time. Presently I am not seeing the glitch at any other time. Unless I am coming back, consider it solved.