ATMEL 169PA se réinitialise avec MCUSR = 0

user20416

ATMEL 169PA se réinitialise avec MCUSR = 0


En de rares occasions, mon ATMega169PA se réinitialise avec MCUSR = 0. Qu’est-ce qui peut provoquer cela?

J’ai plusieurs unités (> 500) exécutant le même code et en de rares occasions, 1 ou 2 unités seront réinitialisées avec MCUSR = 0.

Gustavo Litovsky

Nous aurons besoin de beaucoup plus d’informations. Comment savez-vous qu’il redémarre? L’avez-vous effacé accidentellement avant qu’il ne soit lu?

user20416

J’ai un écran LCD qui clignote et affiche la valeur MCUSR lorsque l’appareil se réinitialise. Toutes les autres réinitialisations telles que JTAG, Watchdog, Power On, External et Brown out ont été testées individuellement et affichées à l’écran mais 1-2 unités aléatoires affichent la valeur 00. Les pannes se produisent lorsque les unités sont placées dans une chambre de température réglée à -30 ° C pendant environ 5 jours.

Gustavo Litovsky

Je suis étonné que vous ayez gardé le fait de la chambre à température froide de la question initiale. Il s’agit d’une information cruciale qui change la réponse.

Chris Stratton

Cela semble être une bonne question pour le site: alors que plus d’informations seraient bien, la réalité est que le problème dans des situations telles que celle-ci est que l’ingénieur sur place ne sait pas pourquoi le comportement se produit et cherche de l’aide auprès de ceux-ci. avec plus d’expérience dans la recherche de tels problèmes. C’est le type de question qui va probablement nécessiter des allers-retours d’idées dans les commentaires pour résoudre, mais c’est ainsi que l’ingénierie est finalement pratiquée.

David G

Avez-vous déjà complètement résolu ce problème? J’ai un problème similaire avec un ATMega168PB qui semble se réinitialiser en raison de RF à proximité (non intentionnelle).

Réponses


 jippie

De temps en temps j’oublie de lier le

RÉINITIALISER¯

broche à Vcc, résultant en des réinitialisations aléatoires. Utilisez une résistance de 10k si vous voulez pouvoir faire une programmation en circuit, sinon vous pouvez enregistrer la résistance et relier directement la broche à Vcc.

user20416

La broche de réinitialisation a une traction de 2,2 K jusqu’à Vcc.

Chris Stratton

Cela pourrait expliquer une réinitialisation aléatoire, mais expliquerait-il une valeur MCUSR (cause de réinitialisation) de 0?

jippie

@ChrisStratton non, mais je voulais avoir une bonne raison d’utiliser le balisage MathJax pour le chevauchement comme dans


 PeterJ

Selon la fiche technique ATmega169P, le registre MCUSR a les valeurs suivantes au démarrage:

• Bit 4 – JTRF: indicateur de réinitialisation JTAG Ce bit est activé si une réinitialisation est provoquée par une logique dans le registre de réinitialisation JTAG sélectionné par l’instruction JTAG AVR_RESET. Ce bit est réinitialisé par une réinitialisation à la mise sous tension ou en écrivant un zéro logique dans l’indicateur.

• Bit 3 – WDRF: indicateur de réinitialisation du chien de garde Ce bit est défini en cas de réinitialisation du chien de garde. Le bit est réinitialisé par une réinitialisation à la mise sous tension ou en écrivant un zéro logique dans l’indicateur.

• Bit 2 – BORF: indicateur de réinitialisation de brunissement Ce bit est activé en cas de réinitialisation de brunissement. Le bit est réinitialisé par une réinitialisation à la mise sous tension ou en écrivant un zéro logique dans l’indicateur.

• Bit 1 – EXTRF: indicateur de réinitialisation externe Ce bit est activé en cas de réinitialisation externe. Le bit est réinitialisé par une réinitialisation à la mise sous tension ou en écrivant un zéro logique dans l’indicateur.

• Bit 0 – PORF: indicateur de réinitialisation à la mise sous tension Ce bit est activé en cas de réinitialisation à la mise sous tension. Le bit n’est réinitialisé qu’en écrivant un zéro logique dans le drapeau.

Dans le cas d’un problème d’alimentation, je m’attendrais à ce que le registre contienne une valeur d’un, ou si la broche de réinitialisation externe n’était pas attachée fermement, je m’attendrais à une valeur de deux. Si vous (ou le compilateur en question) utilisez la recommandation de lire et de réinitialiser le registre de près après le démarrage, je soupçonne que le microcontrôleur ne se réinitialise pas du tout.

Une cause plus probable est une erreur de code entraînant le retour de l’exécution du code au vecteur de réinitialisation ou à un point du code qui le fait apparaître comme si un redémarrage s’était produit. Le vecteur de réinitialisation est situé à l’adresse de programme zéro, donc tout saut vers cette adresse peut provoquer ce problème, mais sans voir le code, il est difficile à déterminer. C’est peut-être un cas extrême dans la séquence de code et / ou les séquences d’interruption qui ont tendance à se produire très rarement, ou cela peut dépendre des modèles d’utilisation des périphériques qui présentent le problème.

Aussi comme suggéré par jippie selon le compilateur, la dernière instruction après main (); est soit un rjmp.-2 soit un jmp 0x0000 donc si le programme parvient à quitter main (); alors le contrôleur peut montrer un comportement similaire.

user20416

J’utilise le compilateur GCC. J’espérais que le problème était une erreur de code mais avec> 500 unités fonctionnant dans le même environnement et les mêmes conditions, je devrais voir cette panne dans plus d’unités que 1-2 unités aléatoires. Ces échecs ne sont pas reproductibles, ce qui rend le débogage plus difficile.

Chris Stratton

Un comportement peu fréquent peut (entre autres possibilités) être causé soit par des chemins défectueux dans le programme qui ne sont déclenchés que par des situations inhabituelles (relations temporelles, entrées externes, comportement électrique) ou par des bruits / défauts électriques perturbant le bon fonctionnement du processeur. Envisagez de définir un piège en remplissant la mémoire inutilisée avec des sauts vers un code qui laissera la preuve d’un emballement (définissez une autre valeur, entrez dans une boucle produisant un caractère sur l’UART, peu importe).


 Gustavo Litovsky

Répondre directement à votre question nécessitera beaucoup plus d’informations. Comment savez-vous qu’il redémarre? L’avez-vous effacé accidentellement avant qu’il ne soit lu?

Sinon, cela indiquerait une remise sous tension où la tension chute en dessous de VPOT (comme spécifié dans la fiche technique). Je sens un problème matériel quelque part.

[Modifier] Compte tenu des nouvelles informations selon lesquelles l’unité est soumise à des températures très froides. Il est presque certain que certaines unités échouent probablement à cause de cela. Je contacterais Atmel avec les informations sur la puce défaillante (numéro de lot, date, etc. qui sont marquées sur l’appareil) et demander plus de conseils. Beaucoup avaient peut-être des problèmes. Le taux d’échec semble trop petit pour être un problème de PCB, mais pourrait définitivement être expliqué par certains appareils ne répondant pas à la spécification -40C.

user20416

Les unités défaillantes sont aléatoires et non répétables. J’ai un écran LCD qui clignote et affiche la valeur MCUSR lorsque l’appareil se réinitialise. Toutes les autres réinitialisations telles que JTAG, Watchdog, Power On, External et Brown out ont été testées individuellement et affichées à l’écran mais 1-2 unités aléatoires affichent la valeur 00. Les pannes se produisent lorsque les unités sont placées dans une chambre de température réglée à -30 ° C pendant environ 5 jours.

 

=, 0,, 169PA, Atmel, avec, MCUSR, réinitialise, se

 

google

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *