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 result register reset ?

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hi,

I'm using the eCAP to measure a pulse width.

Basically CAP1 reg is set to rising edge, with reset. CAP2 is set to falling edge, no reset.

attached is the init function.

I'm reading CAP2 to get the pulse width.

I have an issue that sometimes during a pulse train I read 0 (zero) in CAP2, although I see the pulse present on the GPIO with a scope (I'm using a 1000 Int16 vector, and use the graph of the CCS to see all captures).

I use async mode on the GPIO, so no qualification. Pull-up disabled.

pulses are around 400ns, so roughly 80 sysclks (200MHz sysclk).

My first question is - how is it even possible to have 0 in CAP2? I cannot find a situation that this can happen.

second - any ideas on solution/how to debug this?

third - is there any mechanism that will reset the CAP2 result register (e.g. reading it) ?

thanks a lot!

void Init_eCAP(volatile struct ECAP_REGS  *eCAP)
{
    EALLOW;

    eCAP->ECEINT.all = 0x0000;             // Disable all capture interrupts
    eCAP->ECCLR.all = 0xFFFF;              // Clear all CAP interrupt flags
    eCAP->ECCTL1.bit.CAPLDEN = 0;          // Disable CAP1-CAP4 register loads
    eCAP->ECCTL2.bit.TSCTRSTOP = 0;        // Make sure the counter is stopped

    eCAP->ECCLR.bit.INT = 1;               // Clear Global interrupt flag

    // Configure peripheral registers
    eCAP->ECCTL1.bit.CAP1POL = 0;          // Rising edge
    eCAP->ECCTL1.bit.CAP2POL = 1;          // Falling edge


    eCAP->ECCTL1.bit.CTRRST1 = 1;          // Reset counter
    eCAP->ECCTL1.bit.CTRRST2 = 0;          // Don't reset

    eCAP->ECCTL2.bit.SYNCI_EN = 0;         // Enable sync in
    eCAP->ECCTL2.bit.SYNCO_SEL = 0;        // Pass through

    eCAP->ECCTL2.bit.CONT_ONESHT = 0;      // Continous
    eCAP->ECCTL2.bit.STOP_WRAP = 1;        // Stop at 2 events

    eCAP->ECCTL2.bit.CAP_APWM = 0;        // Ecap module operates in capture mode.
    eCAP->ECCTL2.bit.REARM = 1;            // arm one-shot

    eCAP->ECCTL1.bit.CAPLDEN = 1;          // Enable CAP1-CAP4 register loads
    eCAP->ECCTL2.bit.TSCTRSTOP = 1;        // Start Counter


    EDIS;
}

  • Hi Mojo,

    Your initialization follows the example below. I am not sure why CAP2 would be giving a zero unless a rising edge never occurs there. I have tested it with a pwm period of 40, given that my EPWMCLK is 200Mhz. I was able to successfully capture all edges. Both when resetting at rising edge and not resetting at all.

    Have you had a chance to see the example project that captures a pwm signal from the C2000Ware software development kit?

    Under C:\ti\c2000\C2000Ware_4_03_00_00\device_support\f2837xd\examples\cpu1\ecap_capture_pwm

    Within your ecap isr, are you rearming your ECAP before the isr ends? It seems that you are not enabling an interrupt. I would highly suggest to enable an interrupt to occur on an edge event so you are able to capture the CAP1/2 registers and view them in the watch expressions windows. In order to enable capture interrupt you can see how the example does that. In the example above, it generates an interrupt after every 4th capture event.

    Best regards,

    Ryan Ma

  • Thanks Ryan,

    Yes I'm familiar with the example.

    No need to rearm, since I'm working in continuous mode.

    I'm not using the interrupt (cannot use it due to other constraints), so I rely on the register to hold the value.

    What happens if the pulse width is smaller than 1 sysclk ? or maybe 2 sysclks?

    would the rising edge reset the counter, but then the falling edge occurs before the counter starts to increment?

    I couldn't find spec about the exact timing of the eCAP in such a situation, but maybe I missed it.

    thanks!

  • Hi Mojo,

    Understood, and the minimum pulse width at the inputs for this device is given here. Only sometimes you said this occurs? Could you provide a screenshot of what you're seeing? Do you know when this unexpected result occurs or is it random?

    Best,

    Ryan Ma

  • Yes, this happens randomly.

    I think we have very short pulses (< 2 cycles) due to noise. can that cause the CAP2 be zero?

    here's the graph picture:

  • Hi Mojo,

    Yes this could be happening. Does CAP1 capture the signal successfully?

    Have you tried setting up GPIO qualification? If you plan to use this and have any questions on qualification we can create a new thread to discuss questions specific to GPIO qualification and I can forward you correct expert for GPIO qualification for you.

    Best,

    Ryan Ma