In vielen unserer Produkte setzen wir seit vielen Jahren erfolgreich ATmega48 / 88/168/328-Mikrocontroller ein. Wir haben jetzt überlegt, von den A- und PA-Varianten auf die neue PB-Variante umzusteigen (weil wir die zusätzlichen Pins, Timer und UARTs in neuen Produkten benötigen, weil es billiger geworden ist und weil es so aussieht, als würden die alten Varianten eingestellt). Also haben wir einen ATmega328A gegen einen ATmega328PB ausgetauscht. Nach Stromunterbrechungen scheint es sehr oft durcheinander zu kommen . Solche Probleme traten bei den alten Varianten nie auf.

Regelmäßige Stromunterbrechungen sind für den Einsatz unserer Produkte normal. Wir verwenden ein Schaltnetzteil (wie dieses ), das auf 5 V eingestellt ist, und haben Kondensatoren im Bereich von 220 µF am VCC des ATmega, um den SRAM für Stromunterbrechungen im Bereich von mehreren Minuten am Leben zu halten und interne Zustände zu speichern, die keine Mission sind kritisch, aber die Benutzererfahrung erheblich verbessern, indem sie bei einem Neustart sofort verfügbar ist (diese Zustände ändern sich häufig genug, um das EEPROM ungeeignet zu machen). Das hat immer funktioniert.

Beim neuen ATmega328PB wird der Chip jedoch nach einer Stromunterbrechung zurückgesetzt, ohne dass in MCUSR eine Rücksetzbedingung gefunden wird, und die Uhr scheint durcheinander zu sein.

• Der Brown-Out-Detektor wird pro Sicherung eingestellt. Wir haben alle verfügbaren Bodlevel ausprobiert, der Fehler tritt bei allen auf.
• Wir verwenden externe 20 MHz, die ebenfalls pro Sicherung korrekt eingestellt sind.
• Wir haben 3 verschiedene Chips ausprobiert, es war also kein einziger Löt- oder anderer Hardwarefehler.

Nachdem der Fehler aufgetreten ist, stellt der Takt häufig die 2,5-fach langsamere Geschwindigkeit ein, was darauf hinweist, dass die mcu vom internen 8-MHz-Oszillator getaktet wird. Manchmal beträgt die Verlangsamung jedoch etwa das 6-fache. Dies bedeutet, dass es kein Softwarefehler sein kann, der den Taktteiler ändert, da ich die Sicherungen nicht über die Software einstellen kann und der Taktteiler die Uhr nicht durch 2,5 oder 6 teilen kann.

Mein erster Verdächtiger war also die neue Sicherung zur Erkennung von Taktfehlern. Unabhängig davon, ob es ein- oder ausgeschaltet ist, bleibt das Verhalten gleich.

Um Software-Besonderheiten auszuschließen, habe ich ein einfaches Testprogramm von Grund auf neu geschrieben, das nichts anderes tut, als einen Ausgang mit 100 Hz von einem Timer-Interrupt umzuschalten und nach jedem Neustart mit LEDs anzeigt, welche Rücksetzbedingungen aktiviert wurden (wie von MCUSR gelesen). Der Rest der Hardware wurde ebenfalls entfernt, nur die mcu und der Regler sind vorhanden (und die Anzeigelatten mit Vorwiderständen).

Die Ergebnisse

Etwa 2/3 der Zeit passiert nichts Interessantes. Nach der Stromunterbrechung nimmt das mcu seine Arbeit wieder auf. Sowohl die Anzeige für das Zurücksetzen des Brown-Outs als auch das Zurücksetzen beim Einschalten leuchten auf.

(Auf dem Bild ist Rot der umgeschaltete Stift und Blau ist VCC. Auf diesem Bild ist der 2,7-V-Bronwn-Out deutlich sichtbar. Ich habe die gleichen Tests mit den anderen Brown-Out-Einstellungen durchgeführt. Die Ergebnisse sind genau die gleichen. also werde ich diese Bilder weglassen)

In etwa 1/3 der Fälle tritt der oben genannte Fehler auf, und wenn die Stromversorgung wieder hergestellt ist, leuchtet keine der Anzeigen für Brown-Out-Reset und Power-On-Reset auf! Die Ausgabe ist anders, als ob das mcu mit einer seltsamen Uhr tickt. Es ist nicht chaotisch, aber es tickt mit der gleichen Frequenz.

Interessanterweise scheint in dieser Situation der Brown-Out-Detektor vollständig inaktiv zu sein, da nach der nächsten Stromunterbrechung (bei der die korrekte Uhr manchmal wiederhergestellt wird, manchmal nicht) deutlich zu erkennen ist, dass der Ausgang nach dem Brown-out weiter gut umschaltet. out level wurde bestanden. In solchen Situationen wird die Uhr manchmal schneller, manchmal langsamer:

Während dieser Tests habe ich 16K CK / 14CK + 4,1 ms für die Startverzögerung verwendet (aber die 65 ms Verzögerung vermeidet die Probleme nicht).

Hier ist ein vergrößertes Bild, in dem Sie deutlich sehen können, dass der VCC in weniger als 2 ms einen stabilen Zustand bei 5 V erreicht:

Im obigen Bild wurde das mcu korrekt gestartet.

Interessanterweise steigt die Versorgungsspannung, wenn dies nicht der Fall ist, noch früher auf stabile 5 V an (es scheint, dass sich viele Teile des mcu nicht einschalten lassen, sodass während des Startvorgangs weniger Strom verbraucht wird).

Unten ist ein Bild von einem erfolglosen Start:

Bitte beachten Sie, dass die Software nach mehr als 85 ms nach Stabilisierung der Versorgungsspannung startet, anstatt nach den sonst erforderlichen 10,5 ms. Die Sicherungen für die Startverzögerung sind immer noch dieselben, 16K CK / 14CK + 4,1 ms.

Interessant ist auch, dass sich der VCC nach dem Ausschalten der Versorgung bei etwa 1,1 bis 1,2 Volt stabilisiert (die alte ATmega328A-Variante ging auf etwa 0,6 bis 0,7 V zurück). Das hält es einige Minuten lang. Wenn ich lange genug warte (in der Größenordnung von einer halben Stunde oder länger), startet das mcu immer richtig! Das Problem scheint also zu sein, dass 1,1 Volt in der Nähe sind, was laut Datenblatt nicht garantiert für einen Power-On-Reset ausreicht. Aber es sollte für einen Brown-Out-Reset ausreichen!

Mit Ausnahme dieser Situationen funktioniert der Brown-Out-Detektor einwandfrei. Es ist auf dem ersten Bild sichtbar (das Ausgangssignal stoppt, wenn der Bodlevel erreicht wurde, und der Spannungsabfall verlangsamt sich, wenn Teile des mcu abgeschaltet werden). Ich habe Tests durchgeführt, als ich den VCC auf etwas unterhalb des Bodlevels reduziert und wieder zurückklettern ließ. Unter solchen Bedingungen wurde der mcu immer korrekt neu gestartet, wobei nur die Brown-Out-Reset-Anzeige aufleuchtete.

Habe ich etwas Offensichtliches verpasst oder hat der ATmega328PB einen schwerwiegenden Fehler im Brown-Out-Detektor?

BEARBEITEN:

Interessanterweise treten die oben genannten Probleme nur auf, wenn ich die Versorgung vor dem Regler unterbreche. Wenn ich es nach dem Regler unterbreche (oder ein Labornetzteil benutze), treten die Probleme nie auf. Als ob die Form der ansteigenden Spannung die Probleme verursacht hätte. Wie Sie auf dem letzten Bild sehen können, ist der Spannungsanstieg jedoch recht gut und stabilisiert sich schnell.

BEARBEITEN 2

Ich habe es mit 16 MHz statt 20 MHz ausprobiert, aber genau die gleichen Probleme treten auf.

Ich denke nicht, dass es ein Fehler mit dem Brown-Out-Detektor ist, aber wie Sie den Chip verwenden.

Wie Sie selbst sagten, wird der Schwellenwert für das Zurücksetzen beim Einschalten von 1,1 V nicht erreicht, wenn die Stromversorgung nur kurz unterbrochen und angeschlossen wird, sodass kein POR auftritt.

Auch hier kann der Brown-out-Detektor nicht viel helfen. Sie verwenden den AVR mit 20 MHz, und dafür muss die Versorgungsspannung 4,5 V oder mehr betragen, oder Sie verstoßen gegen die Spezifikationen. Und BOD garantiert nicht, dass es bei 4,5 V auslöst, es ist normalerweise weniger als das, sagen wir 4,3 V. Selbst bevor BOD ausgelöst wird, gibt es keine Garantie dafür, in welchem ​​Zustand der AVR endet, aber der BOD sollte auslösen, außer dass dies möglich ist funktioniert aufgrund Ihres 20-MHz-Takts nicht. Wenn die Spannung wieder ansteigt, wird der BSB deaktiviert, bevor die Versorgungsspannung wieder einen sicheren Wert von 4,5 V erreicht. Wenn es richtig ausgelöst wurde. Die Startverzögerungszeit sollte dann so hoch eingestellt werden, dass sich die Spannung ändert, um vom BSB-Deaktivierungspegel auf 4,5 V zu steigen, bevor der interne Reset freigegeben wird.

Es kann jedoch alles fehlschlagen, da für den Betrieb mit 20 MHz nur mindestens 4,5 V erforderlich sind. Im AVR-Datenblatt wird erwähnt, dass bei einem ungeeigneten internen Rücksetzsystem ein externer Rücksetzchip verwendet werden muss. In diesem Fall scheint es Ihre Probleme zu lösen, den AVR zurückzusetzen, bevor die Spannung auf 4,5 V abfällt.