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.

TMS320F28379D: eCAP in single-shot mode

Part Number: TMS320F28379D

Hello TI support,

I have setup an eCAP module in single-shot mode to capture three events:

EVT1: rising, reset counter

EVT2: falling, do not reset counter

EVT3: rising, reset counter

The pulse train that is connected to the eCAP input has a frequency of 100 kHz (generated by ePWM). The software is re-arming the module at 10 kHz from an ISR triggered by the ePWM.

Since quite a bit of time elapses between EVT3 and re-arming, I would expect the EVT1 capture value to be large (since the counter presumably keeps running while the mod4 counter is stopped after EVT3). However, very strangely, the capture values for EVT1 and EVT3 are identical: 1999 (at SYSCLK = 200 MHz). So this looks like the behavior that I would expect from continuous mode, not single-shot operation. I verified that I am indeed running single-shot operation by removing the periodic ECCTL2.bit.REARM = 1 statement, and confirming that the EVT3 flag is no longer being set.

My conclusion is that I do not properly understand the eCAP operation - any further insight would therefore be appreciated.

Init code (virtually identical to "ECap_Capture_Pwm_Xbar_cpu01" example):

    ECap1Regs.ECEINT.all = 0x0000; // disable interrupts
    ECap1Regs.ECCLR.all = 0xFFFF; // clear flags
    ECap1Regs.ECCTL1.bit.CAPLDEN = 0;  // disable CAP1-CAP4 register loads
    ECap1Regs.ECCTL2.bit.TSCTRSTOP = 0;  // stop counter

    ECap1Regs.ECCTL2.bit.CONT_ONESHT = 1;
    ECap1Regs.ECCTL2.bit.STOP_WRAP = 2; // when to stop
    ECap1Regs.ECCTL1.bit.CAP1POL = 0; // rising
    ECap1Regs.ECCTL1.bit.CAP2POL = 1; // falling
    ECap1Regs.ECCTL1.bit.CAP3POL = 0; // rising
    ECap1Regs.ECCTL1.bit.CTRRST1 = 1; // reset counter
    ECap1Regs.ECCTL1.bit.CTRRST2 = 0; // don't reset counter
    ECap1Regs.ECCTL1.bit.CTRRST3 = 1; // reset counter

    ECap1Regs.ECCTL2.bit.SYNCI_EN = 0;      // disable sync in
    ECap1Regs.ECCTL2.bit.SYNCO_SEL = 0;     // pass through
    ECap1Regs.ECCTL1.bit.CAPLDEN = 1; // enable unit

    ECap1Regs.ECCTL2.bit.TSCTRSTOP = 1; // start counter
    ECap1Regs.ECCTL2.bit.REARM = 1; // arm one-shot
    ECap1Regs.ECCTL1.bit.CAPLDEN = 1; // enable unit

  • Hi Beat,

    Unless you are synchronizing the EPWM and the ECAP modules, EVT1 does not have a good reference point because you are essentially measuring the time between when you started the ECAP counter in software (using TSCTRSTOP or re-arming using REARM) and when the first rising-edge comes in. Also EVT3 should be set the first time around, whether or not you re-arm.

  • Frank - Thank you for your response!

    But how do you explain that I do obtain constant and identical capture values for EVT1 and EVT3? Note that EVT2 is changing with the duty cycle as one would expect.

    Regards,

    Beat

  • Beat,

    Can you sketch out what your EPWM waveform looks like?

  • It is just a normal square wave of fixed period and duty cycle. As produced by the ePWM peripheral.

    But just to reiterate: both EVT1 and EVT3 report the actual period of the square-wave (1999) and EVT2 properly reports the duty cycle (e.g. 999 at 50% duty).

    The square-wave is at 100 kHz, but I only re-arm at 10 kHz.

    I would therefore expect EVT1 to return a value that is much larger than the period, but that is not the case, and this is the issue I would like to resolve.

    Thanks, Beat

  • Ok. The only thing i can think of is that your 10KHz EPWM is generating a SYNC signal that is resetting the ECAP counter (loading phase 0 into the counter). Could also be that your ISR is not actually 10KHz. Have your verified this? Need a few things from you to help figure out what is going on:

    1. In the 10KHz ISR, read the TSCTR before and after re-arm. 

    2. Please provide your full ECAP and EPWM configuration code.  

  • Frank,

    All the ECAP configuration code has been already posted above. As for the ePWM, I can rule out any interaction there as the issue is unchanged when I keep the ePWM disabled and measure an external signal instead.

    I slightly reconfigured my test to gain further visibility into the TSCTR and ECFLAG values. I am still polling the eCAP at 10 kHz, but now I have it measure a signal of 500 Hz at 50% duty cycle. The capture registers read as follows:

    EVT1 = 399999

    EVT2 = 200000

    EVT3 = 399999

    I now delay the re-arming by 5 ms to that we can see what is going on after the one-shot operation has presumably stopped. The result is shown in the image below. As you can see, the flags CEVT1, CEVT2 and CEVT3 are being set successively. These flags remain set until the code clears them before re-arming. However, you can also see that TSCTR is being reset before the re-arming, suggesting the the peripheral is not really operating in one-shot mode and still reacting to events.

    Maybe there is something wrong with my sequence of initialization commands?

    Kind regards,

    Beat

  • Beat,

    Ok. What you are seeing is not expected. Give me a couple of days to replicate your issue locally and I would get back to you.

  • Hi Beat,

    I took a deeper look at your issue and was able to reproduce what you are seeing. So what you are seeing is actually how the ECAP operates in one-shot mode; the documentation is not very clear in this regard. I will file a ticket to get the documentation clarified.

    What is happening is, in one-shot mode, further register writes after initial capture is inhibited, the ECAP still captures in the background.

    Essentially the only difference between one-shot mode and continuous mode is that for one-shot mode, the ECAP still captures in the background like continuous mode but new captures will not be loaded into the capture registers without re-arming.

    Let us know if the explanation is not clear.

  • Hi Beat,

    Anymore questions on this?

  • Hi Frank,

    Thank you very much for taking the time to investigate and clarify.

    Kind regards,

    Beat

  • No problem. Let us know if you see anymore unexpected behaviors.