32 bit input capture 9S08JM60

[TurboBob]

Hello everyone,  and happy holidays.

I am trying to extend the range of my input capture.  In the past I have used all sorts of work-arounds to use the 16 bit input to read a very wide range of frequencies.  I am hoping there is a more elegant way.

What I have done so far is to use the TPM overflow interrupt to increment an unsigned int.  Then when an input capture occurs,  I make a 32 bit register using the overflow counter as the high word.

Calculating the delta is a simple matter, and I have a 32 bit input capture.

This works 99% of the time, but I am getting stray errors in the captures.  I assume it is related to the non-synchronoous increment of the overflow counter, so I my calculations are wrong when the main TPM counter overflows, and a capture occurrs before the overflow interupt can increment the counter.

I vaguely remember an app note regarding counting overflows,  but I can't find it.

A 32 bit capture makes all my other software requirements easier.  So I am hopeful that the internet-wisdom can help me here.

I would change the TPM rate,  but I am doing some other stuff that requires a 50hz PWM,  so I am a bit locked in.

Switching up to the larger Flexis part is not possible at this point.  I finally have the USB working decently...

Thanks in advance for your attention

Bob Bailey

N8DRK

[peg]

Hello Bob,

It would seem to me that your problems are indeed caused by the input capture and the timer overflow occurring at almost the same time.
This is what is covered by the reference kef has provided.
Note that there can be an issue both at the start and finish of your period.
The overflow can occur just before the input capture but due to the lower priority of the overflow interrupt it can cause the overflow to be included in the start time.
The amount of time by which the overflow can happen before the capture and still produce an erroneous capture can be up to the execution time of the longest "other" isr (or even multiple coincident isrs)

As an example:
Due to the asynchronous nature of the input capture to the timer, every so often the capture will occur close to the overflow. If just before this "dual event" occurs another isr is started and its execution occurs over the top of the two timer events then when that isr is completed the two timer isrs will be pending. Due to the priority scheme used the capture isr will always be executed first irrespective of which event occurred first.

There is a very similar problem at the end of the measured period.
This is when the overflow occurs just before the capture again, but this time the oveflow that should be recorded is not.

The example referenced shows how to compensate for both of these events. It is written in HC11 but you can understand what they are doing just by reading the comments.



Message Edited by peg on 2008-12-30 09:22 AM

[TurboBob]

Thanks guys, that was one of the app notes I was looking for.  The other note was for something related to an overflow interrupt happening at 0xFFFF,  not at roll-over.  This may have been an old HC05 note and may not be applicable here.


At any rate, I did a bunch of work related to 'sanity checking' the register extension results, and still had glitches.  For some reason my True-Time connection will not stop at breakpoints any more.  So I am not able to stop the machine and inspect the results.  I was going to trap data in a global variable, but am running out of time to solve this.

So I had to go back to my old methods of 16 bit workarounds.  It works well enough.

The breakpoint issue may be related to an update that occurred when I installed CW6.2.   I am still using CW6.1, since I am using the demo boards as BDM pods.  ( I have both 6.1 and 6.2 installed)

Again, thanks for the help.  If I develop a clean 32 bit general solution for this I will post it.

Bob


Message Edited by TurboBob on 2008-12-30 01:30 PM

[Ake]

Hi there,

I would do as follows:

Read the TPMxCNT to determine where the time equals 0 is.

Clear the Resulth and Resultl 16 bit words.

Use the TOF interrupts to count the number the TPMxCNT register overflows and store it in Resulth.

When the TPMxChy interrupt occurs, read the low 16 bit value from the TPMxCnV register and store it in Resultl.

The 32 bit result will be in Resulth:Resultl.

Notice that if the clock is running at 20 MHz, the overflow interrupt will only occur with 20 MHz/65536 = 305 Hz or every 3.2 ms which is not very often.

Regards,

Ake

[kef]

HC11 reference manual explains that in detail.

http://www.freescale.com/files/microcontrollers/doc/ref_manual/M68HC11RM.pdf

See  10.5.5 Measuring Long Time Periods with Input Capture and Overflow