• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 1080 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28335: HRPWM duty cycle change problem

Pawel Piwowarski87949
Intellectual 795 points
Part Number: TMS320F28335

I am using Delfino F28335 HRPWM peripherals with one-sided modulation. For my application I need to change the PWM carrier. i.e. the value in the TBPRD register from approximately 150 kHz to 300 kHz depending on the external control messages. I have a problem with this change that once in a few cases one of the PWM-s stops working. I use three HRPWM-s and typically tow of them work properly after the change and one of them once in 4-5 times stops modulating. It happens irregularly, seems to depend on the current duty cycle value. It also seems this problem might be related to the fact that the problematic PWM has more high-frequency content than the other two and in result faster changing duty cycle value. The duty cycle is loaded by an interrupt procedure based on the synchronically filled array of integers updated by McBSP using DMA.

The code snippets – the interrupt setup section, ISR_Run is an assembler routine that calculates and feeds ePWM and HRPWM duty cycle/edge position:

                   EALLOW;

                                      PieVectTable.EPWM1_INT = &ISR_Run;     // Map Interrupt

                   EDIS;

                   PieCtrlRegs.PIEIER3.bit.INTx1 = 1;                                  // PIE level enable, Grp3 / Int1

                   EPwm1Regs.ETSEL.bit.INTSEL = ET_CTRU_CMPB;      // INT on CMPB event

                   EPwm1Regs.ETSEL.bit.INTEN = 1;                                                                         // Enable INT

                   EPwm1Regs.ETPS.bit.INTPRD = ET_1ST;                                          // Generate INT on every event

 

// Enable Peripheral, global Ints and higher priority real-time debug events:

                   IER |= M_INT3;          // Enable CPU INT3 connected to EPWM1-6 INTs:

                   EINT;                            // Enable Global interrupt INTM

                   ERTM;                          // Enable Global realtime interrupt DBGM

 

The change of the PWM carrier value is currently just simple assignments:

                   (*ePWM[1]).TBPRD = (prd);

                   (*ePWM[2]).TBPRD = (prd);

                   (*ePWM[3]).TBPRD = (prd);

                   (*ePWM[4]).TBPRD = (prd);

                   (*ePWM[5]).TBPRD = (prd);

               (*ePWM[6]).TBPRD = (prd);

 

What shall I try in order to get rid of this problem ? Maybe some PWM register reconfiguration before the duty cycle change or PWM interrupts should be performed ? I have made some different workarounds but for now with no success.

Pawel

  • 0
    TI__Genius 17175 points
    Hi Pawel,

    I'm writing to let you know that a C2000 team member has been assigned to this post and should be answering shortly.

    Sean
  • 0 in reply to Sean Bigley
    TI__Guru 57255 points

    Hi Pawel,

    What likely is occurring is something like the following:
    You are writing 300 to a PWM's TBPRD, and it was 500.  In this situation, an issue can occur if you write the new value when the TBCTR is 454.  The counter will then have to count up all the way until it overflows (2^16), return to 0, and then it will re-count up to 300 before the PWM will again output as expected.

    If your PWM outputs are not directly related and don't need to be synchronized, the easiest thing to do is to configure your TBPRD writes to be shadowed.  See TBCTL[PRDLD] in your device's ePWM User Guide. 
    http://www.ti.com/product/TMS320F28335/technicaldocuments#doctype6

    [if your PWMs have synchronization between them, it is possible to still make things work, you'll just likely need to think through things so that potential glitches can't occur - you'll likely want to use shadow loads and also want to consistently have your PWM period writes synchronous to your PWM timer]

    Hopefully this helps!


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 795 points

    Hi Brett,

    thank you for the insightful answer, I'll check it in my project and come back with results.

    Regards, Pawel