I am working on a project that involves a PIC16F628 and I am seeing a
problem that made me curious if anyone had noticed before or was aware
of.  I'm 99.999% certain it is not my code, but haven't written a test
bench, yet, to verify this.

I am sampling an input signal using the CCP (capture) feature, and when the
capture occurs, I read the captured values from CCPR1H and CCPR1L registers
and save them into another set of variables.  When another capture event
comes along, I capture the CCPR1H & L values and subtract the previously
saved values from them.

What is happening is that when the low byte of the counter rolls over
(incrementing the high byte), it appears that sometimes the CCPR1H register
has the value of TMR1H before the roll-over, and CCPR1L has the TMR1L value
after the rollover (i.e. the capture is not correctly recording the timer 1
values), giving me an error of [theoretically] up to 256 counts off in my
resulting value.  For example, if the timer rolls over from 0x14FF to
0x1500, I might get a read of 0x1400 instead of 0x1500.  If my previous
sampled value was 0x14F3, then instead of getting a difference of 13, I get
a difference of 243.

This does not happen at every point where the low byte rolls over, which is
why it does not appear to be a code problem (yes, I am properly checking
for borrow), and since all other resultant values are valid near the
threshold, it leads me to suspect it is a hardware problem with the
'628.  The problem is most prevalent when timer 1 changes from 0x14FF to
0x1500, or from 0x0EFF to 0x0F00, or from 0x11FF to 0x1200.  The total
range of signal values in my application can span from 0x0B07 to 0x189C,
and I do not see this problem occurring across any byte boundaries other
than what I listed above.

Perhaps one important factor to mention here is that the CCP input is being
triggered by another PIC that is running in sync with this PIC.  I am
thinking that perhaps the timing of the signal is just too close,
internally, to when and how the PIC rolls over the timer bytes vs. when and
how the capture is performed, that perhaps I am stumbling over an extremely
rare situation that is prominent in this application only because the
timing is in sync.  Is there a way I can use a capacitor or something to
delay the trigger signal ever so slightly to see if this makes any difference?

Bill Hubbard
P.S. I am running the PICs at 12MHz and the input signal is very
predictable (and controllable) and I am polling the interrupt flag rather
than using an interrupt handler to know when a capture has occurred.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.