• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 339 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.

TMS320F28027: XINT Timer Values not as expected

Mark Feller
Expert 1050 points
Part Number: TMS320F28027

Hello,


I am trying to use GPIO6/XINT1 to capture/measure a PWM signal.  (ECAP pins are not available)

I am seeing a mismatch between the measurements and what I am expecting based on the TRM and the input at the pin

As a test, I am generating a 10khz PWM signal with 50% duty from EPWM3, and have this connected to GPIO6.  

Pulse high time = pulse low time = 50us

Pulse period = 100us

From the TRM, xintctr clock source is SYSCLKOUT

SYSCLK = 60MHz

So my expectation is that the 50us hightime or lowtime would be 3000 counts of a 60MHz clock.  Instead I'm seeing a measurement of 50 for hightime and ~227 for lowtime.

At initialization, I first set POLARITY to rising edge only, so I know which edge is being captured.  At first capture, I switch POLARITY to both edges.  Below is the code used for init and ISR:

Initialization:

EALLOW;

GpioCtrlRegs.GPAMUX1.bit.GPIO6 = 0; // 0=GPIO, 1=EPWM1A, 2=Resv, 3=Resv
GpioCtrlRegs.GPADIR.bit.GPIO6 = 0; // 1=OUTput, 0=INput

GpioIntRegs.GPIOXINT1SEL.bit.GPIOSEL = 6; // GPIO6 as interrupt source
XIntruptRegs.XINT1CR.bit.POLARITY = 0x1; // Trigger on rising edge to start

xint1_startup_flag = true;
XIntruptRegs.XINT1CR.bit.ENABLE = 0x1;

EDIS;

ISR:

if (xint1_startup_flag){
xint1_startup_flag = false;
XIntruptRegs.XINT1CR.bit.POLARITY = 0x3;
xint1_nextedge_is_falling=true;
}
else{
if(xint1_nextedge_is_falling){
xint1_nextedge_is_falling=false;
xint1_pulse_high_time = XIntruptRegs.XINT1CTR;  // READING 50, EXPECTING 3000
}
else{
xint1_nextedge_is_falling=true;
xint1_pulse_low_time = XIntruptRegs.XINT1CTR;   // READING ~220, EXPECTING 3000
}

}

I confirmed via logic analyzer that the PWM waveform is correct: 50% duty at 10kHz.  Test hardware is the LaunchPadXL for the 28027.

Do you have suggestions why I'm getting these measurements instead of the expected values?  Or is my interpretation of the datasheet mistaken?

Thanks!

  • 0
    TI__Guru* 95315 points

    Mark,

       Is the behavior any different if you only try to try to measure the falling (or rising) edge for an expected count of 6000?

  • 0 in reply to Hareesh Janakiraman
    Expert 1050 points

    I've reduced the input PWM frequency to 5khz, still at 50% duty, and the values that I'm ready from XINTCTR do not change much.

    Thanks,

  • 0 in reply to Mark Feller
    TI__Guru* 95315 points

    So, regardless of your PWM frequency, XINTCTR value doesn't change much? I presume you have verified that SYSCLKOUT is 60MHZ. Can you please send me your code? You can share it with me privately, if you want. You can do this by initiating a friendship request with me first. You can do so by choosing the "Request Friendship" option when you hover the cursor over my name

  • 0 in reply to Hareesh Janakiraman
    Expert 1050 points

    The EPWM3 timing is working as expected to generate the PWM, so that is my indication that SYSCLKOUT is operating at 60MHz.  (In addition to confirming the setting in DeviceInit)

  • 0 in reply to Mark Feller
    TI__Guru* 95315 points

    Understand. Do you see the incorrect value in the register as well? i.e. instead of reading the value through a variable, look at the value of XINTCTR in the register window.

  • 0 in reply to Hareesh Janakiraman
    Expert 1050 points

    XINTCTR does not freeze when I reach the XINT ISR.  However, when the EPWM is running, I see that the value of XINTCTR in the register window is showing values greater that 50 or 270, possibly up to 3000.   So maybe it is a matter of not reading the register correctly?

    I am using


    uint16_t xint1_pulse_high_time;

    xint1_pulse_high_time = XIntruptRegs.XINT1CTR;

    XIntruptRegs is from TI libraries...I'll look into this to see if it mapped correctly.

  • 0 in reply to Mark Feller
    Expert 1050 points

    It is mapped correctly.  

  • 0 in reply to Mark Feller
    TI__Guru* 95315 points
    Mark Feller said:
     So maybe it is a matter of not reading the register correctly?

    I also feel the register is not being read properly. 

    Few ideas to try:

    1. Continuously read XINT1CTR in a loop and take an ESTOP0 if the counter value=3000. Of course, if there is a problem in the way you are reading this register, this method is not going to help. 
    2. Try GPIO12 (or above) as your XINT1 pin (i.e. a non-PWM pin). I wonder if you accidentally re-configure GPIO6 as a PWM pin after you configure it as XINT1. 
    3. Try XINT2 or XINT3.
  • 0 in reply to Hareesh Janakiraman
    TI__Guru* 95315 points

    Mark,

                One more idea to try: Do not involve the PWM at all. Just toggle a GPIO pin (as a GPIO) and measure the pulse width. This can be achieved just a few lines of code

  • 0 in reply to Hareesh Janakiraman
    Expert 1050 points

    Hi Hareesh,

    After re-reading the description of XINTCTR, maybe this is an issue of making a wrong assumption about how to use XINTCTR.  From the TRM section 1.6.5.2, the counter is reset to 0 on an interrupt edge.  So this is the reason that I'm reading values near-zero in the ISR.  The ISR is triggered, but XINTCTR has just been cleared.

    Which leads to a follow-on question...what is the use case of XINTCTR?  Section 1.6.5.2 also says "These counters can be used to accurately time stamp an occurrence of the interrupt".  How does this work if XINTCTR is zero at the interrupt?  It seems like there should be a capture register for this to work.

    Thanks for your help.

  • 0 in reply to Mark Feller
    TI__Guru* 95315 points
    Mark Feller said:
    the counter is reset to 0 on an interrupt edge.

    Mark, I missed that subtlety. Thanks for pointing that out. It's been ages since I worked on this peripheral.

    Mark Feller said:
    what is the use case of XINTCTR? 

    If the count is read, it tells you how long ago the edge was detected. 

    Mark Feller said:
    It seems like there should be a capture register for this to work.

    For what you were attempting to do, you need to use the Capture unit.