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.

MSPM0C1103: PWM FAILED at update channels

Part Number: MSPM0C1103
Other Parts Discussed in Thread: MSPM0C1104, SYSCONFIG

Tool/software:

I'm migrating a STM32 M0 core to the MSPM0C1104 for a SMPS control using PWM modulation on a 2 switch push-pull topology.

I need to update the duty cycle accordinggly at the control sampling time, wich is much larger than PWM period.
Initially I controlled both PWM channels duty cycle manually.

It works quite well, but at some moments the Counter Compare seems to load a wrong value or no value at the Register
and the PWMs have a distorted pulse, sometimes overlaping its outputs, causing the SMPS to fail.


Is there any way to force a safe load to the Compare Register so it always updates correct? Or a better practice to achieved this application.

So far I've tested a few alternatives with no success:
Increased largelly the control sampling time to avoid any Interrupt priority problem or calculation time.

Tested the Deadband mode, uptadating the deadband to get the desired duty cycle, and it shows the same sporadic problem.

A test code with no interrupts or control, only duty cycle updating, and it shows the same problems as the ported code.

.syscfg file has an option to select the Channel Update Mode but it only allow me to use the option "Capture Compare value has immediate effect", saying it only works on TIMA0 but I'm already using TIMA0 for this code.

Bellow are some pictures of the PWM behaviour.

Thank you for the support

  • Yes, it sounds as though you need Shadow Registers. And yes, according to datasheet (SLASF90B) Table 8-9, TIMA0 has Shadow registers.

    This sounds like a Sysconfig problem.

  • At Advanced Config i selected the Enable shadow Load and the problem persist.

  • Does checking that box change the choices in Channel Update Mode? (I see all the choices either way, so there's something different here.)

  • See below, that the setup in sysconfig "DL_TIMER_CC_UPDATE_METHOD_IMMEDIATE" never changes. I tried what you said, but when run build it return to the same defined below.

    SYSCONFIG_WEAK void SYSCFG_DL_PWM_0_init(void) {

    DL_TimerA_setClockConfig(
    PWM_0_INST, (DL_TimerA_ClockConfig *) &gPWM_0ClockConfig);

    DL_TimerA_initPWMMode(
    PWM_0_INST, (DL_TimerA_PWMConfig *) &gPWM_0Config);

    // Set Counter control to the smallest CC index being used
    DL_TimerA_setCounterControl(PWM_0_INST,DL_TIMER_CZC_CCCTL0_ZCOND,DL_TIMER_CAC_CCCTL0_ACOND,DL_TIMER_CLC_CCCTL0_LCOND);

    DL_TimerA_setCaptureCompareOutCtl(PWM_0_INST, DL_TIMER_CC_OCTL_INIT_VAL_LOW,
    DL_TIMER_CC_OCTL_INV_OUT_DISABLED, DL_TIMER_CC_OCTL_SRC_DEAD_BAND,
    DL_TIMERA_CAPTURE_COMPARE_0_INDEX);

    DL_TimerA_setCaptCompUpdateMethod(PWM_0_INST, DL_TIMER_CC_UPDATE_METHOD_IMMEDIATE, DL_TIMERA_CAPTURE_COMPARE_0_INDEX);
    DL_TimerA_setCaptureCompareValue(PWM_0_INST, 500, DL_TIMER_CC_0_INDEX);

    DL_TimerA_setDeadBand(PWM_0_INST, 500, 500, DL_TIMER_DEAD_BAND_MODE_0);
    DL_TimerA_enableClock(PWM_0_INST);



    DL_TimerA_setCCPDirection(PWM_0_INST , DL_TIMER_CC0_OUTPUT );


    }

    Below is the main file for test:

    tima_timer_mode_pwm_dead_band_LP_MSPM0C1104_nortos_ticlang.zip:

  • When I set "Channel Update Mode" to Zero ("Capture Compare value has effect one TIMCLK cycle after timer counter reaches 0") I get

        DL_TimerA_setCaptCompUpdateMethod(PWM_0_INST, DL_TIMER_CC_UPDATE_METHOD_ZERO_EVT, DL_TIMERA_CAPTURE_COMPARE_0_INDEX);

    which is what I expected. I haven't tried the code since I don't really have a test case.

    [Edit: I'm using Sysconfig 1.19.0]

  • In your project, Sysconfig (as you described) objects if you try to set Update Mode to Zero. It also doesn't generate the the .h file. I don't know what's different from my project, but it seems like something's wrong with Sysconfig.

    You could try inserting the line of code above (adapted as needed) into main().

  • You can refer to this demo code, it's tested on G3507's Launchpad with Timer A.

    Although it's based on old SDK, but you can still refer its configuration.

    Example_pwm_shadowCC_G3507_nortos_tic.zip

  • Our update rate is 1 ms. At 100 ms the problem doesn´t show up.

  • On another computer the sysconfig could update the Mode to DL_TIMER_CC_UPDATE_METHOD_ZERO_EVT. But the problem still happens eventually.

    The problem seems to be dependent on update rate.

  • The code you posted is controlling the duty cycle by adjusting the dead band, i.e. changing RISEDELAY and FALLDELAY in DBCTL to "shave down" the duty period.

    I don't see anything in the TRM suggesting that the shadow-CC mechanism has any effect on DBCTL. At the same time, since the dead band is measured between (various) rising and falling edges [Ref TRM Table 15-18], it is susceptible to "missing" edges in the way a CC update can miss compare matches.

    I'm not very familiar with SMPS design, but I had this idea that the dead band was (usually) more or less fixed -- a safety mechanism more than a part of the adjustment -- but I defer to you on that.

    If you want to use this method, it would seem that the shadow CC mechanism isn't going to help you. You'll probably have to fall back on the methods that are used with non-shadow CC registers, e.g. updating DBCTL in software (interrupt) and only at e.g. a Zero or Load event.

    [Edit: Minor clarification]

  • For deadband update, there is no shadow register, you need to handle this by yourself.

    Here is the recommended method:

    Since TimerA0 has CC0/1/2/3/4/5, you can use CC4 or CC5 to generate a interrupt (time point) that suitable for deadband update.

    (In the middle of the PWM cycle and won't influence the PWM working).

    When your switch the duty cycle from small to large, you need to adjust this CC4/5 time point with better value.

    Just make sure your deadband value update is not in the period that PWM timer reload or deadband detection phase.

  • Ok. Using separated channels it work´s. Thank you.