MSPM0G3107: PWM Startup Signal Blip

Part Number: MSPM0G3107
Other Parts Discussed in Thread: MSPM0G3507, SYSCONFIG

Tool/software:

Hello,

I am working with the PWM peripheral to control some LEDs. During power-on I am expecting my LEDs to be off until a certain event happens in my software which then sets the LEDs to a specific PWM. I am observing a particular behavior where there is a blip during power-on where the LEDs turn on and then go to their expected off state. I've been messing with the way the PWM is configured to see if I can resolve this issue, but no luck.

Here is an oscilloscope capture of the blip I am referring to.

What is causing this blip and how can I get it to not occur? I have attached a sample project where I was able to recreate the issue.


pwm_led_driver_LP_MSPM0G3507_nortos_gcc.zip

Also, another question(s):

  • What does the "Initial Value" attribute do when configuring the PWM peripheral? I've been messing with it and have not seen any noticeable difference in the output.
  • To get the PWM peripheral to boot in the off state I had to invert the channel. Why is that? If the channel isn't inverted a 0 count duty cycle outputs a high signal.

Thank you in advance!!

Adan Pantoja

  • Hi Adan,

    I am currently unable to recreate this blip in my own testing but will continue to look into this.

    With regards to your other questions:

    • The Initial value configuration is for when you need a default CCP output value when the counter is disabled.
    • Can you clarify what you mean by getting the PWM to boot in the off state?

    Best Regards,
    Brian

  • Hi Brian,

    If it helps, I am using the LP-MSPM03507 evaluation board and was able to reproduce it on that.

    The Initial value configuration is for when you need a default CCP output value when the counter is disabled.

    So if I set it to "Low" I should see the signal startup in the low state? 

    Can you clarify what you mean by getting the PWM to boot in the off state?

    My LEDs are active high, so therefore I expect the PWM output to be low while it waits for an event to occur. Because of the blip, during power-on, the LEDs will turn on for a quick second and then go off. I don't want this behavior. Something is setting the PWM to output high for a split second before it goes to it's expected state. As you can see in the screenshot above, I'm setting the counter value to 0 which means I am expecting the PWM to be 0%.

    Hopefully this makes sense. Let me know if you're still confused.

    Thanks,

    Adan

  • With center-aligned PWM, a compare value of 0 gives 100%. (Sysconfig is even telling you that.) It's set high at 0 (up), then low at 0 (down), so it's effectively always high. (I didn't see the "blip", only an always-high.)

    Did you maybe want edge-aligned PWM instead?

  • Hi Adan,

    So if I set it to "Low" I should see the signal startup in the low state? 

    Yes, the signal will be low until the CTRCTL.EN bit is set.

    I believe I have recreated the blip you are seeing. To confirm, is this recurring for every PWM period, under the settings used in your included example SysConfig file?

    If so, this blip is caused by CCP Output action on up and down attempting to perform opposite actions at the same compare value. In the case of an inverted PWM, CCP Output on up makes the signal low, and CCP Output on down makes the signal high. To remove the blip, you can force the CCP output to be low or high using the following DriverLib function:

     DL_Timer_overrideCCPOut(GPTIMER_Regs *gptimer, DL_TIMER_FORCE_OUT out,
        DL_TIMER_FORCE_CMPL_OUT outComp, DL_TIMER_CC_INDEX ccIndex)
    Best Regards,
    Brian
  • Brian,

    No, this blip is not recurring for every PWM period. It is only on start-up where it happens. In the oscilloscope capture below, the yellow signal is the PWM and the green signal is a GPIO which I have toggling to show program execution from power-on. 

     

    I think that blip is just a side affect of inverting the signals and using center-aligned PWM. It probably cannot be mitigated. At this point, I think it is best to use edge-aligned PWM and avoid this blip all-together.

    The entire purpose of using center-aligned vs. edge-aligned was to re-use a driver which controlled the LEDs. This driver was using center-aligned, 16-bit PWM, on a different chip so the counts ranged from 0 - 32767 (where 0 counts = 0% PWM and 32767 = 100% PWM). Being able to configure the TI to mimic the same behavior would have been ideal, hence why the signal was inverted and so on. But it doesn't look to be the case. Switching to edge-aligned isn't a big deal, and I can make it work.

    I did try the DL_Timer_ovverrideCCPOut but it looks like it disables the entire PWM peripheral while it is enabled. Calls to DL_TimerA_setCaptureCompareValue have no affect on the output.

    Thanks,

    Adan Pantoja