RTC DS3231 und lostpower

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!

    Hallo,


    folgende Situation: Raspi 3B V1.21 mit Raspbian GNU/Linux 11 (bullseye) und Kernel 6.1.21-v7+. RTC DS3231 läuft (dtoverlay=i2c-rtc,ds3231), aber: Im Log (kern.log, messages und syslog) gibt es nur Einträge in dieser Art (Beispiel): "rtc-ds1307 1-0068: registered as rtc0" Ich gehe davon aus, dass das ds1307er Modul auch für die DS3231 verwendet wird. So weit, so gut.


    Ich habe versucht herauszufinden, was passiert, wenn die RTC ihre Stützbatterie verliert (lostpower). Der Chip selbst registriert das und man kann ihn über I2C danach fragen, solange er nicht mit einer neuen Zeit "justiert" wird. So wie es aussieht, tut der DS1307-Treiber das aber nicht. Wenn also die RTC nach Batterieverlust dem System eine Zeit kurz nach dem 1.1.2000, 00:00:00 liefert, wird diese akzeptiert und der Raspi läuft dann so, bis er (falls möglich) eine Zeit aus dem Netz holen kann. Der Zustand des Batterieverlusts wird jedenfalls im Log nirgends manifestiert, oder doch?


    Ziel ist es, den Verlust der Stützbatterie wenigstens zu loggen. Z.B. via Logcheck könnte man dann eine entsprechende Mail generieren.


    Alternativ kann man natürlich als Prevention die Batterie z.B. jährlich wechseln.

    Edited once, last by riperasp: Schreibfehler korrigiert ().

    Quote from riperasp

    " Ich gehe davon aus, dass das ds1307er Modul auch für die DS3231 verwendet wird.

    Nö, der DS3231 hat ein eigenes dt-overlay laut /boot/overlays/README (Name: i2c-rtc-gpio).


    Die Clock-Geschwindigkeit eines gepufferten RTC wird von der Versorgungsspannung gesteuert. Unterschreitet diese 3 V, fällt der RTC in den (langsamen) Batteriemodus. Zu diesem Zeitpunkt ist keine Protokollierung in ein Logfile mehr möglich, weil der Pi schon runtergefahren ist. Du musst Dir für dein Vohaben etwas Eigenes erfinden, wie z.B. die Differenz zwischen Gesambtzeitspanne (ab Einlegen einer neuen Batterie) minus Einschaltzeitspanne.



    Servus !

    RTFM = Read The Factory Manual, oder so

    Quote from RTFM

    Nö, der DS3231 hat ein eigenes dt-overlay laut /boot/overlays/README (Name: i2c-rtc-gpio).

    Hmm, ich habe mir gerade mal eine Schnellbesohlung zum Linux Device Tree verpasst. Ich sehe das so: Es gibt lt. /boot/overlays/README zwei Overlays, die die DS3231 unterstützen: i2c-rtc (Zeile 1847) und i2c-rtc-gpio (Zeile 1933). Welches Overlay zur Anwendung kommt, hat wohl eher mit dem I2C-Bus zu tun, habe ich mir aber nicht weiter angesehen. Der dazugehörige Treiber liegt unter /usr/lib/modules/<kernel-Version>/kernel/drivers/rtc und ist jeweils der rtc-ds1307.ko.xz. Jedenfalls ist das der einzige, der die ds3231 in seiner Tabelle führt. Somit ist anzunehmen, dass der Treiber die erweiterten Möglichkeiten der ds3231 gar nicht unterstützt, zumal ich in der rtc.h nichts passendes gefunden habe, was ein RTC-Treiber in dieser Richtung bedienen könnte. Es bleibt mir also tatsächlich nur, etwas Eigenes zu programmieren.


    Ok, Du hast mich jedenfalls weitergebracht.

    Beispielsweise die Möglichkeit der Abfrage des enthaltenen Temperatursensors. Ich habe mir aber gerade die Treiberquelle angesehen. Das wird alles unterstützt.

    Ich überlegte gerade, für mich einen Fork des Treibers nur für die DS3231 zu bauen, der meine Wünsche unterstützt, aber ich sehe jetzt, dass doch alles vorhanden ist. Die Log-Messages lauten jeweils "SET TIME!". Dahinter verbirgt sich, dass der Oszillator steht, die Uhr also nicht läuft (RTC-Register 0x0F, Bit 7; Oscillator Stop Flag (OSF)). Warum die RTC-Zeit trotzdem verwendet wird, erschließt sich mir (noch) nicht, ist aber auch egal. Jetzt muss ich nur noch sehen, dass die zeitliche Abfolge der Ereignisse passt.

    Hast Du eine Ausgabe von

    Code
    echo $(cat /sys/bus/i2c/devices/1-0068/hwmon/hwmon2/temp1_input|awk '{print $0/1000 " °C"}')
echo $(cat /sys/bus/i2c/devices/1-0068/rtc/rtc0/date)
echo $(cat /sys/bus/i2c/devices/1-0068/rtc/rtc0/time) "UTC"

    ?


    Mit Puppy scheint das jedenfalls zu funktionieren. > https://forum.puppylinux.com/viewtopic.php?t=5458

    Ja, glaube ich. Hier ging es aber darum, dass für den "powerloss"-Fall, also RTC-Batterie leer und Beriebsspannung auch weg, der Raspi sich trotzdem die jetzt falsche Zeit (keine Netzwerkverbindung vorausgesetzt) von der RTC holt. Dafür ist in irgend einer Weise der Treiber verantwortlich (warum der das so macht, weiß ich noch nicht), obwohl er die RTC testet und auch erkennt, wenn das Ding nicht mehr stimmt. Siehe weiter oben.

    Das habe ich schon verstanden, aber wenn die Batterie leer und kein Netz vorhanden ist, woher soll der RPi dann die aktuelle Zeit nehmen, wenn nicht die letzte (wenn auch falsche) von der RTC? Was sollte da der Treiber machen? Dem RPi die letzte Zeit geben, die noch vor dem Batterieausfall gültig war? Aber woher soll der Treiber wissen wann genau die Batterie alle wird, um sich rechtzeitig *irgendwie* die letzte aktuelle Zeit zu merken? :conf:


    Fragen über Fragen... ^^


    Ich würde einfach regelmäßig die Batterie wechseln und gut ist. So teuer sind die (hier vermutlich) CR2032 nicht.



    //Edit


    Z.B. hier:https://www.kaufland.de/product/415569357/ :lol:

    Das war jetzt auch bei mir ein Prozess der logischen Durchdringung des Ganzen. Letztlich steht die Info, dass etwas mit der Systemzeit nicht stimmt, zur Verfügung. Entscheidend ist die Info, ob die Zeit brauchbar ist oder nicht. Die steht zur Verfügung, aber leider nur als Log-Eintrag. Wie auch immer, Problem erkannt und weitgehend gelöst.

    Das ist nicht der Punkt. Es geht um die Brauchbarkeit. Also zumindest eine Plausibilitätsprüfung muss ausgeführt werden. Die kann dann z.B. im Vergleich mit der letzten Zeit vor dem aktuellen Neustart passieren. Ist diese größer, ist die aktuelle Zeit unbrauchbar. Die aktuelle Zeit kann periodisch z.B. in einen EEPROM geschrieben werden, um nach dem nächsten Start einen Vergleich zu haben. Schade und das eigentliche Problem ist eben, dass das System nicht vorsieht, dass die RTC-Zeit falsch sein kann. Ganz im Gegensatz zur NTP-Synchronisation, deren Status man problemlos über die verschiedensten programmtechnischen Wege überprüfen kann.

    Quote from riperasp

    Ja, kann man so machen.

    Ich muss mich korrigieren. Kann man nicht so machen. Der Raspi merkt sich den letzten Startzeitpunkt. Wenn er eine Zeitsynchronisation weder aus dem Netz noch von einer RTC bekommt, nimmt er diesen Zeitpunkt als "jetzt" an.

    Doch, weil das Verhalten nicht eindeutig vorhersehbar ist. Ich habe mir auch noch einmal den Treiber angesehen. So, wie ich es verstanden habe, behandelt er zwei Uhren, nämlich die DS3231 und die "rx_8025" (so wird sie im Treiber genannt) anders. Bei diesen kommt die Warnung im Log "SET TIME!" und dann lässt er sie loslaufen. Ich vermute, müsste ich mir aber erst ansehen, dass aus welchen Gründen auch immer, das System den Treiber vor der "probe"-Funktion nach der Zeit fragt und dann liefert der Treiber "EINVAL" (Fehler: nicht valide). Fragt das System nach Aufruf der "probe"-Funktion, bekommt es den 1.1.2000, 00:00 als richtige Zeit angeboten. Beide Fälle hatte ich mit der DS3231.