Ist es möglich sicherzustellen das der Wert vom STM32F107 RTC gültig ist ? Folgende Situation: - Der Vbat Pin soll mittels eines GoldCaps im Falle eine Spannungsausfalls für mehrere Stunden die RTC am laufen halten. Dies funktioniert, jedoch wenn die Spannung unterhalb von 1,8 V gefallen ist, bekommt man beim Neustart keine Sinnvollen Werte. Beispielsweise war der letzte RTC-Wert: 7000. Dann wurde Vcc = 0 gesetzt und die RTC versorgt sich über den Vbat Spannung. Fällt Vbat nun unter 1,8 V und das System wird wieder mit Spannung versorgt bekommt man beispielsweise einen RTC-Wert von 4000, wobei dieser Wert auf jedenfall größer 7000 sein müsste. An dieser Stelle kommt der Tamper Pin ins Spiel. Dieser kann so konfiguriert werden, das er die BKP-Register löscht auch wenn Vcc = 0 V ist sobald ein Übergang HIGH->LOW detektiert wird. Das löschen der BKP Register funktioniert und somit könnte ich feststellen ob die mindest Vbat Spannung eingehalten wurde und ich somit dem gelesenen RTC Wert glauben schenken darf. Nachteilig ist das ich keine Angaben in der Dokumentation dazu finde und bei meinen Versuchen wurde teilweise kein Reset der Backup Register bei 1,6 V durchgeführt, aber hin und wieder fand ein Reset bei 2,4 V statt. Es sind keine Spitzen auf dem Oszilloskop zu sehen, und schon gar keine welche unter die mindest Spannung von 1,8 V gehen. Wäre schön, wenn einer eine Idee hat. Danke.
Nun ist der Backup-Stromverbrauch der STM32 nicht so immens hoch. Wäre es nicht einfacher, an Stelle von Goldcap plus Komparator für den Tamper-Pin eine Lithium-Knopfzelle einzusetzen?
Das Design steht schon so weit, leider wurde dieser Punkt nicht so stark beleuchtet. Bei dem Ansatz mit der Batterie könnte man beim starten des Systems die Batteriespannung messen und damit Rückschlüsse ziehen ob man dem RTC Wert trauen darf oder nicht. Eigentlich hätte ich erwartet, das ein Flag gesetzt wird ob die Spannung an Vbat die Kritische Marke von 1,8V unterschritten hat und zwar µC intern und nicht auch noch extern mit einem Komparator... Ich hoffe es gibt noch eine andere Lösung.
Vorname N. schrieb: > dem RTC Wert trauen darf oder nicht. Eigentlich hätte ich erwartet, das > ein Flag gesetzt wird ob die Spannung an Vbat die Kritische Marke von > 1,8V unterschritten hat und zwar µC intern und nicht auch noch extern > mit einem Komparator... Das hätte ST natürlich machen können, aber bei sowas handelt es sich um analoge Komponenten und wahrscheinlich hätten diese den Stromverbrauch der Backup-Domain vervielfacht. > Ich hoffe es gibt noch eine andere Lösung. Ohne jede Änderung des Designs? Da bin ich gespannt.
Vorname N. schrieb: > Das Design steht schon so weit, leider wurde dieser Punkt nicht so stark > beleuchtet. Bei dem Ansatz mit der Batterie könnte man beim starten des > Systems die Batteriespannung messen und damit Rückschlüsse ziehen ob man > dem RTC Wert trauen darf oder nicht. Was man auch mit dem Goldcap tun könnte. Aber: Man kann Vbat nicht einfach an einen ADC-Pin hängen, weil sonst ohne Vdd Strom über die Schutzdiode nach Vdd abfliesst.
Von ST gibts eine Application zum Batterie-Detect: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00207941.pdf Vielleicht was nutzbar davon. Es gabe auch mal ein Demo Projekt dazu, finde es auf den neuen ST Seiten auf die Schnelle gerade nicht, habe es aber noch bei Bedarf da.
Matthias K. schrieb: > Vielleicht was nutzbar davon. Erkennt laut Text nur die Entfernung der Batterie. Das ist trivial. Für Unterspannungserkennung hilft wohl nur ein externer Überwachungsbaustein.
Mit dem Goldcap würde ich das nicht Versuchen, da dieser in der Zeit schon wieder etwas geladen wird und es somit schwierig zu entscheiden. Das mit den Schutzdioden ist ein guter Hinweis, danke.
Vorname N. schrieb: > Mit dem Goldcap würde ich das nicht Versuchen, da dieser in der Zeit > schon wieder etwas geladen wird Muss ja nicht sein: Output-Pin --- R --- ADC-Pin --- >| --- Vbat Kurz nach Einschalten des Output-Pins misst der ADC-Pin die Spannung an Vbat plus Längsspannung der Diode. Geladen wird der Goldcap über diesen Weg. Funktioniert allerdings nicht, wenn der Goldcap defekt ist (offen).
Bin nicht sicher, ob ich alles verstanden habe... Hast Du in der Backup-Domain noch ein Bit frei? Dann setz das doch im Betrieb auf '1'. Nach Aufwachen checkst Du, ob es immer noch '1' ist, dann haben Backup-Domain und RTC "überlebt". Wenn '0' dann Game Over.
Bringt nichts. Der statische Speicher in der Backup-Domain überlebt viel länger als die RTC. Wahrscheinlich bis deutlich unter 1V. Die aktiv taktende RTC gibt weit vorher auf.
Arne schrieb: > Hast Du in der Backup-Domain noch ein Bit frei? Dann setz das doch im > Betrieb auf '1'. Nach Aufwachen checkst Du, ob es immer noch '1' ist, > dann haben Backup-Domain und RTC "überlebt". Wenn '0' dann Game Over. So war der Grundgedanke. An einigen Stellen in den BKP-Registern stehen Werte von denen ich sicher weiß, das sie ungleich Null sind. Nach der Konfiguration des Tamper Pin (PC13) würde dieser alle BKP-Register auf Null setzen (auch wenn Vcc = 0V ist), sobald ein Übergang HIGH->LOW erkannt wird. Dieser Übergang läge am besten bei 1,8V was im Datenblatt als Minimale Vbat Spannung angegeben ist und somit müsste der RTC noch sicher funktionieren. Leider ist dies in der ST Dokumentation so nicht sauber Dokumentiert und das Ergebnis siehst du in meinem Initial Post...
Autsch... gut zu wissen. Arbeite selbst mit dem 103. Softwarelösung scheidet somit aus :-(
Die fehlende Doku zum Tamper-Pin kann man andersrum ableiten: Wenn der einen Komparator auf 1.8V enthielte, dann stünde das totsicher in der Reference. Da die nichts dazu enthält, muss man von einem normalen Logikpin ausgehen. Da die Vorsorgungsspannung der Eingangsstufe des Tamper-Pins und die dahinter befindliche Tamper-Logik die Versorgung der Backup-Domain ist und die im fraglichen Zeitraum identisch mit Vbat ist, ist eine Verbindung zwischen Vbat und Tamper völlig sinnlos. Allerdings ist die Frage nach dem korrekten Pegel für den Tamper-Pin durchaus interessant. Wenn man den so konfiguriert, dass er bei 1=>0 löscht, was ist dann der richtige Pegel für "1"? Vdd kann es nicht sein und wenn es Vbat ist, dann liegt der Tamper-Pin bei Hochfahren mit Vbat=1,8V und Vdd=3,6V exakt bei Vbackup/2 und damit genau da wo man ihn ganz sicher nicht haben will.
A. K. schrieb: > Die fehlende Doku zum Tamper-Pin kann man andersrum ableiten: Wenn der > einen Komparator auf 1.8V enthielte, dann stünde das totsicher in der > Reference. Da die nichts dazu enthält, muss man von einem normalen > Logikpin ausgehen. Ich denke die folgenden Rechnungen machen keinen Sinn, allerdings zur Info vielleicht interessant. http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf Table 35. I/O static characteristics Standard I/O input high level voltage: Min: 0.41 * (Vdd - 2) + 1.3 = 0.48 V (with Vdd = 0) Max: VDD + 0.5 = 0.5 V (with Vdd = 0) I/O FT(1) input high level voltage: Min: 0.42 * (Vdd - 2) + 1 = 0.16 V (with Vdd = 0) Max: 5.5V A. K. schrieb: > Da die Vorsorgungsspannung der Eingangsstufe des Tamper-Pins und die > dahinter befindliche Tamper-Logik die Versorgung der Backup-Domain ist > und die im fraglichen Zeitraum identisch mit Vbat ist, ist eine > Verbindung zwischen Vbat und Tamper völlig sinnlos. Wird die Verbindung Vbat -> Tamper nicht hergestellt würde das Backup-Register nicht auf Null gesetzt. Völlig sinnlos ist dies natürlich bei dem neuen Ansatz.
Vorname N. schrieb: > Wird die Verbindung Vbat -> Tamper nicht hergestellt würde das > Backup-Register nicht auf Null gesetzt. Mit dieser Verbindung aber auch nicht, denn der Low-Pegel ist letzlich in Prozent von der Versorgungsspannung des betreffenden Ports definiert, mit Schwelle um die 50% davon. Und nun erzähle mir mal, wie du einen Pin auf Low kriegst, der per externem Kabel fix auf 100% der aktuellen Versorgungsspannung hängt ;-). Beachte: Ohne Vdd ist Vbat die Versorgungsspannug der Backup-Domain und diese paar Port-C Pins werden zwangsläufig daraus versorgt ("PC13, PC14 and PC15 are supplied through the power switch"). Folglich gelten die oben aufgeführten Faktoren hier nicht ausgehend von Vdd sondern ausgehend von Vbat (bzw. von Vbackup, was in diesem Fall Vbat entspricht).
So mal als Idee... keine Ahnung ob das funktioniert: Ich nehme mal an, dass bei dieser niedrigen Batteriespannung auch der Uhrenquarz stehenbleibt. Insofern sollte es möglich sein, gleich nach dem Reset per überprüfung von RCC_FLAG_LSERDY rauszufinden dass der Uhrenquarz noch steht.
Irgendwann bleibt er stehen, aber wenn man Pech hat, dann hoppelt er schon vorher unsauber vor sich hin. Müsste man ausprobieren.
Die Idee klingt verlockend, hat bei meinem Versuch aber leider nicht funktioniert. Die LED hat immer grün geleuchtet, selbst wenn Vbat und GND einige Sekunden kurzgeschlossen waren (während Vdd = 0V). Ob die Frequenz korrekt ist habe ich nicht mehr Überprüft, man kann jedoch auf PC13 den LSE clock / 64 ausgeben (sollten 512 Hz sein). Bin mir aber nicht sicher ob dies mit Vdd = 0V funktioniert. Hier ein kleiner Ausschnitt aus dem Code:
1 | /* Enable PWR and BKP clock */
|
2 | RCC_APB1PeriphClockCmd ( RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE ); |
3 | |
4 | if(RCC_GetFlagStatus(RCC_FLAG_LSERDY) == RESET) { |
5 | setLED(LED1, RED); |
6 | }
|
7 | else { |
8 | setLED(LED1, GREEN); |
9 | }
|
10 | |
11 | /* Enable write access to Backup domain */
|
12 | PWR_BackupAccessCmd(ENABLE); |
13 | |
14 | u16_bkp = BKP_ReadBackupRegister(BKP_DR1); |
15 | |
16 | if( (u16_bkp & 0xFF) != CONFIGURATION_DONE) { |
17 | /*RTC not configured yet*/
|
18 | /* Backup Domain Reset */
|
19 | BKP_DeInit(); |
20 | |
21 | |
22 | /*Enable 32.768 kHz external oscillator (LSE) */
|
23 | RCC_LSEConfig(RCC_LSE_ON); |
24 | |
25 | /* Wait till LSE is ready */
|
26 | while(RCC_GetFlagStatus(RCC_FLAG_LSERDY) == RESET){ |
27 | ;
|
28 | }
|
29 | ...
|
30 | ...
|
31 | ...
|
Hmmm... also bei mehreren Sekunden ohne Spannung sollte LSERDY an dieser Stelle wirklich nicht gesetzt sein. Zu welchem Zeitpunkt findet denn die Überürüfung statt? Vielleicht dauert es nach dem Neustart ein paar ms bis ein stehender Quarz erkannt wird? Oder vielleicht kann man der detection Logik etwas auf die Sprünge helfen, wenn man LSERDY erstmal selbst löscht und dann schaut, ob es innerhalb weniger ms wieder gesetzt wird? Naja, alles hoch spekulativ das... hier hilft wohl nur etwas rumprobieren. (Sofern Du nicht so nennenswerte Stückzahlen produzieren willst, dass sich da auch mal jemand bei ST bequemen könnte nachzuforschen...)
Hannes S. schrieb: > Zu welchem Zeitpunkt findet denn die > Überürüfung statt? Findet im Prinzip nach der Konfiguration der HSE und PLLs statt. Hannes S. schrieb: > Vielleicht dauert es nach dem Neustart ein paar ms > bis ein stehender Quarz erkannt wird? Habe zum testen einfach mal ein Wartezeit von 100ms eingesetzt, jedoch mit dem gleichen Ergebnis. Hannes S. schrieb: > vielleicht kann man der > detection Logik etwas auf die Sprünge helfen, wenn man LSERDY erstmal > selbst löscht und dann schaut, ob es innerhalb weniger ms wieder gesetzt > wird? Das Flag kann man nur lesen. Zum testen habe ich vor der Überprüfung (siehe Code Beispiel oben) einfach mal ein RCC_LSEConfig(RCC_LSE_OFF); gesetzt und die 100ms abgewartet mit dem Ergebnis das erkannt wurde, das der LSE nicht läuft.
Tjaaa.... klingt nicht gut... und verstehe auch nicht, wieso da LSERDY nicht das tut, was es soll... Aber mal eine andere (unausgegorene) Idee: Am RTC/Tamper Pin kann man auch einen RTC Alarm ausgeben. Wenn man nun beim Abschalten (ggf. noch über den PVD Interrupt) die Alarmzeit auf ein paar Stunden in der Zukunft (die Dauer die der Goldcap SICHER reicht) stellt, dann könnte man z.B. mit einer kleinen Schaltung an diesem Pin den Goldcap komplett entladen und damit hoffentlich die Backup register komplett zu löschen. Oder vielleicht ist es auch per Software noch irgendwie möglich das Auftreten des Alarms zu erkennen. Jedenfalls kann man dann sagen: Wenn der Alarm aufgetreten ist, dann darf man der Uhrzeit nicht mehr vertrauen.
Könnte mir vorstellen das die Variante mit dem RTC-Alarm nicht funktionieren wird, da kein Interrupt ausgelöst wird (Vdd = 0V). Ein Supervisor circuit welcher mit dem Tamper Pin verbunden ist und bei 1,8V schaltet, wäre noch eine Lösung, wobei ich die Lösung mit dem ADC momentan bevorzugen würde.
Moin moin, ist es nicht möglich die RTC Zeit in die Backup Register zu schreiben (zyklisch oder möglichst kurz vor dem Wegfall der Versorgungsspannung). Beim anschliessenden Hochfahren müsste die RTC Zeit weiter sein als die gespeicherte. Ist die RTC Zeit vor der gespeicherten Zeit oder die Backupregister sind ungültig, wird wohl die RTC Zeit ungültig sein. Gruß Garag
Man kann zwar die letzte Zeit z.B. mittels eines PVD Interrupts (Programmable Voltage Detector) in ein Backup Register schreiben lassen, aber der Goldcap speist die RTC/Backup-Domäne noch für einige Stunden. Beim hochfahren des Systems hatte ich aber schonmal den Fall, das die neue Zeit nicht in der Vergangenheit lag, sondern durchaus eine plausible Zeit gewesen sein könnte (war allerdings doch einige Minuten daneben). Ansonsten ja.
Sehr schön wäre, wenn man per RTC Alarm einen Tamper Event auslösen könnte. Die beiden teilen sich noch dazu den gleichen Pin, Alarm als Output, Tamper als Input. Also spräche eigentlich nix dagegen. Nur leider sagt das Ref Manual folgendes: "The TAMPER pin must not be enabled while the ASOE bit is set." Und "must not" klingt ja richtig bedrohlich... meine Güte... Explosion, Kernschmelze?? Ich meine aber, damit wollen die sagen, dass bei Alarm Output an diesem Pin natürlich kein Tamper-Switch mehr angeschlossen werden kann. Insofern schreit das schon fast danach, ausprobiert zu werden... ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.