Kerry Wentworth wrote:
> The customer got 6
> free samples of  16F877As in the 44 pin SM package.  I designed a PC
> board and built 6, using 20MHz ceramic resonators with built-in caps,
> as I normally do.
> ...
> After exhaustive testing without results, I replaced a 20MHz resonator
> with a 4MHz resonator, and it suddenly worked.  An 8MHz resonator also
> worked.  But not a 20!  The leads for the resonator were as short as
> practical, as I have had trouble at 20MHz if the leads are too long.
>
> At the time, that was all the proof I needed.  If you need more, I can
> always send you a couple of the chips and a copy of the artwork.  I
> don't think it is worth the effort, and my point is "Be aware that
> free samples may not be prime parts".

You are jumping to conclusions, which further erodes your credibility.  You=
r
evidence is hardly proof for the conclusion that "free samples may not be
prime parts".  I seriously doubt that Microchip bins slightly out of spec
parts to be sent out as free samples.  That would defeat their purpose, and
would cost more in logistics.

A more likely possibility is that you got a bad batch of 20MHz resonators,
or they were weak to begin with.  Resonators are usually weaker than
crystals, and 20MHz is on the high end for resonators.  Did you try with a
ordinary 20MHz crystal or a different model of resonator?  Did you look at
the resonator specs carefully?

Another possibility is that you had a bug such that XT instead of HS
oscillator mode was selected.  That will work at lower frequencies, but fai=
l
at higher, just like you saw.  You were using a "less than professional"
programmer to begin with, and then modified its code on top of that, so do
you really know the oscillator setting was set in the PIC as it was intende=
d
in the code?  Did you actually read back the config word to check?

Also I suspect this programmer you used wasn't a production programmer in
that it didn't read back at the Vdd limits.  That matters for older parts
like the 16F877.  I don't remember whether it applies to the A version, but
I would do the double readback unless it explicitly said it wasn't needed.
How do you know your flakeware programmer didn't cut short the programming
time or something, and the bits weren't really all there?

In short, it's far more likely you screwed up in any of several way rather
than you got bad PICs as samples.  Your jumping to conclusions when other
more likely explanations are possible makes it difficult to trust your othe=
r
conclusions, such as that your testing was "exhaustive".  Most likely you
missed something, probably one of the things I mentioned above.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.