William Hubbard wrote:

...

>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?


This delays roughly 10=B5s:

Signal -> o---[10k]--*---> Target PIC
                     |
               1nF  =3D=3D=3D
                     |
                    GND=20

=20
>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.

Then, maybe it can happen that the flag gets set before counter is securely=
 latched, and if you are testing the flag at the same time you branch to the=
 storing routine you might jump faster than possible with interrupt routine=
 (mybe the interrupt fires only next cycle...?) ...  I think not, but... Try=
 adding a nop between checking the flag and jumpig to storing routine and=
 see if there is any difference.  Als try use interrupt and see if it is the=
 same.  If you don=B4t want it to interrupt enything else, just only shortly=
 enable it in the same place you now poll the flag.

Also, check if you are using a late silicon.  Some manufacturers don=B4t=
 list all bugs in erratas, but fix them anyway in next silicon release.  For=
 example i detected one switch in A/D clock in PIC14000 was wrong in my=
 earliest batch, but fixed in the next.  Never reported by Mchip, and i=
 never got an answer when i asked either :( they just fixed it silently=
 while i was pulling my hair out.  Same for a readout bug in early LTC2400.
New digital chips often burn my schedule...

Try making a nice test bench to really hammer on this with variable delay=
 etc.

After 2 months with 6 pages of data i managed to make Maxim admit a bug in=
 MAX110/111...
What a waste of time

Sorry i had to get something off my nerves...

/Morgan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body