mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Langzeit BitFehler in Register


Autor: Torsten B. (torty)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Mich würde mal interessieren, ob man sich auch für längere Zeit auf die 
Beständigkeit von Registerinhalten verlassen kann.

Beispiel:
In einem Programm, dass im Dauerbetrieb eine Maschine überwacht, werden 
verschiedene Stati per Bitsetzen/-löschen in einem Register "Status" 
gespeichert.
Kann man sich darauf verlassen, dass auch über Tage oder Monate kein Bit 
in einem solchen Register unbeabsichtigt "kippt", oder sollte man so ein 
Statusbyte besser in SRAM, EEPROM oder sonstwo speichern und bei Bedarf 
erst "frisch" in ein Register laden ?

Was meint Ihr ?

Grüße
Torsten

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie sieht das mit Bitfehlern im "Sonstwo" aus?

Ich denke, daß dieser "Status" viel eher durch Softwarefehler verfälscht 
wird als durch Hardwarefehler.

In welchem Stadium befindet sich denn das Projekt?

Bernhard

Autor: Torsten B. (torty)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bernhard

Das ist ja im Grunde meine Frage. Wo speichert man so ein Statusbyte am 
besten. Wenn mit Stromausfall gerechnet werden muss, nimmt man am besten 
einen nicht flüchtigen Speicher (EEPROM) klar.
Jeder Neustart würde jedoch auch gleich wieder den Urzustand herstellen.

Ich habe nur Bedenken, in der Laufzeit den "Faden zu verlieren" und dann 
irgendwo im Nirvana mit meinem Status zu stehen.

Gegen Softwareeingriffe sollte in Register doch geschützt sein, wenn ich 
es schon Status nennen und nur ganz speziell darauf zugreife, oder ?

Das Projekt ist bisher noch in den ersten Gedankenschritten. Ich würde 
es jedoch gere gleich richtig anfangen. Deshalb die Frage hier.

Grüße
Torsten

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Register sind auch nur SRAM.

Speicher den Status doch in 2 Registern. Dann kannst Du vor der 
Benutzung erst mal überprüfen, ob noch alles ok ist.

Was kann denn ein Bit in deiner Umgebung kippen? Kosmische Strahlung? .. 
EMV? .. verursacht durch Motoren? .. Straßenbahn? ..
Also gut abschirmen und dafür sorgen, daß Interfaces keine Störungen 
einkoppeln. Lässt man den uC in Ruhe werkeln gibt es sicher keinen Grund 
für ein spontanes Kippen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten B. schrieb:
> Hi Bernhard
>
> Das ist ja im Grunde meine Frage. Wo speichert man so ein Statusbyte am
> besten. Wenn mit Stromausfall gerechnet werden muss, nimmt man am besten
> einen nicht flüchtigen Speicher (EEPROM) klar.

Logisch. Irgendetwas nicht flüchtiges.

> Jeder Neustart würde jedoch auch gleich wieder den Urzustand herstellen.

Was meinst du mit Urzustand?
Bei einem Neustart sieht man dann eben im EEPROM nach und holt sich den 
Wert von dort. Beim allerersten mal muss man halt dafür sorgen, dass da 
ein vernünftiger Wert drinn steht, aber ansonsten ist das nicht weiter 
ein Problem.

> Ich habe nur Bedenken, in der Laufzeit den "Faden zu verlieren" und dann
> irgendwo im Nirvana mit meinem Status zu stehen.

Den Faden verlierst du in 99.999999% aller Fälle durch einen 
Softwarefehler. Sprich: Du hast einen Bug im Programm.

> Gegen Softwareeingriffe sollte in Register doch geschützt sein, wenn ich
> es schon Status nennen und nur ganz speziell darauf zugreife, oder ?

Nicht wirklich.
Wenn dein Sklave alles tut, was du ihm aufträgst und dein Auftrag lautet 
"Spring aus dem Fenster" dann kann dein Sklave noch so gut 'geschützt' 
sein. Auftrag ist Auftrag.

> Das Projekt ist bisher noch in den ersten Gedankenschritten. Ich würde
> es jedoch gere gleich richtig anfangen. Deshalb die Frage hier.

Du machst dir an dieser Stelle unnütze Gedanken. Sieh zu, dass dein 
Programm fehlerfrei wird. Dann wird es viele Tage, Monate, Jahre laufen, 
ohne dass durch irgendein kosmisches Teilchen ein Bit ganz von alleine 
kippt. Die Wahrscheinlichkeit, dass das tatsächlich zu einem Problem 
werden könnte ist so gering, dass du den Fall getrost ignorieren kannst.

Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Register gegen Softwareeingriffe schützen".

Wenn nicht durch software, wodurch wird denn der Zugriff auf die 
Register sonst gesteuert? Aber hier kommt es auf die 
Prozessor-Architektur an. Harvard <-> von Neumann ... Bei Harvard sind 
natürlich die Register ein wenig besser geschützt, da sich das Programm 
in einem anderen Bereich befindet, als die Daten. Währen der Laufzeit 
wird sich ein Programm in der Regel nicht selbst ändern.

Bei von Neumann ist das etwas anders. Hier gibt es keinen Unterschied 
zwischen Programm und Daten-Speicher. Natürlich kann hier ein 
Programm-Fehler z.B. auch dazu führen, daß man andere Teile vom Programm 
überschreibt - und dann vielleicht doch ein eigentlich "geschütztes" 
Register an ungewollter Stelle überschreibt.

Auch bei Harvard muss man natürlich dem Compiler sagen, daß er genau 
dieses eine Register nicht beliebig verwenden kann. Bei Assembler liegt 
es in der Macht des Programmierers das nicht zu tun. Ist allerdings dann 
auch als Programmierfehler zu werten, wenn man genau das z.B. in einer 
ISR vergisst umzusetzen.

Autor: Bernhard R. (barnyhh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

ich spreche hier nicht von vorsätzlichen Software-Manipulationen, 
sondern von den allgemein üblichen Design- und Programmierfehlern 
(Experten: ca. 1 Fehler / kLoc bei Auslieferung des Produkts).

Im übrigen hatte ich befürchtet, daß das Produkt schon kurz vor der 
Auslieferung stehe, und nachträgliches "Hineinflicken" von Qualität geht 
meistens ganz gewaltig in die Hose.

Ich denke, daß das Register eine sinnvolle Stelle für diese Variable 
ist. Für den Restart-Fall nach Ausfall sollte vielleicht ein permanenter 
Speicher mit einer Untermenge des Status - sinnvoller Restart-Status - 
benutzt werden.

Bernhard

Autor: Wilhelm F. (ferkes-willem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Torsten B.:

>Mich würde mal interessieren, ob man sich auch für längere Zeit
>auf die Beständigkeit von Registerinhalten verlassen kann.

Ich verstehe deine Bedenken, da ich diese ebenfalls mal hatte. In den 
Anfangszeiten, wo ich mit Mikrocontrollern zu tun hatte, frischte ich 
noch zyklisch die SFR auf, aber das ist verrückt. Im Grunde könnte man 
ja dann keinem einzigen bit aus der Software mehr vertrauen. Die SFR in 
einem Controller sind ebensolche RAM-Zellen, wie die Stelle, wo man ein 
Statusbyte speichert.

Für den Codespeicher kann man z.B. mal eine zyklische 
Checksummenüberprüfung während der Laufzeit, in die Software einbauen, 
oder sonstige Redundanztests, da gibt es ausreichend Möglichkeiten, wenn 
man das möchte.

Solange man keine groben Schnitzer in der Software hat, sollte es in 
integrierten Halbleiterschaltungen möglich sein, ein Statusbit bis in 
alle Ewigkeit (Stromausfall) in einem Register zu behalten. Integrierte 
Halbleiterschaltungen haben intern die höchsten elektrischen 
Feldstärken, die in der Elektrotechnik vorkommen. Allein von daher sind 
sie sehr robust gegen äußere Einflüsse. Industrielle Steuerungen, auch 
sicherheitskritische, laufen über Jahre hinweg, bis man den Strom 
abschaltet. Ich bin sicher, dir fallen da einige Anwendungen in deiner 
Umgebung ein. Man mag sich ja nicht vorstellen, daß mal alle Ampeln an 
einer Kreuzung auf grün stehen...

Ansonsten gibt es da batteriegepuffertes SRAM oder EEPROM für wichtige 
Betriebsparameter, die über einen Ausfall hinweg gerettet werden müssen.

ESD und EMV z.B. stören natürlich ab einem bestimmten Maß. Da sind 
selbstverständlich die entsprechenden Vorkehrungen zu treffen.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist alles eine Frage der Wahrscheinlichkeiten und des Risikos im
Fehlerfall.

Das regelmäßige Auffrischen von Variablen verkürzt das Zeitfenster, in
der eine Störung einen Fehler verursachen kann.

Viel wichtiger als die Vermeidung ist es aber, einen Fehler zu
erkennen. Dazu kann man den Status z.B. über eine Prüfsumme oder
auch CRC absichern. Man macht das üblicherweise nicht für jeden Wert
einzeln, sondern über eine Datenstruktur, die mehrere Variablen
enthält. Diese Prüfsumme wird dann möglichst zeitnah vor dem Auswerten
der Daten mit dem Istwert verglichen.

Da ein erkannter Fehler zumeist eine Fehlerroutine aufruft, sinkt die
Verfügbarkeit des Systems. Das kann ebenfalls kritisch sein. Die
Verfügbarkeit könnte mittels ECC erhöht werden, wobei natürlich das
Auftreten des Fehlers in einem Log registriert werden sollte.

> Register sind auch nur SRAM.

Nun ja, im Allgemeinen nicht. Das spielt hier aber keine Rolle.

Gruß
Marcus

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.