AM13E23019: ECAP Capture Count Offset Observation

Hello Dheeraj,

Thank you for the additional data and SysConfig screenshots. Looking at your table more carefully, there are actually two separate issues present: a constant capture offset and a boundary overflow condition. I want to address each one individually.

Issue 1: Constant Capture Offset

Your data shows a consistent offset on both Cap1 and Cap2 regardless of duty cycle:

Expected Cap1 = tick_high_pulse + fixed_offset
212 = 200 + 12 (consistent across all rows)

This offset is a fixed pipeline and routing delay composed of three contributors:

1. INPUTXBAR signal routing latency from PWM1A to the ECAP input
2. SyncIn-to-counter-load pipeline delay internal to the ECAP hardware
3. ECAP event detection pipeline, typically 2 to 3 clock cycles

Because the offset is constant and independent of duty cycle, this is not a configuration error. At your 200 MHz clock, 12 to 14 counts corresponds to approximately 60 to 70 ns, which is consistent with the expected INPUTXBAR routing latency on this device.

Issue 2: Boundary Overflow Near Full Period

Your data shows Cap2 wrapping to a small value when tick_low_pulse approaches the PWM period. The following timing reconstruction explains why this occurs.

With tick_low_pulse = 6240 and the routing delay of 12 counts:

TBCTR = 0 : SyncOut fires, ECAP counter resets
ECAP_CTR = 12 : PWM1A goes high, Cap1 captured (~212)
ECAP_CTR = 212 : PWM1A goes low, Cap2 should be ~6452
ECAP_CTR = 6237 : TBCTR reaches 6249 (PRD), rolls to 0, new SyncOut fires
ECAP counter resets before the falling edge is captured
Cap2 captured : 2 to 4 counts (the remaining low pulse after reset)

The overflow threshold can be verified directly:

tick_high_pulse + routing_delay + tick_low_pulse > PWM_PERIOD
200 + 12 + 6240 = 6452 > 6249 -- overflow confirmed

Recommended Solution

Since synchronization is required in your application, I recommend the following combined approach.

Step 1: Set the ECAP Phase Register to compensate for routing delay

This causes the ECAP counter to start at the measured offset value when the SyncIn arrives, aligning it with the actual PWM counter state and eliminating the Cap1 offset.

DL_ECAP_setCounterPhaseValue(APP_ECAP0_INST, 12U);

The value 12 should match your measured Cap1 offset. If that offset varies slightly across builds or devices, measure it once at startup and store it as a calibration constant.

Step 2: Add boundary detection and wrap correction in the ISR

When the ECAP counter is reset by SyncIn between Event 1 and Event 2, Cap2 will be smaller than Cap1. Detect this condition and reconstruct the correct low pulse width using the known period.

void APP_ECAP0_INT_Handler(void)
{
    uint32_t cap1 = DL_ECAP_getCaptureData(APP_ECAP0_INST, DL_ECAP_INPUT_CHAN_1);
    uint32_t cap2 = DL_ECAP_getCaptureData(APP_ECAP0_INST, DL_ECAP_INPUT_CHAN_2);

    uint32_t high_ticks;
    uint32_t low_ticks;

if (cap2 < cap1)
    {
        /* SyncIn reset the counter between Event 1 and Event 2.
        Reconstruct the full low pulse from the two partial segments. */
        low_ticks = (APP_MCPWM_4_PERIOD - cap1) + cap2;
    }
else
    {
        low_ticks = cap2 - cap1;
    }

high_ticks = cap1;
}

Step 3: Apply software offset subtraction if residual error remains

If a small residual offset persists after setting the phase register, subtract the calibrated offset values directly:

#define ECAP_CAP1_OFFSET 12U

high_ticks = (high_ticks >= ECAP_CAP1_OFFSET) ? high_ticks - ECAP_CAP1_OFFSET : 0U;

Summary

Please try these changes and let me know if the behavior improves or if any questions come up.

Best Regards,
Zackary Fleenor