Nous utilisons les microcontrôleurs ATmega48 / 88/168/328 avec succès depuis de nombreuses années dans bon nombre de nos produits. Nous avons maintenant envisagé de passer des variantes A et PA à la nouvelle variante PB (parce que nous aurons besoin des broches, des minuteries et des UART supplémentaires dans les nouveaux produits, car c'est devenu moins cher, et parce qu'il semble que les anciennes variantes seront abandonnées), nous avons donc remplacé un ATmega328A par un ATmega328PB. Il semble se détraquer très souvent après des coupures de courant . De tels problèmes ne se sont jamais produits avec les anciennes variantes.

Des coupures de courant régulières sont normales pour l'utilisation de nos produits. Nous utilisons une alimentation à découpage (comme celle-ci ) réglée sur 5 V et des condensateurs dans la plage de 220 µF sur le VCC de l'ATmega, pour maintenir la SRAM en vie pendant des interruptions de courant de plusieurs minutes, pour stocker des états internes qui ne sont pas la mission critique mais augmente considérablement l'expérience utilisateur en étant instantanément disponible au redémarrage (ces états changent assez souvent pour rendre l'EEPROM inadaptée). Cela a toujours fonctionné.

Cependant, avec le nouveau ATmega328PB, après une coupure de courant, la puce se réinitialise sans qu'une condition de réinitialisation ne soit trouvée dans MCUSR, et l'horloge semble se détraquer.

• le détecteur de brunissement est réglé par fusible. Nous avons essayé tous les niveaux de carrosserie disponibles, le bug se produit sur chacun d'eux.
• nous utilisons 20 MHz externes, également réglés correctement par fusible.
• nous avons essayé 3 puces différentes, donc ce n'était pas une seule soudure ou une autre défaillance matérielle.

Après le bug, l'horloge se règle souvent à une vitesse 2,5 fois plus lente, indiquant que le processeur est synchronisé par l'oscillateur interne à 8 MHz. Cependant, le ralentissement est parfois d'environ 6x. Cela signifie qu'il ne peut pas s'agir d'un bug logiciel modifiant le diviseur d'horloge, car je ne peux pas régler les fusibles à partir du logiciel, et le diviseur d'horloge ne peut pas diviser l'horloge par 2,5 ou par 6.

Donc, mon premier suspect était le nouveau fusible de détection de défaillance d'horloge. Cependant, peu importe s'il est activé ou désactivé, le comportement reste le même.

Pour exclure les particularités du logiciel, j'ai écrit un programme de test simple à partir de zéro, qui ne fait rien d'autre que basculer une sortie à 100 Hz à partir d'une interruption de minuterie, et indique avec des LED après chaque redémarrage quelles conditions de réinitialisation ont été activées (comme lu sur MCUSR). Le reste du matériel a également été retiré, seuls le mcu et le régulateur sont là (et les voyants avec résistances série).

Les resultats

Environ 2/3 du temps, rien d'intéressant ne se produit. Après l'interruption de l'alimentation, le mcu reprend son travail, les voyants de réinitialisation de panne de courant et de réinitialisation de mise sous tension s'allument.

(sur l'image, le rouge est la broche basculée et le bleu est VCC. Sur cette image, le bronzage 2,7 V est clairement visible. J'ai fait les mêmes tests avec les autres paramètres de brunissement, les résultats sont exactement les mêmes, donc je vais omettre ces photos)

Environ 1/3 du temps, le bogue susmentionné se produit, et lorsque le courant est de nouveau rétabli , aucun des indicateurs de réinitialisation et de réinitialisation à la mise sous tension n'est allumé! La sortie est différente, comme si le processeur fonctionnait avec une horloge étrange. Ce n'est pas chaotique, cependant, il continue de fonctionner avec la même fréquence.

Fait intéressant, dans cette situation, le détecteur de brunissement semble être complètement inactif, car après la prochaine coupure de courant (où l'horloge correcte est parfois rétablie, parfois non), il est clairement visible que la sortie continue de basculer bien après le brun. le niveau a été dépassé. Dans de telles situations, l'horloge devient parfois plus rapide, d'autres fois elle ralentit:

Lors de ces tests, j'ai utilisé 16K CK / 14CK + 4,1 ms pour le délai de démarrage (mais le délai de 65 ms n'évite pas les problèmes).

Voici une image zoomée, où vous pouvez clairement voir que le VCC atteint un état stable à 5 V en moins de 2 ms:

Dans l'image ci-dessus, le MCU a démarré correctement.

Fait intéressant, quand ce n'est pas le cas, la tension d'alimentation atteint un 5 V stable encore plus tôt (il semble que de nombreuses parties du MCU ne s'allument pas, donc il consomme moins de courant lors du démarrage)

Ci-dessous, une image d'un démarrage infructueux:

Veuillez noter que le logiciel commence à fonctionner après plus de 85 ms après stabilisation de la tension d'alimentation, au lieu des 10,5 ms requis autrement. Les fusibles pour le délai de démarrage sont toujours les mêmes, 16K CK / 14CK + 4,1 ms.

Ce qui est également intéressant à noter, c'est qu'après la coupure de l'alimentation, le VCC se stabilise autour de 1,1 à 1,2 Volt (l'ancienne variante ATmega328A est tombée à environ 0,6 - 0,7 V). Il garde cela pendant plusieurs minutes. Si j'attends assez longtemps (de l'ordre d'une demi-heure ou plus), le mcu démarre toujours correctement! Il semble donc que le problème soit qu'il y ait 1,1 Volt autour, ce qui, selon la fiche technique, n'est pas garanti pour être réinitialisé à la mise sous tension. Mais cela devrait suffire pour une réinitialisation du brownout!

À l'exception de ces situations, le détecteur de brunissement fonctionne correctement. Il est visible sur la première image (le signal de sortie s'arrête lorsque le niveau corporel a été atteint, et la chute de tension ralentit, car certaines parties du processeur sont arrêtées). J'ai fait des tests lorsque j'ai réduit le VCC à un niveau légèrement inférieur au niveau de la carrosserie et que je l'ai laissé remonter à nouveau, le mcu a toujours redémarré correctement dans de telles conditions, seul l'indicateur de réinitialisation de brunissement étant allumé.

Ai-je raté quelque chose d'évident, ou l'ATmega328PB a-t-il un bug sérieux dans son détecteur de brunissement?

ÉDITER:

Fait intéressant, les problèmes ci-dessus ne surviennent que lorsque j'interrompt l'alimentation devant le régulateur. Si je l'interromps après le régulateur (ou si j'utilise une alimentation de laboratoire), les problèmes ne se produisent jamais. Comme si la forme de la tension croissante causait les problèmes. Cependant, comme vous pouvez le voir sur la dernière image, la montée en tension est assez agréable et se stabilise rapidement.

EDIT 2

Je l'ai essayé avec 16 MHz au lieu de 20 MHz, mais les mêmes problèmes se produisent.

Je ne pense pas que ce soit un bug avec le détecteur de brunissement, mais comment vous utilisez la puce.

Comme vous l'avez dit vous-même, le seuil de réinitialisation à la mise sous tension 1,1 V n'est pas atteint si l'alimentation est juste brièvement coupée et connectée, il n'y aura donc pas de POR.

Le détecteur de brunissement ne peut pas non plus aider beaucoup ici. Vous utilisez l'AVR à 20 MHz, et cela nécessite une tension d'alimentation de 4,5 V ou plus, ou vous violez les spécifications. Et le BOD ne garantit pas qu'il se déclenchera à 4,5 V, il est généralement inférieur à cela, disons 4,3 V. Donc, même avant que le BOD ne se déclenche, il n'y a aucune garantie dans quel état l'AVR se termine, mais le BOD devrait se déclencher, sauf qu'il peut ne fonctionne pas en raison de votre horloge de 20 MHz. Lorsque la tension recommence à augmenter, la DBO se désactive avant que la tension d'alimentation ne soit à nouveau à un niveau sûr de 4,5 V. S'il s'est déclenché correctement. La temporisation de démarrage doit ensuite être réglée sur une valeur suffisamment élevée pour que la tension passe d'un niveau de désactivation de DBO à 4,5 V avant que la réinitialisation interne ne soit libérée.

Mais tout cela peut échouer car il a juste besoin d'au moins 4,5 V pour fonctionner à 20 MHz. La fiche technique de l'AVR mentionne que si le système de réinitialisation interne ne convient pas, utilisez une puce de réinitialisation externe, et dans ce cas, il semblerait que cela résoudrait vos problèmes pour réinitialiser l'AVR avant que la tension ne tombe à 4,5 V.