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.

TMS320F28069: Delayed EPWM execution

Part Number: TMS320F28069

Hello,


we use the EPWM outputs of the TMS320F28069 as control for a half bridge.
After initialisation, only the compare value of the PWM machine is adjusted.
This takes place in the CLA interrupt. The PWM machine is operated in UpDown-Mode at 30kHz.
Epwm1A and Epwm1B are used for upper and lower IGBT synchronously and inverted.
We want to change the dutycycle at CTR = Zero and CTR = Period. CMPA shall be used for both PWMs.

In my tests I noticed that 2 to 3 times the CLA_int is entered before the Compare-Value is effective.
My expectation would be that a Comparevalue which is calculated in CLA_int will be effective from the next CTR = Zero or CTR = Period Event.

Where can this delay come from?

Epwm1 is initialized like this:

    EPwm1Regs.TBPRD = PWM_PERIODE_USED; //90e6/30e3
    EPwm1Regs.TBPHS.half.TBPHS = 0;
    EPwm1Regs.TBCTL.bit.CLKDIV = TB_CLKDIV_DIV1; //0
    EPwm1Regs.TBCTL.bit.HSPCLKDIV = TB_HSPCLKDIV_DIV1; //0
    EPwm1Regs.TBCTL.bit.SYNCOSEL = TB_CTR_ZERO; //1
    EPwm1Regs.TBCTL.bit.PRDLD = TB_SHADOW; //0
    EPwm1Regs.TBCTL.bit.PHSEN = TB_DISABLE; //0
    EPwm1Regs.TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN; //2
    EPwm1Regs.CMPCTL.bit.SHDWAMODE = CC_SHADOW; //0
    EPwm1Regs.CMPCTL.bit.SHDWBMODE = CC_SHADOW; //0
    EPwm1Regs.CMPCTL.bit.LOADAMODE = CC_CTR_ZERO_PRD; //2    
    EPwm1Regs.CMPCTL.bit.LOADBMODE = CC_CTR_ZERO_PRD;  //2
    EPwm1Regs.AQCTLA.bit.CAU = AQ_CLEAR; //1
    EPwm1Regs.AQCTLA.bit.CAD = AQ_SET; //2
    EPwm1Regs.AQCTLB.bit.CAU = AQ_SET; //2 - probably not needed
    EPwm1Regs.AQCTLB.bit.CAD = AQ_CLEAR; //1 - probably not needed
    EPwm1Regs.DBCTL.bit.HALFCYCLE = 0;
    EPwm1Regs.DBCTL.bit.IN_MODE = DBA_ALL; //0
    EPwm1Regs.DBCTL.bit.POLSEL = DB_ACTV_HIC; //2
    EPwm1Regs.DBCTL.bit.OUT_MODE = DB_FULL_ENABLE; //3
    EPwm1Regs.DBRED = 42;
    EPwm1Regs.DBFED = 42;
    EPwm1Regs.TBCTL.bit.FREE_SOFT = 0;

Regards,

Dominik

  • Dominik,

    what is causing your CLA task to trigger?

    What is the order of event that you are expecting? Update CMPA-> start CLA task->update duty cycle?? 

    Regards,
    Cody

  • Hello Cody,

    the CLA is triggered by the ADC interrupt, which is triggered by Epwm1's Zero or Period event.

    The ADC int is effectivly empty. The CLA converts the ADC Results to their actual values and calculates the next Compare Value.

    The compare value is written to Epwm1.CMPA.half.CMPA afterwards in the CLA interrupt.

    My expactation would be, that the Comparevalue will be used at the next Zero or Period event.

    As exampe: I said we use 30kHz. So every 33µs the ADC is called. Our CLA needs arround 10µs for it's calculations. Then my expactation would be, that 23µs later the compare value is in use.

    Regards,

    Dominik

  • Dominik,

    I do not expect a delay. If a value is written to CMPA then the next CTR= 0 or CTR= PRD event should cause the CMPA value to take effect.

    Is it possible that your CLA task was delayed? Maybe the trigger was reconfigured to something else, or possibly the CLA was executing another task?

    How can you tell if the previous value written has or has not taken effect?

    I would recommend putting some GPIO toggles in your code to see when CMPA is getting updated,and then see how long it takes to take effect. It shouldn't take any longer than the next CTR=0 or CTR=PRD event.

    Regards,
    Cody

  • Dominik,

    Are you still having problems with this?

    Regards,
    Cody

  • Hi Cody,

    I'm still having problems, but they are smaller than I thought first.

    I measured by changing CMPA over a GPIO from 0 to 1000. However, my GPIO was a filtered Signal which takes 0,1ms to reach 3,3 V. I misjudged it because my logic analyzer interpreted less voltage as high signal.

    Now my Triggersignal is faster and I measure 0-1 periods without new compare value. It's working if the next event is at CMPA = Period and not working at CMPA = Zero(see figures).

    Additionally it works every time if I change CMPA from 1000 to 0.

    Regards,

    Dominik

  • Dominik,

    I am not 100% sure from your description, but it sounds like you are having a this issue.

    F28069 has a more modern Type 1 PWM. https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/646249

    Regards,
    Cody

  • Hello Cody,

    I'm not quite sure if I'm having the exact same problem as Ricky either. But what I could extract from the conversation and what finally worked for me was changing

        EPwm1Regs.AQCTLA.bit.ZRO = AQ_NO_ACTION;
        EPwm1Regs.AQCTLA.bit.PRD = AQ_NO_ACTION;

    to

        EPwm1Regs.AQCTLA.bit.ZRO = AQ_SET; //needed when CMPA changes from 0 to x to work immediatly
        EPwm1Regs.AQCTLA.bit.PRD = AQ_CLEAR; //needed when CMPA changes from TBPRD to x to work immediatly

    Notice that my PWM-Logic is inverted to Rickys.

    Is the ZRO or PRD event handled before the shadowregister is transfered? Would that prevent CAU and CAD event from Clearing or Setting the Output?

    Regards,

    Dominik

  • Dominik,

    Are you still having an issue?

    The take away from the other post should be that newer devices like yours shadow loads happen before the CMPA event is compared..

    The priority of events are discussed in the TRM.

    There are a number of things that could be causing CAU or CAD to be missed.

      • Adjusting the TBCTR with TBPHS past the CAU or CAD event.
      • Changing the CMPA value using immediate mode 
        • decreasing the value while up counting can cause the even to be missed
        • increasing the value while down counting can cause the even to be missed
      • a higher priority even like a software force

    Regards,
    Cody 

  • Hello Cody,

    my issue is cleared by the changes i stated in my last message.

    Unfortunatly I would not expect my changes to work with the information of your last message because...

    ... TBPHS is not getting changed after the initialization. TBCTR is not manually changed.

    ... Immediate mode is disabled

    ... CAU has higher prioritiy than ZRO and CAD has higher priority than PRD

    I would mark my last message as "this resolved my issue" because I won't be able to test any further as other issues got higher priority.

    Thank you for your help and Regards,
    Dominik

  • Dominik,

    Understood. Please feel free to started a 'related thread' if you need additional support.

    Regards,
    Cody