• State Answer Suggested
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 112 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSPM0H3216: PWM_GLITCH

Lavanya M
Prodigy 20 points

Part Number: MSPM0H3216
Other Parts Discussed in Thread: MSPM0H3215

We are currently facing another issue while implementing two PWM signals on the same board. We are generating the second PWM signal using the TimerG module of the MSPM0H3215/3216.

During testing, we observed that random glitches occasionally occur in the PWM output, particularly when the PWM duty cycle is updated dynamically based on the ADC value.

Could you please help us understand the possible cause of these random glitches and provide the recommended configuration or method to achieve a completely glitch-free PWM output?

Our application requires two PWM outputs using different timer modules, with the duty cycle dynamically updated based on the ADC value. We would like to ensure that the duty-cycle update does not cause any abnormal pulses or glitches in the PWM output.

Please suggest the recommended TimerG configuration, shadow/load mechanism, or register update sequence that should be followed for reliable and glitch-free PWM operation.

  • 0
    Guru 103365 points

    What sort of glitches? A scope trace might be handy here.

    The most common PWM glitch comes from dynamic update of the CC register, where a "miss" with respect to the CTR value can result in 0 or 2 transitions (CC events) in a single cycle. The usual solution is to use Shadow CC registers, so the (true) CC is updated by hardware at a known moment -- usually the Load event.

    Data sheet (SLASFB9B) Table 8-11 indicates that none of the TIMG-s have Shadow CC registers, so you'll just have to be very careful about updating the CC. The usual first-guess is to write the CC at a Load event (in the ISR).

  • 0 in reply to Bruce McKenney
    Prodigy 20 points


    Initially, we used TimerA for PWM generation, and we did not observe any glitches because TimerA has a shadow register.

    Now, we are trying to implement another PWM using TimerG. With TimerG, we are currently facing a random glitch issue. We have also implemented the ISR method to update the PWM at the period boundary.

    The ISR implementation is described below:

    ```c
    /*
    * PWM_0_INST_IRQHandler - TIMG14 interrupt handler.
    *
    * LOAD event fires at every period boundary. If a duty update was queued
    * by the main loop, it is applied here via stop/update/restart so the new
    * compare value takes effect at the start of the next period with no glitch.
    */
    ```

    However, the glitch still occurs randomly, and we have not yet been able to identify the exact root cause.

    Kindly support us in debugging this issue 

    If possible, could you please share any TimerG- and ADC-based PWM generation code. The PWM duty cycle will be controlled based on the ADC value.

  • 0 in reply to Lavanya M
    Guru 103365 points

    In the absence of shadow-CCs. unfortunately, there is no foolproof update method. Loading the CC at the LOAD event has a hazard if the CC value -- old or new -- is very small (up-counting). 

    One method -- still imperfect, but simple -- might be to impose a minimum CC value.

    Since you're already stopping the timer to update the CC, another method that comes to mind [I haven't tried it]: When main() enqueues a new CC value, it also sets CTRCTL:REPEAT=0 (DL_Timer_setCounterRepeatMode(timer,DL_TIMER_REPEAT_MODE_DISABLED)), so the timer stops at the LOAD event. After the ISR updates the CC value it sets REPEAT=1 (DL_TIMER_REPEAT_MODE_ENABLED) before re-enabling the timer.

    You may also be able to do something with the DMA.