• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 959 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.

TSCTR in eCap is having "jitter" and only count to ~150.000 and not 0xFFFF

john madsen
Prodigy 25 points

I am running a 28069 and I am having a strange problem with the eCap function.

I have traced the problem to being related to the TSCTR value jumping up and down.

When I read out the TSCTR value in each program run, then the read value goes both up and down.

I have tried to reset the TSCTR using the SWsync, however I can not get the TSCTR to reset to 0.

I have also noticed that when I stop the TSCTR, then when I start it again, then the value read from TSCTR jumps to a much higher value.

It seems to me that the TSCTR is not a unique and seperate counter for each eCAP, but instead it is a clock value, where the value is latched/loaded from a counter else where in the system. (which counts quite unstable)

This however does not comply with the description in "spruh18e.pdf"

Attached is a picture of the TSCTR value being read from the uP.

Any suggestions to what I am doing wrong?

Br John

Register setup:

    DINT;                                        //disable global interrupts
    pEcapRegs->ECCTL2.bit.TSCTRSTOP = 0;        // Stop the counter

    pEcapRegs->ECEINT.bit.CEVT1 = 0;            //disable all eCAP interrupts
    pEcapRegs->ECEINT.bit.CEVT2 = 0;
    pEcapRegs->ECEINT.bit.CEVT3 = 0;
    pEcapRegs->ECEINT.bit.CEVT4 = 0;
    pEcapRegs->ECEINT.bit.CTROVF = 0;
    pEcapRegs->ECEINT.bit.CTR_EQ_CMP = 0;
    pEcapRegs->ECEINT.bit.CTR_EQ_PRD = 0;

    pEcapRegs->ECCTL1.bit.CAP1POL = EC_RISING;          // Capture Event 1 Polarity select (EC_RISING, EC_FALLING)
    pEcapRegs->ECCTL1.bit.CTRRST1 = EC_ABS_MODE;        // Counter Reset on Capture Event 1 (EC_ABS_MODE, EC_DELTA_MODE)
    pEcapRegs->ECCTL1.bit.CAP2POL = EC_FALLING;
    pEcapRegs->ECCTL1.bit.CTRRST2 = EC_DELTA_MODE;
    pEcapRegs->ECCTL1.bit.CAPLDEN = 1;                  // Enable Loading CAP1-4 regs on a Cap Event
    pEcapRegs->ECCTL1.bit.PRESCALE = EC_DIV1;           // Event Filter prescale select
    pEcapRegs->ECCTL1.bit.FREE_SOFT = 3;                // Emulation mode - 11 = ignore emulation suspend

    pEcapRegs->CTRPHS = 0;
    pEcapRegs->ECCTL2.bit.CONT_ONESHT = EC_CONTINUOUS;  // EC_CONTINUOUS, EC_ONESHOT
    pEcapRegs->ECCTL2.bit.STOP_WRAP = EC_EVENT2;        // "Stop value for one-shot, Wrap for continuous"
    pEcapRegs->ECCTL2.bit.REARM = 1;                    // One-shot re-arm (0, EC_ARM)
    pEcapRegs->ECCTL2.bit.SYNCI_EN = 1;                 // Counter sync-in select, 0 = disable Sync-In
    pEcapRegs->ECCTL2.bit.SYNCO_SEL = EC_SYNCO_DIS;     // Sync-out mode (EC_SYNCIN, EC_CTR_PRD, EC_SYNCO_DIS)
    pEcapRegs->ECCTL2.bit.SWSYNC = 1;                   // SW forced counter sync, 0 = no action (no s/w synch)
    pEcapRegs->ECCTL2.bit.CAP_APWM = EC_CAP_MODE;       // CAP/APWM operating mode select (EC_CAP_MODE, EC_APWM_MODE)
    pEcapRegs->ECCTL2.bit.APWMPOL = EC_ACTV_HI;         // APWM output polarity select (EC_ACTV_HI, EC_ACTV_LO)

    pEcapRegs->ECCLR.all = 0x00ff;

    pEcapRegs->ECCTL2.bit.TSCTRSTOP = EC_RUN;           // TSCNT counter stop (EC_FREEZE, EC_RUN)
    EINT;

  • 0
    TI__Guru 57255 points

    Hi John,

    After using this module many times, I can confirm that the eCAP's timer is in fact a unique and separate timer.

    Therefore the issue you are seeing must have to do with either the configuration or something odd in how your are doing your testing.  After a quick look at your code, I didn't see anything obviously wrong though and can't easily explain what you are seeing.

    Can you explain your testing methodology a bit more and what is being shown in your two figures?  For example:
    -Can you confirm that you are looking at TSCTR in both pictures? 
    -How is the value getting to the graphing application?  How often is this data being sampled?  Is it possible that aliasing effects are occurring?  Note that you could change the eCAP clock prescaler value to help check this.
    -Are you looking at the variable as a 32-bit value? 
    -Is there any signal on the physical GPIO (configured as an eCAP) input?

    If possible, my recommendation might be to connect up CCS, run your code, control the registers via the watch window and view the way TSCTR changes in real-time mode. 

    Hopefully this helps give you some ideas.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Prodigy 25 points

    -Can you confirm that you are looking at TSCTR in both pictures?  -> yes.
    -How is the value getting to the graphing application? -> mapped through our management system.

    How often is this data being sampled? -> Each 10mS

    Is it possible that aliasing effects are occurring? -> No

    Note that you could change the eCAP clock prescaler value to help check this.


    -Are you looking at the variable as a 32-bit value?  -> yes
    -Is there any signal on the physical GPIO (configured as an eCAP) input? -> yes (100Hz 50% DS)

     

    My core problem is that I use TSCTR time stamp for calculating frequency variations.

    I have found that if I set CTRRSTx = 1, then TSCTR readings are showing this strange behavior.

    I have changed my setup so that I now run it with CTRRSTx = 0 and then I get the correct expected TSCTR values.

    I have an acceptable work-around for my problem, but there still exists a strange issue, which is not described in the spruh18e.pdf document.

     

     

  • 0 in reply to john madsen
    TI__Guru 57255 points

    John,

    My only other thought might be to check the GPIO qualification of your eCAP's GPIO pin.  You will want to at a minimum use 'synch to SYSCLKOUT'. 

    A window of 3 or 6 samples are applicable as well (if you system requires it).  The asynch option is not valid and could conceivably cause you to see odd issues.


    Thank you,
    Brett