Friday, 8 December 2017

avr - How do you determine if a new microcontroller is defective?


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.




No comments:

Post a Comment

arduino - Can I use TI's cc2541 BLE as micro controller to perform operations/ processing instead of ATmega328P AU to save cost?

I am using arduino pro mini (which contains Atmega328p AU ) along with cc2541(HM-10) to process and transfer data over BLE to smartphone. I...