This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C1294XL: Timer PWM glitch when decreasing its period

Part Number: EK-TM4C1294XL

Hi,

I face the exact same problem as described here: https://e2e.ti.com/support/microcontrollers/other/f/908/t/530418?GPTM-in-PWM-mode-suffers-period-update-glitch

In my case this happens at very low frequencies (<20Hz) because I use the 16MHz PIOSC as clock source. But otherwise I couldnt describe the problem better and I have the exact same timer configuration, too. I also tried adding delays between each register write as recommended in the datasheet, section 13.3.2 when using the PIOSC, but it made no difference. I also tried to disable the timer before a write to the prescale, prescale match, load and match registers, and re-enable it afterwards, but this leads to unwanted behavior because the values are applied immediately (because of the enable) and not on timeout as wanted.

Unfortunately I can't use the PWM modules, because I need to cover a frequency range from 1Hz to 10kHz (even with /64 prescaler and slowest clock the 16bit PWM counters can't go low enough). So I do need the 24 bit resolution of the Timer PWM.
This glitch is absolutely inacceptable for my application where the output pulse width must not exceed a given value.


Thank you very much!
Max

  • HI,

      Are you in count down mode or count up mode? If you are in count down mode then try to update the preload and match values on the timeout event instead of immediately. Try it and see if that makes a difference. 

    29.2.2.36 TimerUpdateMode


    This function configures the update of timer load and match settings.
    Prototype:


    void
    TimerUpdateMode(uint32_t ui32Base,
    uint32_t ui32Timer,
    uint32_t ui32Config)


    Parameters:
    ui32Base is the base address of the timer module.
    ui32Timer specifies the timer(s); must be one of TIMER_A, TIMER_B, or TIMER_BOTH.
    ui32Config is a combination of the updates methods for the timers specified in the ui32Timer
    parameter.


    Description:
    This function configures how the timer updates the timer load and match values for the timers.
    The ui32Timer values can be TIMER_A, TIMER_B, or TIMER_BOTH to apply the settings in
    ui32Config to either timer or both timers. If the timer is not split then the TIMER_A should be
    used. The ui32Config values affects when the TimerLoadSet() and TimerLoadSet64() values
    take effect.

    TIMER_UP_LOAD_IMMEDIATE is the default mode that causes the TimerLoadSet() or
    TimerLoadSet64() to update the timer counter immediately.


    TIMER_UP_LOAD_TIMEOUT causes the TimerLoadSet() or TimerLoadSet64() to update
    the timer when it counts down to zero.

    Similarly the ui32Config value affects when the TimerMatchSet() and TimerMatchSet64() values
    take effect.


    TIMER_UP_MATCH_IMMEDIATE is the default mode that causes the TimerMatchSet() or
    TimerMatchSet64() to update the timer match value immediately.

    TIMER_UP_MATCH_TIMEOUT causes the TimerMatchSet() or TimerMatchSet64() to update
    the timer match value when it counts down to zero.


    Note:
    These settings have no effect if the timer is not in count down mode and are mostly useful
    when operating in PWM mode to allow for synchronous update of timer match and load values.

  • Charles Tsai said:
    hese settings have no effect if the timer is not in count down mode

    Perhaps they should be TIMER_DN_DITTO_TIMEOUT then? It would seem the define is for up count timer mode.

  • I think the UP means UPdate in this case, not as to go up.

  • Hi,

    Thanks for the replies. As I said, my code is exactly the same as in the other topic, and - just as there - I do have TIMER_UP_LOAD_TIMEOUT and TIMER_UP_MATCH_TIMEOUT set. Also, I do know that these work as expected for 99% of the time (non-glitch situations) - verified by scope. I tried without those flags and the result is different (again, as expected) and unsuitable for my situation. Again, this glitch only (!) occurs below a certain frequency, which is still well within the range, and it only occurs when changing to a faster frequency. The output is absolutely glitch free in any other situation.

    The "UP" in the flag names must indeed stand for "UPDATE" because Timer PWM only works in count down mode (datasheet page 958, Table 13-3), and the flags do work (as described).

  • Hi,

      Can you send a small CCS project that you can reproduce the problem? According to Amit in the post that you referenced, t it seems like there could be some issue when the current counter is larger than the new preload value under some circumstances. 

  • Absolutely glitch-free (mainly) Greetings,

    Feel your pain - & applaud your "search & find" of a remarkably over-lapping occurrence.    (such (almost) avoids the dreaded, "Single Board/Device Anomaly"  ...    No jury would convict a diagnostician for strangling such a client...)

    Max Zuidberg said:
    Again, this glitch only (!) occurs below a certain frequency, which is still well within the range, and it only occurs when changing to a faster frequency. The output is absolutely glitch free in any other situation.

    You very well note:

    • occurs below a certain frequency  ... (<20Hz - noted opening post)
    • is still well within the range
    • and it only occurs when changing to a faster frequency

    Yet certain added/lasered facts - not yet in evidence - may prove insightful:

    • may  "occurs below" be further sharpened to, "occurs always when below?"
    • does the magnitude of the frequency change impact (either) the occurrence and/or the degree of the issue?   (i.e. is there a precise "frequency delta" which (always) guarantees the issue?)

    If "magnitude of the change" proves disruptive - might a, "Sequence of lesser changes" - cascaded - escape the glitch while still satisfying your "frequency increase?"

    It is my firm's experience that (more often than not) drilling down deeply may expose critical values or linkages - which are unlikely to surface w/out such (lasered) focus...

  • , of course. I attached a slightly modified version of the code already provided in the linked topic (that version runs on the TM4C123, this on the TM4C1294).

    , I played around with the attached example code the whole day and can describe the condition much better now.

    • It is actually not frequency dependant; this was a side effect of how my code works and generates the frequencies.
      The only thing that matters is if the new (24bit) load value is lower than the old (24bit) match value. In that case the error occurs
    • The glitch only occurs if TIMER_UP_MATCH_TIMEOUT is set. With only TIMER_UP_LOAD_TIMEOUT set, the test program works fine but in my application I find sometimes two pulses following each other immediately which is not acceptable.

    Finally, after trying pretty much any possible combination, I found a setup that seems to be glitch free in my application:

    • Only set TIMER_UP_LOAD_TIMEOUT
    • Invert the output with TimerControlLevel(timerBase, TIMER_A, true)

    With the output inverted and the low duty cycle in my application (<20%) the match value is now passed just before reload instead of just after reload. This seems to provide enough time to prevent glitches even without a synchronized match update. The general recommendation would then be to use inverted output for low duty signals and non-inverted output for high duty signals to get as much time as possible between reload and match.

    Although this works I wonder if the behavior in the provided test program is intended and even more what the actual purpose of TIMER_UP_MATCH_TIMEOUT is.

    PWM_Bug_1294.zip