Hallo liebe Leser, kann es sein, dass das Chip-Erase den Inhalt des SRAMs zurücksetzt? Bei einem Test mit den Sparmatic Zero Heizugsreglern habe ich die Erfahrung gemacht, dass nach einem Chip-Erase der Inhalt der RTC, die im SRAM liegt, auf $00 gesetzt wird. Ein normales RESET oder ein (Über-)Programmieren ohne vorheriges Chip-Erase verändert das SRAM nicht. Der Controller ist ein Mega169PV, Programmiersprache ist ASM, wobei ich das SRAM bei einem RESET absichtlich nicht komplett initialisiere, sondern nur die Zellen, die einen bestimmten Inhalt haben sollen. Da ich dieses "Feature" in keinem Datenblatt oder einer AppNote gefunden habe, frage ich hier.
wenn es "chip erase" heisst, würde ich erstmal davon ausgehen, dass auch der komplette chip (inkl. sram) gelöscht wird.
Davon ausgehen heißt: Nicht wissen. Das Datenblatt sagt FLASH und (bei nicht gesetzter EESAVE-Fuse) EEPROM werden gelöscht, nicht aber (unbedingt) das SRAM...
Na ich hatte es ja probiert, aber mir fehlt so ein bisschen die Bestätigung aus der Community, denn ich kann mir einerseits nicht vorstellen, dass ich der Einzige bin, dem das auffällt und zweitens wäre es ein Ding, wenn das SRAM tatsächlich gelöscht wird und es nirgendwo dokumntiert ist. Ich habe schon an den verschiedensten Ecken des Internets nach diesem Tehma gesucht, bevor ich hier aufschlage, habe aber nichts gefunden. Scheinbar bleibt bei allen anderen AVR-Benutzern das SRAM beim Flashen unverändert, oder niemand hat bislang das Bedürfnis gehabt, Variablen auch nach dem Flashen wieder verwenden zu wollen. Ich möchte ja auch nur wissen, ob das normal ist, denn dann müsste ich die Variablen zyklisch im EEPROM sichern.
Vorstellen könnte ich mir, das im Programmiermodus der SRAM vom Strom abgeklemmt wird sicher das alles genullt wird? Man könnte natürlich auch mal schauen ob das ISP Protokoll es überhaupt erlaubt den SRAM zu beeinflussen.
Ich könnte mir vorstellen, dass das SRAM zum Programmieren genutzt wird, um die Page zwischenzuspeichern. Wissen weiß ich's aber nicht... ...
für den prog-mode wird der reset gepullt ... wenn da der ram nicht resettet wird, wann dann?
weinbauer schrieb: > für den prog-mode wird der reset gepullt ... wenn da der ram nicht > resettet wird, wann dann? Ein Reset bewirkt keinen "Reset des Rams". Desswegen müssen Variablen zur Laufzeit auch noch initialisiert werden. Ich hab das mal ausgenutzt, um z.B. Variablen über einen beabsichtigen Watchdog Reset hinweg zu retten.
Läubi .. schrieb: > Vorstellen könnte ich mir, das im Programmiermodus der SRAM vom Strom > abgeklemmt wird Naja... nicht ganz. Ohne Chip-Erase bleibt alles erhalten. Wenn ich also einfach ein gleiches Programm über das bereits im Flash enthaltene drüberbügele, gibt es keine Probleme mit dem RAM. Läubi .. schrieb: > sicher das alles genullt wird? Noch nicht. Ich bin sicher, dass es eine Menge Speicherzellen im unteren SRAM-Bereich betrifft. Läubi .. schrieb: > Man könnte natürlich auch mal schauen ob das ISP Protokoll es überhaupt > erlaubt den SRAM zu beeinflussen. ??? Hannes Lux schrieb: > Ich könnte mir vorstellen, dass das SRAM zum Programmieren genutzt wird, > um die Page zwischenzuspeichern. Wissen weiß ich's aber nicht... Denkbar, aber warum nur mit Chip-Erase und nicht ohne? Noch dazu gibt es einen eigenen temporären Page-Buffer, der extra vorhanden ist und der über ISP auch gefüllt/verändert wird, bevor die betreffende Page geschrieben wird. elmo schrieb: > Ein Reset bewirkt keinen "Reset des Rams". Desswegen müssen Variablen > zur Laufzeit auch noch initialisiert werden. > Ich hab das mal ausgenutzt, um z.B. Variablen über einen beabsichtigen > Watchdog Reset hinweg zu retten. Exakt, RESET alleine macht am RAM gar nichts. Ich kann den Chip ewig intern oder extern resetten, ohne dass im SRAM ein Bit kippt. Es scheint reproduzierbar nur mit dem Chip-Erase zu tun zu haben.
Servus ! Das ist mir auch aufgefallen im Zusammenhang mit einer RTC, als ich von einem Mega8 auf einen Mega88 umgestiegen bin. Denn bei der ISP-Programmierung wird bei neueren AVRs der SRAM genullt, wobei bei den älteren der SRAM immer einen nicht definierten bzw. vor dem Reset definierten ;) Inhalt hatte. Seitdem verwende ich den Bootloader vom FireFly-Projekt. Dennoch ist dies keine perfekte Lösung, weil der Bootloader ja selbst den SRAM verwendet. Von Atmel hatte ich diesbezüglich ebenfalls nichts gelesen ! Die ham das einfach vo einem Tag am andren geändert ;) Schöne Grüße, Daniel
Danke Daniel, das ist doch mal ein Wort. Wobei der Mega169(P) ja noch ein Chip der älteren Garde ist. Aber gut zu wissen, dass ich nicht alleine bin mit der Feststellung. Mir hat die alte Vorgehensweise mit dem undefinierten bzw. unveränderten RAM besser gefallen. Der Witz ist, dass der STACK nicht automatisch auf RAMEND gesetzt wird, wie das bei allen Controllern ab dem Tiny2313 gemacht wird, das muss man noch selber machen...
Ich könnte mir vorstellen, das es aber gewissermaßen ein "Sicherheitsfeature" ist, da man ja durch einen ChipErase ja auch die Lockbits löschen kann. Damit nun ein Angreifer nicht aus dem RAM noch irgendwelche geheimen Daten nutzen kann wird dieser beim Chiperase gelöscht. (Man könnte sonst ein Programm aufspielen, welches einfach nur den SRAM ausliest und per RS232 raushaut)
Joah, das könnte so sein. Aber warum dokumentiert ATMEL das dann nicht und lässt die Anwender im Nebel stochern...?
Es wäre ja auch sehr schwer einen Sinn darin zu erkennen, dass die Daten im Sram erhalten bleiben wenn man den Flash löscht. Was sollten die Daten im Sram wenn im MC garkein Programm mehr drinne ist ? Gruss K
Naja, wenn man nur eine kleine Änderung an seiner (Zeit(schalt))Uhr macht, aber nicht jedes mal die Zeit neu stellen möchte ;) Man kann ja fixe SRAM-Adressen verwenden und eben in die .noinit - Section geben.
Klaus De lisson schrieb: > Es wäre ja auch sehr schwer einen Sinn darin zu erkennen, > dass die Daten im Sram erhalten bleiben wenn man den Flash löscht. > Was sollten die Daten im Sram wenn im MC garkein Programm mehr drinne > ist ? Stell Dir vor, ein Programm ist im Flash, welches eine RTC hochzählt. Jetzt lädst Du ein Update desselben Programms auf den Controller und WUUUUSCH, alle RTC-Daten sind weg. Somit stellst Du die Uhr neu. Da der Controller nicht weiss, wann das Update kommt, kannst Du nur durch ein zyklisches Sichern im EEPROM sicherstellen, dass die RTC-Daten erhalten bleiben, wenn man neu flasht. Wäre das RAM einfach nur ein stures RAM, wären die Daten noch da, und zwar so lange, bis man den Strom abzieht. Es geht mir aber mehr um die Dokumentation, denn wenn ich weiß, dass das RAM abkackt, dann muss ich mich halt um den Erhalt der Daten kümmern.
Ich hab' diesen 'Effekt' bei einem mega644 als Videogenerator auch bemerkt. Nicht initialisierter Grafikspeicher enthielt nach Reset die Daten von vorher, nach dem Flashen war der gesamte SRAM auf 0x00. Bin mir nicht mehr ganz sicher, aber ich meine, beim EEPROM schreiben war das auch. Hatte aber auch nichts dazu gefunden, welches Verhalten lt. Atmel nun erwartbar wäre. Die 128-byte-Pagegröße und 4kB SRAM widersprächen aber evtl. der Vermutung, es hätte mit dem Zwischenspeichern beim Flashen zu tun, da wird auch, meine ich, kein Page-Buffer verwendet sondern byte für byte eingelesen und direkt in den Flash geschrieben. Ist nur geraten, aber vielleicht wird beim Flashen alles 'abgeschaltet', was nicht benötigt wird (PORTS etc. und halt SRAM), beim RESET bleibt die Spannung erhalten? Beim 6510er war es so, dass man Reset als Funktion nutzen konnte, da der Speicherinhalt erhalten blieb, es wurde nur der Prozessor beeinflusst. Beim AVR müsste man auch noch einen Extra-Schaltkreis einbauen, der das SRAM beim reset x Nano-, oder gar Mili-Sekunden vom Strom trennt damit's sicher gelöscht wird. Macht Arbeit, kostet Geld und schränkt den User unnötig ein. Mark
Andreas K. schrieb: > Der SRAM dient doch nur als eine Art Arbeitsspeicher, oder nicht? Ja und? Bei einem externen RAM-Bausteinen bleiben die Daten auch erhalten, solange keiner den Stecker zieht oder die Batterien herausnimmt. Bei vielen Geräten wurde und wird batteriegepufferter RAM verwendet, um die Betriebsdaten und Presets zu speichern. Trotzdem kann man einen Werksreset oder ein Firmware-Update machen, ohne gleich alle Daten zu verlieren. Diese Funktion hätte ich gerne, aber ich kann und möchte an der Hardware nichts ändern. Nunja.
Mark L. schrieb: > Ich hab' diesen 'Effekt' bei einem mega644 als Videogenerator auch > bemerkt. Aah ja. Mark L. schrieb: > Bin > mir nicht mehr ganz sicher, aber ich meine, beim EEPROM schreiben war > das auch. Das kann man durch setzen der EESAVE-Fuse verhindern. Dann wird das EEPROM bei Chip-Erase nicht angetastet. Mark L. schrieb: > Ist nur geraten, aber > vielleicht wird beim Flashen alles 'abgeschaltet' Dann wäre das SRAM aber nicht sämtlich auf $00, sondern undefiniert. Mark L. schrieb: > Beim 6510er war es so, dass man Reset als Funktion nutzen konnte, da der > Speicherinhalt erhalten blieb, es wurde nur der Prozessor beeinflusst. So kannte ich das bisher auch. Bin mir nicht ganz sicher, aber beim Mega16 ud älter habe ich kein RAM-Löschen registriert. Mark L. schrieb: > der das > SRAM beim reset x Nano-, oder gar Mili-Sekunden vom Strom trennt damit's > sicher gelöscht wird. Nochmal: Abschalten eines SRAM löscht es nicht, sondern lässt es undefiniert wieder hochfahren. Es handelt sich bei den Speicherzellen um FlipFlops, die halt auf 0 oder 1 liegen. Der Startzustand hängt von vielen Faktoren ab und ist zumeist recht zufällig.
Knut Ballhause schrieb: > Nochmal: Und nochmal: Undefiniert heißt nicht das das Ergebnis nicht alles 0 sein kann ;) undefiniert heißt einfach, das der Hersteller keinen definierten Zustand garantiert, das kann 00, FF, AE, oder was zufälliges sein.
Knut Ballhause schrieb: > Ja und? Bei einem externen RAM-Bausteinen bleiben die Daten auch > erhalten, solange keiner den Stecker zieht oder die Batterien > herausnimmt. Ja also, wenn ich nen Chip-Erase durchführe dann wohl nicht um das selbe Programm hinterher nochmal aufzuspielen. Da wird sehr wahrscheinlich eine geänderte Version draufgeschrieben, also was würde ich dann noch mit dem eventuell nicht mehr konsistenten Inhalt des Arbeitsspeichers von früher anfangen wollen? Das bei älteren Chips der SRAM nicht gelöscht wurde würd ich eher als Bug bezeichnen.
Andreas K. schrieb: > Ja also, wenn ich nen Chip-Erase durchführe dann wohl nicht um das selbe > Programm hinterher nochmal aufzuspielen. Ja. Andreas K. schrieb: > Da wird sehr wahrscheinlich eine geänderte Version draufgeschrieben, Genau. Andreas K. schrieb: > also was würde ich dann noch mit dem eventuell nicht mehr konsistenten > Inhalt des Arbeitsspeichers von früher anfangen wollen? Die neue Version verwendet dieselben globalen Variablen am selben Speicherplatz. Andreas K. schrieb: > Das bei älteren Chips der SRAM nicht gelöscht wurde würd ich eher als > Bug bezeichnen. Ansichtssache. Ich mag Chips, die nichts machen, was ich nicht vorher auch angewiesen habe. Die automatische Init der Hardware-Register ist da schon in Ordnung, aber vom User zu definierender Arbeitsspeicher soll doch bitte auch vom User zu definieren sein...
Läubi .. schrieb: > Und nochmal: Undefiniert heißt nicht das das Ergebnis nicht alles 0 sein > kann ;) Ja klar, ich nahm Bezug auf Mark L. schrieb: > vom Strom trennt damit's > sicher gelöscht wird.
lieber so als das dieser löscheffekt wirklich zufällig eintitt solche dinge können dann von gerät zu gerät variiren und für kurioseste effekte sorgen
Knut Ballhause schrieb: > Die neue Version verwendet dieselben globalen Variablen am selben > Speicherplatz. Möglich, aber wie wahrscheinlich ist das? Mit Assembler lässt sich das sicherlich gut kontrollieren, aber unter C krieg ich das nicht wirklich mit, wenn sich die Adressen im Arbeitsspeicher verschieben.
blkfn schrieb: > lieber so > als das dieser löscheffekt wirklich zufällig eintitt > solche dinge können dann von gerät zu gerät variiren und für kurioseste > effekte sorgen Nein. Wenn ich das SRAM initialisieren will, dann mache ich das. Jede im Programm zu nutzende Variable wird bei Programmbeginn ohnehin initialisiert, egal ob das SRAM ausgenullt ist, oder nicht. Man kann sich als Programmierer ohnehin nicht auf einen definierten Zustand eines Arbeitsspeichers verlassen, zumal bei einem RESET keine Ausnullung stattfindet. Wenn ich aber eine Variable später, egal welcher Betriebszustand (außer Spannungsmangel) zuvor eingetreten ist, noch brauche, ist eine automatische Ausnullung problematisch.
Andreas K. schrieb: > Möglich, aber wie wahrscheinlich ist das? > Mit Assembler lässt sich das sicherlich gut kontrollieren, aber unter C > krieg ich das nicht wirklich mit, wenn sich die Adressen im > Arbeitsspeicher verschieben. Aus diesem Grund schreibt man hardwarenahe (wie in diesem Fall gewünscht) und zeitkritische Dinge auch in ASM.
Ist zwar nicht dokumentiert, aber es gibt einen guten Grund, SRAM beim Chip Erase mitzulöschen. Ein Programm speichert sicherheitsrelevante Informationen, z.B. Passwörter im Klartext im SRAM. Der Programmierer hat die Lockbits aktiviert. Ein Hacker lädt nach einem Chip Erase sein eigenes Programm, um das SRAM auszulesen. Ohne SRAM Erase wäre es jetzt möglich, die Passwörter zu sehen!
Knut Ballhause schrieb: > Mark L. schrieb: >> Bin >> mir nicht mehr ganz sicher, aber ich meine, beim EEPROM schreiben war >> das auch. > > Das kann man durch setzen der EESAVE-Fuse verhindern. Dann wird das > EEPROM bei Chip-Erase nicht angetastet. Ich meinte den SRAM, gleicher Effekt (alles 0x00), egal ob ich nur den Flash oder nur den EEPROM neu beschreibe (Chip-Erase war daher deaktiviert), müsste aber mal die Schaltung rauskramen und nochmal genau ausprobieren. Mir war das damals nur so nebenbei aufgefallen und da ich nichts dazu im Datenblatt fand, habe ich das Thema nicht mehr weiter verfolgt. Hab' mich da wohl 'etwas' unglücklich ausgedrückt. Da der Inhalt der einzelnen Speicherzellen undefiniert ist, muss es ja eine Funktion geben, die u.a. beim 'Einschalten' alle Zellen auf 0 setzt. Da die Funktion aber wohl beim Reset unterbleibt ist sie offensichtlich nicht Teil der üblichen Resetprozedur. Einfachste Möglichkeit die mir spontan einfiel, wäre eine Schaltung, die das Aktivieren der Stromzufuhr erkennt, alle Select-Leitungen der Speicherzellen aktiviert und alle auf 0 setzt. Wenn im ISP-Modus nur die benötigten Teile mit Strom versorgt werden, könnte das SRAM auch deaktiviert sein. Keine Ahnung, wie Atmel das nun gelöst hat, aber es würde zu meinen Beobachtungen und dem, was ich hier gelesen habe, passen. Die Datenblätter schweigen sich darüber ja leider aus. Es handelt sich ja anscheinend um ein neues Feature dass der SRAM auf 0x00 gesetzt wird. Aber wie auch immer das umgesetzt wurde, die Frage ist ja mehr die, wann das auftritt (Stromzufuhr, ISP-Zugriff, ???), bzw. wann nicht (Reset, ???). Tiefergehend könnte man noch über die Informationspolitik der Firma Atmel diskutieren ;-)
Das trägt zumindest zur Sicherheit bei. Sonst könnte man Daten / Passwörter im SRAM auslesen, indem man ein entsprechendes Programm flasht. Für einen DS1307 war kein Platz mehr?
Christian H. schrieb: > Aus diesem Grund schreibt man hardwarenahe (wie in diesem Fall > gewünscht) und zeitkritische Dinge auch in ASM. Eingangs gehts um nen Heizungsregler, ich seh da keinen Grund "Hardwarenah" zu programmieren. So wie ich das sehe gehts nur um die fehlende Dokumentation,.
Hab' da was bei Atmel gefunden: http://support.atmel.no/bin/customer.exe?=&action=viewKbEntry&id=959
Mark L. schrieb: > Hab' da was bei Atmel gefunden: Okay, das sagt zwar nichts über das Problem, aber die 32 Arbeitsregister scheinen als Alternative zum Retten der RTC übrigzubleiben. Muss ich mal testen. Andreas K. schrieb: > Eingangs gehts um nen Heizungsregler, ich seh da keinen Grund > "Hardwarenah" zu programmieren. Ha, der war gut. Was spricht dagegen? ;-) Andreas K. schrieb: > So wie ich das sehe gehts nur um die fehlende Dokumentation,. Ja. So ist es.
Es steht doch nirgends, daß nach einem ISP-Programming das SRAM erhalten bleibt. Also wüßte ich nicht, warum man dann Atmel eine Vorwurf machen sollte. Wenn Du willst, daß der SRAM erhalten bleibt, mußt Du eben einen Bootloader verwenden. Der SPM-Befehl ändert das SRAM nicht. Peter
Knut Ballhause schrieb: > Ha, der war gut. Was spricht dagegen? ;-) Es wäre äußerst gründlich und die passenden Utensilien finden sich auch vor Ort, und dennoch: Ich putze mein Bad nicht mit der Zahnbürste. ;)
Peter Dannegger schrieb: > Es steht doch nirgends, daß nach einem ISP-Programming das SRAM erhalten > bleibt. > Also wüßte ich nicht, warum man dann Atmel eine Vorwurf machen sollte. Umgekeht wäre besser. Einfach sagen, was Sache ist. Alles andere ist haarklein beschrieben. Peter Dannegger schrieb: > Wenn Du willst, daß der SRAM erhalten bleibt, mußt Du eben einen > Bootloader verwenden Ein Bootloader ist zwar immer gern gesehen, hier aber momentan keine Option.
Andreas K. schrieb: > Ich putze mein Bad nicht mit der Zahnbürste. Ich auch nicht. Der Vergleich hinkt. Da in diesem System fast ausschliesslich mit Pins getoggelt wird und Hardware-Interfaces bedient werden, drängt sich ASM förmlich auf. Okay, ein paar Berechnungen wären in C vielleicht elegant zu erschlagen gewesen, aber die habe ich auch ohne Arithmetik-Lib hinbekommen. Aber das führt hier jetzt am Thema vorbei. Zudem denke ich, dass soweit alles gesagt ist. Danke für alle Informationen zum Thema.
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.