ATmega328P, das auf CR2032 läuft, hat Probleme mit dem Timing-/Sleep-Code, da die Spannung mit der Zeit abnimmt

Ich habe seit ungefähr einer Woche einen ATmega328P, der mit 16 MHz auf CR2032 mit ein paar Sensoren und Funk läuft. Es begann bei 3+ Volt und misst derzeit bei 2,96 Volt. Derzeit verwende ich keine Ladedruckregler, um dies zu regulieren. Ich verwende den Low-Power-Sleep-Modus mit den Jee Lib-Bibliotheken , schlafe für ein paar Sekunden, wache dann für weniger als eine Sekunde auf, nehme ein paar Messwerte, übertrage und schlafe wieder ein.

In letzter Zeit bemerkte ich, dass die Schlafdauer um einige Größenordnungen geschrumpft war. Es scheint ungefähr 50 Millisekunden lang zu schlafen, anstatt der 5-Sekunden-Schlafzeit, mit der es früher gearbeitet hat. Wenn ich auf 2xAA (2,84 Volt) umschalte, bekomme ich immer noch den vollen 5-Sekunden-Schlafzyklus.

Ist dieses Verhalten darauf zurückzuführen, dass der ATmega328P zurückschaltet, um die internen 8 MHz anstelle der externen 16 MHz zu verwenden? Sie sind sich auch nicht sicher, wie das Timing / der Schlaf mit 2xAA bei 2,84 Volt gut funktioniert, aber nicht mit CR2032 bei 2,96 Volt?

Anstelle des beabsichtigten Schlafs erleben Sie möglicherweise einen sich wiederholenden Zyklus von Spannungsabfällen und Zurücksetzen. Versuchen Sie, die Versorgungsspannung mit einem Zielfernrohr zu beobachten.

Antworten (2)

Ein paar Dinge. Wahrscheinlich misst du die Batterie ohne Last. Selbst wenn es angeschlossen und in Betrieb ist, erkennt ein Multimeter keinen schnellen Stromverbrauch. Ein Oszilloskop wird für Leistungsentnahmen im Millisekundenbereich benötigt. Denken Sie daran, dass CR2032s für den Langzeitgebrauch mit niedrigem Strom ausgelegt sind. 250mAh @ ein paar mA. Ihr Mikro und Ihre Sensoren, die aus dem Ruhezustand kommen, verursachen einen Einschaltstrom, und der hohe ESR (äquivalenter Serienwiderstand) des CR2032 verursacht einen Spannungsabfall. Haben Sie einen Entkopplungskondensator parallel in der Nähe der Stromanschlüsse?

Und Spannungsabfälle lassen den ATmega nicht auf eine langsamere Geschwindigkeit fallen. Das ist eine zu fortgeschrittene Funktion für die meisten niedrigen Mikros. Es wird weiterhin versuchen , bei 16 MHz mit einem instabilen Takt zu laufen. Brownouts sind wahrscheinlich.

Sie könnten den ATmega für alle Spannungen mit 8 MHz betreiben, um das Problem zu vermeiden, und Ihre Verzögerungen/Timer darauf basierend anpassen.

Danke für die Info. Ja, Spannungen wurden ohne Last gemessen. Ich habe ein paar Entkopplungskondensatoren ausprobiert - 1uF, 10uF (konnte keine 0,1uF bekommen), aber sie haben das Ausgangsverhalten nicht verändert. Ich verwende das Low-Power-Radio nrf24l01 + und den tmp36-Sensor. Sie scheinen einen sehr geringen Strombedarf zu haben. Derzeit führt ATmega328p-pu den Arduino Uno-Bootloader aus. Würden Sie zufällig wissen, dass ich, wenn ich den 8-MHz-Bootloader verwende, immer noch dieselben ATmega-Befehle verwenden könnte, die die Energiesparmodi verwenden ( jeelabs.net/pub/docs/jeelib/classSleepy.html )?
Sie sollten Ihre erwarteten Verzögerungszeiten einfach durch die Hälfte teilen und dann testen. (Die halbe Uhr, es dauert doppelt so lange, bis zur gleichen Zahl zu zählen)
Hier ein Artikel über ein Projekt mit einem CR2032 als Stromquelle: hackster.io/Talk2/…

Es sieht so aus, als würden Sie die MCU mit einer Knopfzelle außerhalb des sicheren Betriebsbereichs betreiben . Laut ATmega328P-Datenblatt , Seite 316, liegt die minimale sichere Versorgungsspannung für 16 MHz bei etwa 3,8 V (die roten Markierungen sind von mir). Sie sollten in diesem Fall mit unberechenbarem Verhalten rechnen. In der Praxis übertakten Sie nur Ihre MCU. Sehen Sie , was Russell McMahon dazu zu sagen hat .

ATmega328P sicherer Betriebsbereich

Was die Frage AA vs. Knopfzelle betrifft, so hat dies damit zu tun, dass AAs eine viel höhere Entladungsrate haben (AAs können einige Ampere liefern). Knopfzellen ( siehe Musterdatenblatt ) können bei kurzen Impulsen bis zu einigen mA liefern.

Danke für die Info. Mir war klar, dass es für diesen Test außerhalb der Spezifikation lag, aber die Ergebnisse schienen ein Muster zu haben, das sich von den Werten unterscheidet, die ich normalerweise erhalte, wenn ich die Spannungen weiter nach unten senke und einen Brown-Out erzwinge. Also versuchte ich herauszufinden, ob es versucht, herunterzuschalten und bei 8 MHz zu arbeiten, bevor es das Handtuch wirft.
Rechts. Wie Russel spöttisch in seinem Beitrag (den ich verlinkt habe) sagt, werden Sie sich auf unbekanntes Terrain wagen, wenn Sie an den Spezifikationen vorbeigehen. Wenn Sie die MCU-Grenzwerte testen, scheinen die Dinge zu funktionieren, aber Sie können unberechenbares Verhalten bekommen, wenn Sie es am wenigsten erwarten. Übrigens, ich hoffe, Sie haben es nicht beleidigt, dass ich auf Russels Antwort verlinke, da sie etwas zu humorvoll ist - aber sie veranschaulicht meinen Standpunkt gut.
Aber nein, der ATmega ändert seine Uhr nicht. Es wäre nützlich, wenn es so wäre, aber es gibt einfach auf unerwartete Weise auf.
Danke für den Link. Nichts für ungut, überhaupt nicht. Kurze und klare Erklärung. Der Link war auch ziemlich lustig und informativ. Ich wünschte nur, StackExchange hätte eine Funktion, um mehr als eine Lösung als akzeptable Antwort zu markieren.
Kein Schweiß. Kreuzen Sie die Antwort an, die Ihnen am nützlichsten erscheint . Andere können anders abstimmen, aber die Antwort zu akzeptieren, ist Ihre Entscheidung: D