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.

ePWM Delay

Hi;

I am using ePWM of F28335 and have selected INT on zero event of this ePWM, inside INT I set a GPIO pin to high, but there is a 250 nSeconed delay in GPIO output to change to high, I also applied an external INT and in the INT I set a GPIO pin to high, also there is a 250nSecond delay.would you please guide me what can be the reason of this delay?

Thanks

  • First of all when is the delay from?  From when you write to the GPIO and the GPIO going high or between the zero event and the GPIO high?  What is your clock rate?

    If the delay is between the zero event and GPIO high then this is likely just a processing delay:

    When the event occurs an ISR is called.  Entering this ISR takes about 20 cycles (~130ns at 150MHz) and even more if C needs to save any variables.  There is at least half (if not all if C saves a few variables) of your delay even before you reach user code.  Then there is the time processing all code before the GPIO.  This may not be any but I would need to see the code.

    How to reduce this delay? 

    1) You have to do as little as possible in the ISR to ensure that no extra variables need to be saved.

    2) GPIO code first thing.

    3) Or write the ISR in assembler to use only variables automatically saved by the CPU.

     

    Tim

  • 1) The delay is from zero event or external INT (rising edge) and the GPIO high.

    2) Clock rate is 150MHz.

    3)Program running from RAM.

    4) Program test for external INT and the GPIO high.

     

    _______________________________________________________________________

    #include "DSP28x_Project.h"   


    interrupt void interrupt inputISR(void);


    void main(void)
    {

       InitSysCtrl();
      InitEPwm1Gpio();

     
          EALLOW;
          
           GpioCtrlRegs.GPAMUX2.bit.GPIO23 = 0;
           GpioCtrlRegs.GPADIR.bit.GPIO23 = 0;
         GpioIntRegs.GPIOXINT1SEL.bit.GPIOSEL = 23;
          
            
          GpioCtrlRegs.GPAMUX1.bit.GPIO8 = 0;   //
           GpioCtrlRegs.GPAPUD.bit.GPIO8 = 0;   //
          GpioCtrlRegs.GPADIR.bit.GPIO8 = 1;   //
         
         
          GpioCtrlRegs.GPAMUX1.bit.GPIO9 = 0;   //
           GpioCtrlRegs.GPAPUD.bit.GPIO9 = 0;   //
          GpioCtrlRegs.GPADIR.bit.GPIO9 = 1;   //
            
         EDIS;
         
          XIntruptRegs.XINT1CR.bit.ENABLE = 1;
         XIntruptRegs.XINT1CR.bit.POLARITY = 1;   //

       DINT;
      
       InitPieCtrl();
      
       IER = 0x0000;
       IFR = 0x0000;

       InitPieVectTable();

       EALLOW; 
         PieVectTable.XINT1 = inputISR;  
       EDIS;   



       EALLOW;
       SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 0;
       EDIS;

        InitEPwm1Example();

       EALLOW;
       SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 1;
       EDIS;


       IER |= M_INT1;


      PieCtrlRegs.PIEIER1.bit.INTx4 = 1;   

       EINT;  
       ERTM; 


       for(;;)
       {
           asm("NOP");
       }

    }


    //***************

    void interrupt inputISR(void) {


        EALLOW;  
        GpioDataRegs.GPASET.bit.GPIO8 = 1;
        EDIS;
       
        EALLOW;  
       GpioDataRegs.GPACLEAR.bit.GPIO8 = 1;
        EDIS;
     PieCtrlRegs.PIEIFR1.bit.INTx4=0;
    PieCtrlRegs.PIEACK.bit.ACK1 = 1; // acknowledge this interrupt
    }

    ____________________________________________________________

    Thanks

  • Around 150ns-250ns is probably about right in my opinion.

    It will be due to a number of tasks that take a finite amount of time:

    1) Finding the rising edge on the input.

    2) Starting the interrupt

    3) Preparing the interrupt (this is probably the bulk of the delay).  See Section 3.4 of http://focus.ti.com/lit/ug/spru430e/spru430e.pdf for reference to what is actually happening.

    4) C environment interrupt response (not that much in your code).

    5) User code.

    The only thing I can see to do is remove the EALLOW as GPASET does not need this.  This will save you a few nanoseconds.  But you are probably stuck with some delay as processing time is finite and thus some things dont happen instantly.

    Tim

  • Hi Ahmad,

    Additional delay might be caused by the input qualification circuitry. You should check what is the path of your GPIO signal (async, sync or sync with qualification). If is is default (power-up) configuration, than it depends on the SYSCLOKOUT frequency.

    Regards, Mitja

     

  • Hi Tim, Mitja,

     

    Thanks for your response.

    I selected input qualification as Async, but it seems it does not work for GPIO input, and it is as same as Synchronize to SYSCLKOUT. The SYSCLKOUT is 150M.

     

    Ahmad

  • I agree with Tim,

    This delay seems reasonable.

    The diagram in this wiki article may help:

    http://processors.wiki.ti.com/index.php/Interrupt_FAQ_for_C2000#ISR_Latency

    14 cycles according to this diagram for the first instruction in the ISR to get to exe for an internal interrupt

    The ISR likely includes at least an ASP, DP load before the write to GPIO

    I1    ASP
    I2    DP load      
    I3    GPIO set

    Cycle    D2 R1 R2 EXE  W
    14          I3 I2  I1
    15             I3  I2
    16                 I3
    17                     I3

    18                         pin set

     

    18 cycles x 6.6ns = 118 ns

    You can put the CPU into IDLE (described on the wiki) to avoid any delay due to execution of a multi-cycle instruction when the interrupt comes in.

    Regards

    Lori

     

    EDIT: fixed typo