Since this happened a week ago, I'm not certain I can
reproduce it, but I was wondering if anyone had seen this
before. I didn't get a chance to write this up until today.

A coworker and I have been working on a PIC16C76-based
circuit, and we noticed something odd -- the values
returned in ADRES would be erratic if the AD clock was set
to run at a low speed. We were running at 4MHz and the AD
clock was set to 32Tosc, so the AD should have had 8us to
do the conversions; the data sheet suggested a minimum of
1.6us was required. The problem went away when I changed
the AD clock to 8Tosc, which gave a conversion time of 2us.

We had the thing in a big loop, doing a variety of
stuff. We only had a single A/D input, and neither A/D
conversion time nor power consumption was an issue, but
access to a recent result when needed was an issue. So each
time through the loop, we'd check the GO/DONE bit. If it
was clear, we'd copy the result to a file register and
set GO again. If it was set we'd just go on and do the
rest of the event loop and check later.

What was hapenning was that each time the conversion
completed we'd get a different answer, even if the input
didn't change. All the TRIS and ADCON settings were checked
and triple-checked, and they were right. In one case, we
called a bunch of code in the loop, and the result would
be quite erratic and eventually would just get stuck at an
erronious result. In another, we commented out the call
to a big part of the code; then the result would cycle
through three different values, only one of them valid. We
only commented out the goto, not the code itself, so there
was only one line changed (this was being done in MPASM)
but it resulted in a whole bunch of dead code. Curiously,
if some different code that did nothing but the A/D
conversion was used, the results were the normal,
as-expected value.

My co-worker tried it on the Picmaster, and there seemed
to be no explanation for it. So I took it and put it
on the Clear View Matthias, and it didn't see anything,
either. My CVM has the advanced PIC16Cxx module, so I set
data breakpoints on ADRES and ADCON.  Nothing in the big
loop ever touched the AD subsystem, as far as I could
tell; the only things that ever messed with the AD was
the code we were focusing on.  (The big loop is the emWare
emMicro code, and a bunch of it is still a mystery to us,
not having read it all; there *is* AD stuff in the emWare
code but it had been disabled). After staring at it in the
CVM for a couple of hours, I finally just made a total
wild-ass guess and changed the AD clock to 8Tosc from
32Tosc. The problem went totally away. No other changes
had to be made to the code to fix the problem.

It seemed as if something burried in the AD subsystem was
being affected by the amount of code that was executed
in the loop. Interrupts were enabled, but not for the AD
subsystem, and the CVM never showed the PIC taking the
ISR path. I don't think that it was the CVM, because the
same thing happened on the Picmaster (I suppose it could
be a bondout glitch). We never tried it with a real 16C76.

Has anyone ever seen this or its like before?

Thanks,
--Bob

--
============================================================
Bob Drzyzgula                             It's not a problem
bob@drzyzgula.org                until something bad happens
============================================================