Hallo Ihr... Weiß jemand, ob beim AVR der SRAM-Inhalt erhalten bleibt, wenn der Controller crasht und deswegen neu startet? Oder initialisiert der AVR bei diesem Reset das komplette SRAM neu mit Null oder so? Klar, wenn das RAM bei dem Controller-Amoklauf schon überschrieben wird, dann ist der Inhalt weg, aber das was dann noch drinsteht, ließe sich vielleicht für Debug-Zwecke nutzen wenn so ein Crash auftritt. Danke euch!
Ben B. schrieb: > Nachtrag: Selbst ausprobiert, funktioniert, SRAM-Inhalt bleibt. Jein. Vom Controller her schpn, aber es gibt Compiler, die initialisieren am Programmanfang erstmal den Sram.
120kb reiner Assembler-Quellcode... etwa 4200 Befehle im Moment.
>:-)=)
Ben B. schrieb: > 120kb reiner Assembler-Quellcode... etwa 4200 Befehle im Moment. Wenn man keine Mammuts mehr jagen kann, dann wenigstens Assembler . . .
Irgendwie muss man seine Controller-Abstütze und -Amokläufe ja produzieren... :-)
Ben B. schrieb: > 120kb reiner Assembler-Quellcode... etwa 4200 Befehle im Moment. > Wie das ? 4200 x 4 Bytes maximale Befehlslänge, da komme auf ich auf 16800 Bytes. Ah, ich sehe, Quellcode.... Gruß, Michael
:
Bearbeitet durch User
Ben B. schrieb: > 120kb reiner Assembler-Quellcode... etwa 4200 Befehle im Moment. > > :-)=) Auch eine Möglichkeit seine Zeit zu verbringen...
Ich glaube bei C gibt es dafür die ".noinit" Sektion, da kann man Variablen unterbringen, die beim Reste nicht initialisiert werden sollen. https://www.microchip.com/webdoc/AVRLibcReferenceManual/mem_sections_1sec_dot_noinit.html
Ben B. schrieb: > Weiß jemand, ob beim AVR der SRAM-Inhalt erhalten bleibt, wenn der > Controller crasht und deswegen neu startet? Da der AVR gar keine Reset-Quelle namens „Crash“ kennt, ist die Frage so sinnfrei. Geben tut es Power on, Brown out, external, und Watchdog-Resets. Letzterer käme als „Crash“ - Reset in Frage. Das Datenblatt sagt allerdings über den Inhalt des SRams nach einem Reset (vermutlich absichtlich) nichts aus, ergo ist alles möglich. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > ergo ist alles möglich. Das sehe ich anders. Beim Reset passiert mit dem RAM einfach nichts.
Ben B. schrieb: > 120kb reiner Assembler-Quellcode... etwa 4200 Befehle im Moment. Selba schuld. Wahrscheinlich keine 3 usec schneller, dafür aber Wochen und Monate Lebenszeit sinnlos investiert. Oder: auch eine Möglichkeit Sado-Maso auszuüben.
Mitlesa schrieb: > Oder: auch eine Möglichkeit Sado-Maso auszuüben. Programmieren macht mit Kerzen und Peitschen gleich viel mehr Spaß!
Stefanus F. schrieb: > Oliver S. schrieb: >> ergo ist alles möglich. > > Das sehe ich anders. Beim Reset passiert mit dem RAM einfach nichts. Bei einem Brown-out-Reset auch nicht? Gewagte Annahme... Und solange der TO nicht verrät, wo da wirklich im Falle eines Crashs passiert, ist das alles Kaffesatzleserei. Oliver
Oliver S. schrieb: > Bei einem Brown-out-Reset auch nicht? Den kannst man durchaus auf eine Spannungs-Schwelle konfigurieren, wo der AVR noch tadellos funktioniert (z.B. 4,3V). Du meinst wohl eher den Ausfall der Spannungsversorgung. Das hat dann aber nichts mehr mit dem RESET zu tun, sondern mit den "Operational Conditions".
Ben B. schrieb: > Oder initialisiert der AVR > bei diesem Reset das komplette SRAM neu mit Null oder so? Hi, ein Power on Self Reset mit Hochzählen der Adressen etc. wie beim PC, davon wüsste ich nichts bei den ATMEL AVRs. Zur Sicherheit wird nach dem Stackinit auch gleich eine Lösch-Routine angeschlossen. Dann ist das SRAM sicher mit Nullen überschrieben. So mach ich das. (Sonst hatte ich beim ersten Zugriff auf das SRAM und Ausgabe Hieroglyphen auf dem Display. Erst bei weiterem Zugriff kamen dann die Daten, die aktiv ins SRAM geschoben worden waren auch richtig ins Display.) ciao gustav
Stefanus F. schrieb: > Den kannst man durchaus auf eine Spannungs-Schwelle konfigurieren, wo > der AVR noch tadellos funktioniert (z.B. 4,3V). Nach dem Brown-Out-Reset ist das RAM trotzdem hinüber. Das hat gar nichts mit der Triggerschwelle zu tun.
Karl B. schrieb: > ein Power on Self Reset mit Hochzählen der Adressen etc. wie beim PC, Wann hast du das letzte Mal einen PC gestartet?
Karl B. schrieb: >Assembler Beispiel Der Ben hatte genau dach dem Gegenteil gefragt. Er möchte, dass das RAM (zumindest teilweise) NICHT initialisiert wird.
Nein schrieb: > Nach dem Brown-Out-Reset ist das RAM trotzdem hinüber. Kann man das irgendwo nachlesen?
Nein schrieb: > Wann hast du das letzte Mal einen PC gestartet? Beim alten ME kann man das Hochzählen im Startbild gut sehen. So meinte ich das. Bei den jetzt verwendeten höheren Windows ist das anders. ciao gustav
Oliver S. schrieb: > Bei einem Brown-out-Reset auch nicht? Gewagte Annahme... Solange der Bod Reset noch als solcher erkannt wird, "sollte" das gelingen. Bei einem Power on Reset, wird man sich gar nicht mehr auf die Daten verlassen können. Aber wie immer: CRC/Prüfsumme kann die Zuverlässigkeit der Erkennung gültiger Datensätze verbessern.
Karl B. schrieb: > Beim alten ME kann man das Hochzählen im Startbild gut sehen. So meinte > ich das. > Bei den jetzt verwendeten höheren Windows ist das anders. Du meinst sicher das BIOS, nicht Windows ME.
Stefanus F. schrieb: >> Nach dem Brown-Out-Reset ist das RAM trotzdem hinüber. > > Kann man das irgendwo nachlesen? SRAM bekommt beim Unterschreiten der minimalen Betriebsspannung zufällige Werte. Es ist egal, ob das vom Brownoutdetektor erkannt wird oder nicht. Gegen den Betriebsspannungsverlust kann der nichts machen. Er verhindert nur, dass der µC mit zu geringer Betriebsspannung weiterrechnet. Sobald die Spannung wieder hoch genug ist, resetiert der Brownout-Mechanismus den Controller. Dann ist der RAM-Inhalt aber schon beschädigt.
Stefanus F. schrieb: > (zumindest teilweise) NICHT initialisiert wird. Hi, also bei mir ist etwas Zufälliges drin dann. Manchmal hält es die Daten, manchmal auch nicht. ciao gustav
Nein schrieb: > Stefanus F. schrieb: >>> Nach dem Brown-Out-Reset ist das RAM trotzdem hinüber. >> >> Kann man das irgendwo nachlesen? > > SRAM bekommt beim Unterschreiten der minimalen Betriebsspannung > zufällige Werte. > Es ist egal, ob das vom Brownoutdetektor erkannt wird oder nicht. Gegen > den Betriebsspannungsverlust kann der nichts machen. Er verhindert nur, > dass der µC mit zu geringer Betriebsspannung weiterrechnet. Sobald die > Spannung wieder hoch genug ist, resetiert der Brownout-Mechanismus den > Controller. Dann ist der RAM-Inhalt aber schon beschädigt. Die anderen beiden Speicher, EEPROM und Flash, sind da viel kritischer, als das SRAM
Arduino Fanboy D. schrieb: > Die anderen beiden Speicher, EEPROM und Flash, sind da viel kritischer, > als das SRAM Nein? EEPROM und Flash verlieren bei Spannungsverlust natürlich nicht ihren Inhalt. So ein Unsinn.
Angehängte Dateien:
-
Win_ME_memory.jpg
79 KB
Stefanus F. schrieb: > Du meinst sicher das BIOS, nicht Windows ME. Hi, so in etwa sieht das aus, wenn man den Museumsrechner hochfährt: Das ist nicht der BIOS Schirm. Aber Inhalt vom Bios beim Start, erst Energy Saving Logo etc. OK. Mal sehen, ob ich den noch flott bekomme. Dann zeig ich's. ciao gustav
Nein schrieb: > Nein? > EEPROM und Flash verlieren bei Spannungsverlust natürlich nicht ihren > Inhalt. > So ein Unsinn. Ach man.... Es ist ja nicht nur das "behalten", sondern auch das Auslesen und beschreiben. Und da versagen die beiden eher, als das Ram.
Michael A. schrieb: > 4200 x 4 Bytes maximale Befehlslänge, da komme auf ich auf 16800 Bytes. > > Ah, ich sehe, Quellcode.... In den '90ern waren Code-Metriken in Mode. "Anzahl der Kommentarzeilen dividiert durch Anzahl der Programmzeilen" und sowas. Teilweise hingen davon die Prämien ab, entsprechen sah dann der Code ab.
Nein schrieb: > Flash Im Flash (cseg) ist doch das Programm drin. ; ATtiny4313 memory use summary [bytes]: ; Segment Begin End Code Data Used Size Use% ;-------------------------------------------------- ;[.cseg] 0x000000 0x0002a6 650 28 678 4096 16.6% ;[.dseg] 0x000060 0x000060 0 0 0 256 0.0% ;[.eseg] 0x000000 0x000000 0 0 0 256 0.0% ;Assembly complete, 0 errors. 0 warnings ;-------------------------------------------------- so sieht das beispielsweise aus. ciao gustav
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Es ist ja nicht nur das "behalten", sondern auch das Auslesen und > beschreiben. Hi, für das EEPROM sind laut Dabla Schreib-Lesezyklen mit ca. 100000 angegeben oder so. ciao gustav
Nein schrieb: > EEPROM und Flash verlieren bei Spannungsverlust natürlich nicht ihren > Inhalt. > So ein Unsinn. Bei einem langsamen Spannungsabfall bekommt man das EEPROM ziemlich sicher gelöscht oder zumindest korrumpiert. Deshalb ist bei EEPROM-Nutzung immer der BOD einzuschalten.
Nein schrieb: > Nach dem Brown-Out-Reset ist das RAM trotzdem hinüber. > SRAM bekommt beim Unterschreiten der minimalen Betriebsspannung > zufällige Werte. Es geht doch um den Fall, dass die Spannung nur ein bisschen unter 4,3V sinkt und der Brown-Out Detektor auf 4,3V eingestellt ist. In diesem Fall haben wir kein Unterschreiten der minimalen Betriebsspannung, das RAM funktioniert noch, es gehen keine Daten verloren.
Karl B. schrieb: > Hi, > für das EEPROM sind laut Dabla Schreib-Lesezyklen mit ca. 100000 > angegeben oder so. Ich sage: Das EEPROM ist kritischer bei Spannungsabsenkung, als das RAM. Und du sagst: Gestern hat es geregnet. (100000 Zyklen) Das eine hat doch mit dem anderen nichts zu tun! Aber dennoch: Schön dass du das Datenblatt gelesen hast. Lies es bitte noch ausführlicher. Denn: Thomas E. schrieb: > Deshalb ist bei > EEPROM-Nutzung immer der BOD einzuschalten. Das steht auch im Datenblatt.
Arduino Fanboy D. schrieb: > Ich sage: > Das EEPROM ist kritischer bei Spannungsabsenkung, als das RAM. Und woher stammt diese Erkenntnis? Ja, im EEPROM kann bei Spannungsabsenkung die Adresse, auf die der Schreibzeiger gerade zeigt, korrumpiert werden. Das steht extra (etwa verklausuliert) im Datenblatt, weil man das so nicht erwartet. Zum SRAM steht da schlicht gar nichts, weil dort niemand irgend eine definierten Inhalt nach einem Reset erwartet. Oliver
Stefanus F. schrieb: > In diesem > Fall haben wir kein Unterschreiten der minimalen Betriebsspannung, Doch natürlich. Sonst bräuchte man keine BOD.
Karl B. schrieb: > Stefanus F. schrieb: >> (zumindest teilweise) NICHT initialisiert wird. > > Hi, > also bei mir ist etwas Zufälliges drin dann. Manchmal hält es die Daten, > manchmal auch nicht. Das ist auch das, wovon ich grundsätzlich ausgehen würde, wenn mein Programm startet. Karl B. schrieb: > Stefanus F. schrieb: >> Du meinst sicher das BIOS, nicht Windows ME. > > Hi, > so in etwa sieht das aus, wenn man den Museumsrechner hochfährt: > > Das ist nicht der BIOS Schirm. Und was davon ist jetzt der "Power on Self Reset mit Hochzählen der Adressen", von dem du sprachst?
Karl B. schrieb: > Aber Inhalt vom Bios beim Start, erst Energy Saving Logo etc. > OK. Mal sehen, ob ich den noch flott bekomme. Dann zeig ich's. Hi, versprochen. OK. Kam noch Keyboard-Error.-) Zählt schon das RAM durch. ciao gustav
Arduino Fanboy D. schrieb: >> Deshalb ist bei >> EEPROM-Nutzung immer der BOD einzuschalten. > Das steht auch im Datenblatt. Ja klar. Das ist richtig. Es ist und bleibt aber dabei: Das EEPROM und der Flash behalten die Daten bei einer BOD. Das RAM aber eben nicht (garantiert).
Thomas E. schrieb: > Deshalb ist bei EEPROM-Nutzung immer der BOD einzuschalten. Oliver S. schrieb: > Ja, im EEPROM kann bei Spannungsabsenkung die Adresse, > auf die der Schreibzeiger gerade zeigt, korrumpiert werden. > Das steht extra (etwa verklausuliert) im Datenblatt, > weil man das so nicht erwartet. BTDT Ich hab's nicht verbrochen, durfte aber anschließend für einem Großkunden das Nachflashen (bzw. Nachfusen) von einigen Tausend Geräten im Feld organisieren. :(
Oliver S. schrieb: > Ja, im EEPROM kann bei > Spannungsabsenkung die Adresse, auf die der Schreibzeiger gerade zeigt, > korrumpiert werden. Zumindest in dem Punkt besteht Einigkeit! Oliver S. schrieb: > weil dort niemand irgend eine definierten Inhalt nach einem Reset > erwartet Immerhin wurde eine .noinit Section eingeführt (AVR-gcc). So dass dir eigene Experimente+Versuche möglich sind. Oliver S. schrieb: > Und woher stammt diese Erkenntnis? Aus meinen Versuchen! Thema dabei war: Batteriewechsel, ohne Datenverlust. Erkenntnis daraus: Wenn der Maschinenstatus sagt: Power on Reset Dann große Wahrscheinlichkeit, dass RAM Daten korrupt. Wenn der Maschinenstatus sagt: BOD Reset Dann große Wahrscheinlichkeit, dass RAM Daten ok. Darum sagte ich auch: Arduino Fanboy D. schrieb: > Aber wie immer: > CRC/Prüfsumme kann die Zuverlässigkeit der Erkennung gültiger Datensätze > verbessern. Nebenbei haben die Versuche ergeben, dass die Daten bei Absenkungen auf 1,1V sehr zuverlässig erhalten bleiben. Auch wenn die 1,1V über Stunden anliegen. Meine Versuche habe ich mit ATMega328P angestellt. Vermutlich wird die untere Grenze Exemplarstreuungen unterliegen und auch vom konkreten AVR Type abhängig sein. Nein schrieb: > Das RAM aber eben nicht (garantiert). Eine Garantie kann man nicht darauf geben! Wo habe ich das gemacht? Die fantasierst du dahin.
Stefanus F. schrieb: > Es geht doch um den Fall, dass die Spannung nur ein bisschen unter 4,3V > sinkt und der Brown-Out Detektor auf 4,3V eingestellt ist. In diesem > Fall haben wir kein Unterschreiten der minimalen Betriebsspannung, das > RAM funktioniert noch, es gehen keine Daten verloren. Was ist denn das für ein an den Haaren herbeigezogener Fall? Wenn die Spannung unter 4,3V fällt, schaltet der BOD auf Reset. OK. Und dann bleibt die Spannung bei 4,2V stehen, damit der RAM-Inhalt erhalten bleibt, oder was? Und irgendwann steigt die Spannung wieder an und alles ist wie vorher? Hauptsache was schreiben, auch wenn es der größte Blödsinn ist.
Thomas E. schrieb: > Wenn die Spannung unter 4,3V fällt, schaltet der BOD auf Reset. OK. Und > dann bleibt die Spannung bei 4,2V stehen, damit der RAM-Inhalt erhalten > bleibt, oder was? Und irgendwann steigt die Spannung wieder an und alles > ist wie vorher? > Hauptsache was schreiben, auch wenn es der größte Blödsinn ist. Zumindest haben wir die GARANTIE(?), dass der Ram Inhalt oberhalb von 1,8V erhalten bleibt. Auch wenn BOD auf 4,3V eingestellt ist. Darum ist die Aussage "BOD ausgelöst = Ram korrupt" in dieser absoluten Weise falsch.
Angehängte Dateien:
-
safe_operating_area.png
38 KB
Arduino Fanboy D. schrieb: > Zumindest haben wir die GARANTIE(?), dass der Ram Inhalt oberhalb von > 1,8V erhalten bleibt. Es gibt im Datenblatt ein Diagramm, dass die absolute Minimalbetriebsspannung in Abhängigkeit der Frequenz darstellt. Die Aussage, dass 1.8V immer noch OK ist, ist eindeutig falsch. Wenn der safe-operating-area-Bereich verlassen wird, ist das RAM-Inhalt als Defekt anzunehmen. Alles andere ist grob fahrlässig.
Nein schrieb: > Es gibt im Datenblatt ein Diagramm, dass die absolute > Minimalbetriebsspannung in Abhängigkeit der Frequenz darstellt. > Die Aussage, dass 1.8V immer noch OK ist, ist eindeutig falsch. Im (BOD) Resetzustand gibt es keine Taktfrequenz mehr. Das Bild ist also für diesen Fall vollkommen irrelevant. Wichtig ist die Aussage im Datenblatt, dass der µC statisch arbeitet. SRAM, nicht DRAM. Somit bleiben die Daten auch ohne Takt erhalten.
Arduino Fanboy D. schrieb: >> Es gibt im Datenblatt ein Diagramm, dass die absolute >> Minimalbetriebsspannung in Abhängigkeit der Frequenz darstellt. >> Die Aussage, dass 1.8V immer noch OK ist, ist eindeutig falsch. > > Im (BOD) Resetzustand gibt es keine Taktfrequenz mehr. > Das Bild ist also für diesen Fall vollkommen irrelevant. > > Wichtig ist die Aussage im Datenblatt, dass der µC statisch arbeitet. > SRAM, nicht DRAM. Somit bleiben die Daten auch ohne Takt erhalten. Ok. Nehmen wir an, das ist so. Wer garantiert dir jetzt, dass die Spannung nicht doch bis auf 1.7V gefallen ist? RAM-Inhalt nach der Rückkehr aus dem Brown-Out ist und bleibt undefiniert.
Meine Fresse, was ist denn hier los? Also zu allererst mal finde ich es super lustig wie ihr euch über mein Assembler-Programm die Mäuler zerreißt. Nur so viel, wenn die Kernfunktionen fertig sind, dauert das Programmieren nicht viel länger als mit einer Hochsprache. Viele der verwendeten Funktionen waren vorher bereits fertig, das einzige was ich noch nicht hatte und erst recht zeitaufwendig basteln musste, waren die GSM-Funktionen. Aber das zu bauen hat echt Spaß gemacht, das war mit der Kerngedanke des Projekts... mal schauen ob ich das hinkriege oder nicht. Die Geschwindigkeit war auch kein Kriterium. 14,7 MHz sind für eine Alarmanlage ziemlich großspurig und werden definitiv reichen. Wieso ich gefragt habe: Ich halte es für möglich, daß das Programm irgendwann aus irgendwelchen Gründen mal crasht. Daher baue ich ein wenig Sicherheit ein, daß ich wenigstens weiß welche Funktion vor dem Crash als letztes ausgeführt wurde oder vom Watchdog abgebrochen wurde. Ich mache das mit dem RAM löschen beim Start/Reset auch. Dann herrschen da stabile Zustände und das Programm hat egal nach was für einem Start/Reset/Crash immer die gleichen Ausgangsbedingungen. Aus der RAM-Lösch-Funktion habe ich nun die ersten beiden Bytes des RAM ausgenommen. Die scheinen sogar einen kurzen Verlust der Betriebsspannung zu überstehen, das ChipErase beim Programmieren überstehen sie nicht. Der Crashtest war auch nicht besonders schwierig... ldi r16,0x88 push r16 push r16 ret -> und tschüss.
Nein schrieb: > Wer garantiert dir jetzt, dass die Spannung nicht doch bis auf 1.7V > gefallen ist? > > RAM-Inhalt nach der Rückkehr aus dem Brown-Out ist und bleibt > undefiniert. Zum zweiten Mal: Arduino Fanboy D. schrieb: > Eine Garantie kann man nicht darauf geben! > Wo habe ich das gemacht? > Die fantasierst du dahin. Zum dritten Mal: Arduino Fanboy D. schrieb: > Aber wie immer: > CRC/Prüfsumme kann die Zuverlässigkeit der Erkennung gültiger Datensätze > verbessern.
Ben B. schrieb: > Der Crashtest war auch nicht besonders schwierig... > ldi r16,0x88 > push r16 > push r16 > ret -> und tschüss. Das hat mit "Crash" nichts zu tun. Du springst halt an eine Adresse und führst den dort stehenden Code aus.
0x8888 liegt aber deutlich oberhalb des Programms in der unendlichen Leere des unbenutzten Flash. Also gibt das auf jeden Fall einen Amoklauf. Keine Ahnung was da im Flash drinsteht und auch keine Ahnung, was der AVR bei illegalen Opcodes macht. Intel-CPUs lösen einen Interrupt aus, der AVR hat sowas nicht. Was ich aber als noch unschöner empfinde, sind Endlosschleifen. Wenn die vom Watchdog unterbrochen werden, weiß man ohne solche Sicherheiten niemals, an welcher Stelle das Programm vorher ausgeführt wurde.
Das hat mit einem Reset nichts zu tun, da tritt gar keiner auf. Was passiert, ist, daß du übers Flashende hinaus ein Programm ausführst. Das Verhalten dazu ist offiziell undefiniert, inoffiziell wird der Programmzeiger irgendwann überlaufen, und dann geht’s halt bei 0 wieder los. Dabei bleibt SRAM-Imhalt sehr wahrscheinlich erhalten. Garantieren kann das aber auch niemand. Oliver
Verstehe das Problem nicht. Auf das RAM zuzugreifen, ohne dort vorher Daten hingeschrieben zu haben (und sei es beim Initialisieren), ist doch üble Programmiertechnik. Es wird immer einen Grenzbereich geben, wo einige Speicherzellen kippen und andere nicht allein durch die Serienstreuung, d.h. i.A. ist der Inhalt undefiniert -> fertig.
Ich denke, wenn man die Standpunkte etwas anders formuliert, wird die Sache möglicherweise etwas klarer und die Diskussion etwas entschärft. Der Punkt bei der BOD ist doch, dass man nicht definitiv sagen kann, dass die Spannung bei ihrem Ansprechen so niedrig ist, dass das RAM seinen Inhalt verliert. Ich denke das wollte auch so niemand behaupten (korrigiert mich, falls ich mich da irre). Es gibt ja verschiedene Level auf die man BOD-Ansprechschwelle stellen kann. Leider ist ja auch ein konkreter Typ nicht genannt, so dass man hier evtl. gewisse Unterschiede feststellen kann. Die Aussage von Nein, ist, gemessen an seinem Datenblatt (magst Du das mal verlinken, bitte?) formal auch richtig. Es steht ja da 1,8V < Vdd. Allerdings hat er in seinem Zitat vielleicht übersehen, dass Fanboy ausdrücklich von "... oberhalb von 1,8V ..." spricht. Neins Antwort, dass "1,8V" nicht noch OK ist, bezieht sich also nicht darauf. Ein Lapsus; kann mal passieren. :-) Ich gehe im folgenden mal von einem ATMega328p aus. (ww1.microchip.com/downloads/en/DeviceDoc/ATmega328_P%20AVR%20MCU%20with %20picoPower%20Technology%20Data%20Sheet%2040001984A.pdf) Danach lässt sich der BOD-Level (Seite 370) bis auf 1,8V herunter stellen und in der Anmerkung ist beschrieben, dass Typen, die für 1,8V Betriebsspannung spezifiziert sind auch genau darauf getestet werden, dass sie bei 1,8V den BOD-Reset auslösen. Daraus ergibt sich eine differenziertere Betrachtung: Wenn der uC mit 1,8V betrieben wird und der BOD-Level darauf eingestellt ist, kann man wohl begründet davon ausgehen, dass das RAM nicht mehr funktionieren muss sobald BOD ausgelöst hat. Wenn aber der uC mit einer höheren Spannung betrieben wird, die über einem der höheren BOD-Level liegt, so wird das RAM noch funktionieren, sobald der BOD-Reset auftritt und solange, wie die Spannung noch über 1,8V liegt. Im Grunde war die Frage des TOs ja auch nicht auf den BOD-Fall bezogen, sondern einen "Crash" ohne das das näher charakterisiert wurde. Stefanus F.s Einwand war insofern etwas lakonisch, denn er bezog sich auf den BOD-Reset, ohne aber einzugrenzen, ob er dabei davon ausgeht, dass die Spannung auf 1,8V abfällt, was ja nicht zwingend der Fall sein muss, oder nicht. Insofern erweitert er den Fokus auf Resets auch auf BOD-Resets. Der Grund aber, warum das RAM seinen Inhalt verliert, liegt zu allererst nicht im Reset begründet (egal ob BOD oder nicht) sondern in der niedrigen Betriebsspannung. Man kann sich das zwar denken, muss es aber nicht und das hat, meiner Meinung nach, erst die Diskussion um den Betriebsspannungsbereich ausgelöst. Ich hoffe das ist hilfreich.
Der schlimmste vorstellbare Crash wäre, wenn der Controller erst ein paar tausend Befehle kreuz und quer durch das Programm fliegt und erst dann ein Reset ausgelöst wird. Da rauszubekommen, an welcher Stelle das Unheil seinen Anfang nahm, wird schwierig. Aber die Methode sollte zumindest Watchdog-Resets zuverlässig abfangen können. Wenn sie bei den restlichen Problemen nur vielleicht eine brauchbare Information liefert, dann ist das immer noch besser als nichts, also bleibt das so. ;) Bislang läuft das Programm aber sehr zuverlässig. Habe bislang nur Tippfehler (falsche Puffergröße) oder einen buffer overrun produziert. Eine nur zum Debuggen verwendete Funktion hat eine SMS in den Speicherbereich der GSM-Variablen hineinkopiert und dort Chaos angerichtet. Solange die nur für LCD-Module verwendet wurde war's egal, für den Sende-Puffer eines USART (keine direkte LCD-Ausgabe) war's etwas ungünstig. Letzters habe ich länger suchen müssen weil der Fehler schwer reproduzierbar war. Aber sonst alles schick.
Ben B. schrieb: > 0x8888 liegt aber deutlich oberhalb des Programms in der unendlichen > Leere des unbenutzten Flash. Also gibt das auf jeden Fall einen > Amoklauf. Keine Ahnung was da im Flash drinsteht und auch keine Ahnung, > was der AVR bei illegalen Opcodes macht. Da steht das drin, was du da reinprogrammiert hast. Oder falls der Bereich durch den Programmer gar nicht angefasst wurde, 0xFF, was soweit ich weiß beim AVR ein NOP ist. Passiert also gar nix, bis dein AVR wieder bei 0 startet. Es werden also weder irgendwelche Register, noch der RAM angefasst. Einen Reset oder "Crash" gibt's da nicht. Was du unter "Crash" verstehst, definierst alleine du. Davon hängt dann ab, was nachher im RAM steht. Wie oben schon geschrieben, solltest du aber davon ausgehen, dass da irgendwas zufälliges drin steht. > Intel-CPUs lösen einen Interrupt aus, der AVR hat sowas nicht. Eine Exception. Interrupts hat der AVR schon.
Nachtrag: BOD war bei den Tests auf die höchste Stufe (4,3V glaube ich) eingestellt und der Reset wurde durch kurzzeitiges Abschalten des speisenden Netzteils (12V-Seite) ausgelöst, nach dem Erlöschen des LCD-Displays wieder eingeschaltet. Das haben die Daten im RAM überstanden, aber es ist wahrscheinlich, daß die Spannung am Controller nicht unter 1..2V abgesunken ist. Das wird reichen, damit das RAM funktionsfähig bleibt. >> Intel-CPUs lösen einen Interrupt aus, der AVR hat sowas nicht. > Eine Exception. Interrupts hat der AVR schon. Klugscheißer. Wenn man etwas absichtlich missverstehen will, ist so eine blöde Bemerkung wohl garantiert.
Ben B. schrieb: > Klugscheißer. Wenn man etwas absichtlich missverstehen will, ist so eine > blöde Bemerkung wohl garantiert. Lass deine Aggressionen doch bitte an jemand anderem aus.
Rolf M. schrieb: > Lass deine Aggressionen doch bitte an jemand anderem aus. So sind Assembler-Programmierer nun mal. Ist doch auch logisch, daß die ständig genervt sind.
Angehängte Dateien:
-
Win_ME_End.jpg
73 KB
Karl B. schrieb: >> OK. Mal sehen, ob ich den noch flott bekomme. Dann zeig ich's. ggg ciao gustav
Beitrag #5666029 wurde von einem Moderator gelöscht.
Beitrag #5666034 wurde von einem Moderator gelöscht.
Beitrag #5666071 wurde von einem Moderator gelöscht.
Beitrag #5666168 wurde von einem Moderator gelöscht.
Beitrag #5666269 wurde von einem Moderator gelöscht.
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.