TMS320F28069M: Question about eCAP module

Green Deng

Part Number: TMS320F28069M
Other Parts Discussed in Thread: C2000WARE

Dear team:

C:\ti\c2000\C2000Ware_4_01_00_00\device_support\f2806x\examples\c28\ecap_capture_pwm

After modifying the PWM duty cycle in the above routine, my customer found that cap1 can only capture the rising edge of the current pulse and the falling edge of the next pulse.

What may be the reason?

Below is the code:

InitEPwmTimer()
{
EALLOW;
SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 0;
EDIS;

EPwm1Regs.TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN;//TB_COUNT_UP; // Count up
EPwm1Regs.TBPRD = 8000;//PWM3_TIMER_MAX;
EPwm1Regs.TBPHS.all = 0x00000000;

EPwm1Regs.CMPCTL.bit.SHDWAMODE = 1;
EPwm1Regs.CMPCTL.bit.SHDWBMODE = 1;
EPwm1Regs.CMPA.half.CMPA =4000;
EPwm1Regs.CMPB = (Uint16)4000;

EPwm1Regs.AQCTLA.bit.CAU = 2;
EPwm1Regs.AQCTLA.bit.CAD = 1;
EPwm1Regs.AQCTLB.bit.CAU = 2;
EPwm1Regs.AQCTLB.bit.CAD = 1;
//EPwm1Regs.AQCTLA.bit.PRD = AQ_TOGGLE; // Toggle on PRD

EPwm1Regs.DBCTL.bit.IN_MODE = 2;
EPwm1Regs.DBCTL.bit.POLSEL = 2;
EPwm1Regs.DBCTL.bit.OUT_MODE = 3;
//
// TBCLK = SYSCLKOUT
//
EPwm1Regs.TBCTL.bit.HSPCLKDIV = 1;
EPwm1Regs.TBCTL.bit.CLKDIV = 0;

//EPwm6TimerDirection = EPWM_TIMER_UP;

EALLOW;
SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 1;
EDIS;
}

Delete the PWM modification part of the original ecap1_isr code and add the following code:

EPwm1Regs.TBPRD = tpwm;
EPwm1Regs.CMPA.half.CMPA = a;
TSt1 = ECap1Regs.CAP1;
TSt2 = ECap1Regs.CAP2;
TSt3 = ECap1Regs.CAP3;
TSt4 = ECap1Regs.CAP4;

Best regards

over 3 years ago

0 Cody Watkins over 3 years ago

TI__Mastermind 42195 points

There are some modes which can reset the counter values, or ignore events. I would see if they accidently mis-configured the module. However if this code works with a wider pulse, and not with a smaller pulse then perhaps that isn't the issue. Should be easy to adjust the PWM during runtime an check though.

Is the HRCAP being used at all? It has a minimum pulse width requirement.

How wide is the pulse when the falling edge is being missed?

Regards,
Cody

0 Green Deng over 3 years ago in reply to Cody Watkins

TI__Expert 4490 points

Cody Watkins said:
I would see if they accidently mis-configured the module.

According to the customer, he only modified part of the code attached to the above topic in the routine (ecap_capture_pwm.c).

Cody Watkins said:
Is the HRCAP being used at all?

HRCAP isn't being uesd.

0 Cody Watkins over 3 years ago in reply to Green Deng

TI__Mastermind 42195 points

Green,

Please have the customer start from the example code and see if the pulse is still being missed.

How wide was the pulse that they were trying to measure?

Regards,
Cody

0 Green Deng over 3 years ago in reply to Cody Watkins

TI__Expert 4490 points

Hi Cody:

The pulse width is 3ns and the duty cycle is very small. But the same pulse can be correctly collected on CAP2 ~ 4.

Regards,

Green

+1 Cody Watkins over 3 years ago in reply to Green Deng

TI__Mastermind 42195 points

Green,

The eCAP module runs off of sysclock. Sysclock's period on this device is about 11ns, so your pulse width is much less than your system clock. This is clearly a race condition, and will be highly dependent on these signal occurring at the same time as the GPIO buffer read since the eCAP does not latch the input.

Cap2-4 may work on some devices, but I wouldn't expect this to be universally true.

HRCAP also has a minimum pulse width requirement, so that is not an option here.

Perhaps a pulse stretcher could be used here to stretch the pulse beyond 1 sysclock cycle ensuring the device will always see the rising and falling edges.

Regards,
Cody

0 Green Deng over 3 years ago in reply to Cody Watkins

TI__Expert 4490 points

Hi Cody:

After I sent your analysis to the customer, the customer found that his description was wrong.

The pulse width should be 3us instead of 3ns, which is larger than the clock cycle...

So, is there any other difference?

Best regards,

Green

0 Cody Watkins over 3 years ago in reply to Green Deng

TI__Mastermind 42195 points

Green,

there is no problems capturing a 3uS pulse. I expect this to be a configuration issue. I would recommend the customer to start from the example code and then modify the code from there.

There is a very very small chance that there is a defect which is causing this issue, but i think that this is very unlikely. Has the customer verified this behavior on more than one device?

Regards,
Cody

0 Green Deng over 3 years ago in reply to Cody Watkins

TI__Expert 4490 points

Hi Cody:

This is a screenshot of the customer's test, in which tst1 ~ tst4 correspond to cap1 ~ cap4 respectively.

At this time, the pulse width is more than 3us, but cap1 still fails to recognize the falling edge, resulting in an extra cycle of counting.

Best regards

0 Green Deng over 3 years ago in reply to Cody Watkins

TI__Expert 4490 points

In addition, the customer has tested that a pulse of at least 9us width is required to be captured by eCAP1 normally.

0 Cody Watkins over 3 years ago in reply to Green Deng

TI__Mastermind 42195 points

Cody Watkins said:
I would recommend the customer to start from the example code and then modify the code from there.

Have they tried the above?

Cody Watkins said:
Has the customer verified this behavior on more than one device?

Regards,
Cody

0 Green Deng over 3 years ago in reply to Cody Watkins

TI__Expert 4490 points

Hi Cody:

My customer reported that there are no other chips of the same model that can be tested. If there is a chance to test later, he will feed back the test results.

Thank you for your help. I think you may close this post.

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28069M: Question about eCAP module