Coldfire eTPU Input Capture stops interrupting

[butzodaddy]

I have an Input Capture channel with a 1kHz signal at the input. The CPU is running at 96MHz.  I'm using the eTPU api functions provided by Freescale.

The initialization call is:

Code:

fs_etpu_ic_init( TPU0,                                  FS_ETPU_PRIORITY_MIDDLE,                                  ETPU_IC_MODE_CONT,                                 FS_ETPU_TCR2,                                 ETPU_IC_RISING_EDGE,                                 333 )

The IC continues to work for long periods of time, interrupting every 333 cycles on the input.  At some point the IC stops interrupting the cpu even though none of the control registers for the channel have changed, interrupts are still enabled.  I observe in the parameter ram for the channel that the Transition count is still changing, but the Final time register value is static, during normal operation the Final time register is changing. 
 
Any clues as to why the IC stops interrupting the CPU?

[butzodaddy]

It is not an interrupt register configuration or interrupt level problem.  Once the condition is active, it can be jumpstarted with a call to the fs_etpu_ic_init initialization function and another call to fs_etpu_interrupt_enable (needed only because fs_etpu_ic_init disables the channel interrupt).

[stzari]

Hi,

so it's not that easy ...

I had a  look into the IC eTPU source code (rev 1.7) and I think that there might be a problem with the variable IC_TransCount.
If I'm reading this correctly, the variable is set to zero at initialization (HSR: IC_INIT_TCR2) and then incremented at every transition. It is then checked against IC_MaxCount to see whether the limit has been reached generating an ISR if it is greater than IC_MaxCount.
However it is not reset after that.
So I think that (if you dont issue any HSR inbetween) you would get an ISR after 333 edges, then an ISR at every edge and then nothing after 2^23 edges.

HTH
  stzari

[jbezem]

We seem to have a similar situation.

We need every edge to trigger an interrupt, so we initialize maxcount to 0 (since it is typed as uint32, transcount will never be less, right?).

But now we found situations (we used mode 'continuous', of course) where after some 35+ hours of correct operation, the channel suddenly didn't produce any interrupt any more.

After some serious work, we confirmed that the rest operated as expected, just no more interrupts.

Then we looked at the eTPU source, and found both maxcount and transcount (IC_MaxCount and IC_TransCount) to be typed as 'int24', meaning _signed_!

So apparently, we had a wraparound of IC_TransCount into negativity, and TransCount being less than zero (MaxCount) we didn't get any interrupts for the next 35+ hours.

Just as a warning to others (we're currently verifying our solution), either reset TransCount on every interrupt, or initialize MaxCount with -2^23 (0x800000) and see if that works...

FWIW,

Johan

[butzodaddy]

stzari wins the thread!  I think there are bugs in IC.  I am trying out PPA for this application instead.

Thanks for your help.

[stzari]

Hi,

I suppose this is on a Coldfire MCF523x ?

I'd suggest the following:
- check ETPU_CIER, ETPU_CISR and ETPU_CIOSR registers
- check the CPU Status Register; is IPL lower than the interrupt priority of the eTPU channel ?

HTH
  stzari