Je n'ai jamais eu affaire à des pièces défectueuses du digikey, mais 3 nouveaux Atmel ATmega164A que j'ai reçus ont présenté un comportement extrêmement étrange.
Je l'ai réduit à quelque chose à voir avec l'horloge et il s'est avéré que le signal d'horloge résultant de l'oscillateur interne soi-disant "calibré en usine" oscillait entre 650 et 700 kHz au lieu du 1 MHz solide qu'il est censé être. J'ai pu écrire dans l'octet d'étalonnage pour obtenir ce très proche de 1 MHz (toujours avec une gigue) et la plupart des choses fonctionnent mais les UART ne se comportent pas correctement, ils semblent produire un flux continu d'impulsions courtes, peu importe ce que vous leur demandez de faire.
J'ai traité la version basse consommation de ce microcontrôleur auparavant (164P) avec aucun problème et j'ai décidé de le laisser en place et de vérifier la sortie d'horloge à ce sujet, et c'est un solide 1 MHz sans gigue. Je penche vers la conclusion que ces puces 164A sont défectueuses, mais y aurait-il d'autres tests que je pourrais essayer de confirmer?
Edit: Je pensais juste que je décrirais le processus par lequel je mesure l'horloge. J'ai activé le bit de fusible de sortie d'horloge et mesuré la broche appropriée avec un échantillonnage d'analyseur logique à un taux très élevé. J'ai un programme qui écrit dans le registre d'étalonnage OSCCAL
et j'ai pu faire des essais et des erreurs sur 1 MHz.
Edit # 2: Après une enquête plus approfondie, il semble que le microcontrôleur commence à agir après une certaine taille de programmeseuil. Un projet simple avec un fichier source unique faisant clignoter une LED semble être OK, mais la compilation et la liaison dans l'un de mes autres fichiers (par exemple la bibliothèque UART ou autre) sans même appeler de fonction à ces méthodes fait que le microcontrôleur se comporte le comportement décrit ci-dessus. Les connexions électriques sont correctes et un découplage correct a été effectué. Je n'ai pas le temps de déboguer davantage pour le moment, nous avons donc plutôt opté pour la version basse consommation. Je ne sais pas exactement où le problème pourrait être soit 1) 164A et 164P ne sont pas compatibles avec le code 2) La procédure de programmation est différente pour ces deux uC 3) Les unités sont défectueuses. Je suis confiant dans la conception de notre carte et exclurais les problèmes d'alimentation. Malheureusement, je ne peux pas vraiment choisir une bonne réponse, je vais donc laisser cette question telle quelle - peut-être que je ' Je reviendrai sur le problème à l'avenir. Merci à tous ceux qui ont fourni des commentaires ou des réponses perspicaces, ils pourraient être utiles à quelqu'un d'autre avec des problèmes uC prêts à l'emploi.