How do you determine if a new microcontroller is defective?

Question

I've never dealt with parts being defective strait from digikey, but 3 new Atmel ATmega164A's that I've received have been exhibiting extremely odd behaviour.

I narrowed it down to something to do with the clock and it turned out that the resulting clock signal from the supposedly "factory calibrated" internal oscillator was jittering between 650-700 kHz instead of the solid 1 MHz it's supposed to be. I was able to write in to the calibration byte to get this very close to 1 MHz (still with some jitter) and most things work but the UARTs just don't behave properly, they seem to output a continuous stream of short pulses no matter what you ask them to do.

I've dealt with the low power version of this microcontroller before (164P) with zero issues and decided to drop it in place and check the clock output on that, and its a solid 1 MHz with no jitter. I'm leaning towards the conclusion that these 164A chips are defective, but would there be any other tests I could try to confirm that?

---

Edit: Just thought I'd describe the process by which I'm measuring the clock. I've enabled the clock output fuse bit and measured the appropriate pin with a logic analyser sampling at a very high rate. I have a program which writes in to the calibration register OSCCAL and I've been able to trial & error my way to 1 MHz.

---

Edit #2: After further investigation, it appears that the microcontroller starts acting up after a certain program size threshold. A bare-bones project with a single source file flashing an LED seems to be OK, but compiling and linking in any of my other files (say UART library or whatever) without even making a function call to those methods causes the microcontroller to behave in the described behaviour above. Power connections are fine and proper decoupling has been exercised. I don't have time to debug this any further at the moment, so we've gone ahead with the low power version instead. I am unsure where exactly the problem could be either 1) 164A and 164P are not code compatible 2) Programming procedure is different for these two uC's 3) Units are defective. I am confident in our board design and would rule out power issues. Unfortunately, I can't really pick a correct answer so I'll leave this question as is - maybe I'll come back to the problem again in the future. Thanks to everyone who provided insightful comments or answers, they might serve useful to someone else with uC issues out of the box.

Answer 1

It is rare to have that kind of failure. You might expect to see a little more noise on a pin, or have that pin completely non-functional. But to have it "somewhat work, but not in a useful way" is rare. I would suspect there are design issues that are causing the problems, and have something to do with a difference between the 164A and 164P. Since jitter is high, I would look at power related things. Are all the power/gnd pins connected? Are are the I/O pins either driven or pulled high or low? Etc.

But there still remains the possibility that the parts are bad. It's rare, but not unheard of. The only real way to tell is to get some more parts, from a different supplier, and try them. If they work, then you need to investigate further and see if you killed them in handling/soldering or if they really did come from Digikey bad.

Answer 2

I once had a very similar issue with baseline Microchip parts. We were messing up the ICSP programming and were finding a way to erase the oscillator trim, causing gross errors in the accuracy of the internal clock. Make sure that your programming fixture and/or programming tools are being connected correctly and are being used correctly.

There's no easy way to verify the accuracy of the oscillator without programming the parts, so I'd just write a trivial port-toggle program (one that doesn't do anything but wiggle an I/O line) and have someone else program the parts, preferably with different programming hardware. Once you verify the wiggle, you can reflash with your own code and see if the issue persists.