Ich habe von einem Hersteller von Funkchips mit integriertem uC einen Hinweis bekommen dass man den Code im Flashspeicher zyklisch (1 mal pro Jahr) auslesen und neu schreiben sollte. Dies würde die Lebensdauer des Codes im Flash erhöhen. Soll heißen nach 10 Jahren könnte der Flash sonst anfangen seinen Inhalt zu verlieren. Ich habe noch nie davon gehört dass man das machen sollte. Ist ja auch ziemlich aufwendig und fehleranfällig das Ganze. Ist dies ganz normal bei Flash speichern, dass man diese zyklisch auffrischen muss?
Daniel S. schrieb: > Ich habe von einem Hersteller von Funkchips mit integriertem uC einen > Hinweis bekommen dass man den Code im Flashspeicher zyklisch (1 mal pro > Jahr) auslesen und neu schreiben sollte. Dies würde die Lebensdauer des > Codes im Flash erhöhen. Soll heißen nach 10 Jahren könnte der Flash > sonst anfangen seinen Inhalt zu verlieren. Hallo Daniel, wenn Dein Hersteller das wünscht - tu das. Und sieh' Dich nach einem anderen Hersteller um. Moderne Flash Prozesse in Mikrocontrollern sollten leicht 10J und mehr die Daten halten (ich glaube mich erinnern zu können bei STM irgendetwas mit 30J gelesen zu haben). Was innerhalb weniger Jahre den Flash Inhalt verliert solltest Du kritisch prüfen bevor Du es einsetzt! rgds
@6A66 (Gast) >wenn Dein Hersteller das wünscht - tu das. >Und sieh' Dich nach einem anderen Hersteller um. >Moderne Flash Prozesse in Mikrocontrollern sollten leicht 10J und mehr >die Daten halten (ich glaube mich erinnern zu können bei STM irgendetwas >mit 30J gelesen zu haben). Was innerhalb weniger Jahre den Flash Inhalt >verliert solltest Du kritisch prüfen bevor Du es einsetzt! Ich denke, ob 10 Jahre, oder 30, darum ging es hier wohl nicht. Sondern einfach darum, daß der Flash irgendwann anfängt die Daten zu verlieren, so daß man vorher, ehe es soweit ist, mal den Flash auffrischen soll. Bei Atmel/PIC sind (oder zumindest waren) es auch nur 10 Jahre. Daß da 1 Jahr als Interval genannt wurde, ist wohl einfach ein Wert mit reichlich Reserve, falls der Flash doch schon eher als 10 Jahre schlapp machen sollte. Genau 10 Jahre Intervall würde ich daher auch nicht nehmen, denn es gibt sicherlich Ausreiser. Wenn Du das jedes Jahr machts, kannst Du trotzdem noch tausende Jahre das Ding damit am Leben erhalten.
Daniel S. schrieb: > Soll heißen nach 10 Jahren könnte der Flash > sonst anfangen seinen Inhalt zu verlieren. In 10 Jahren können auch allerhand andere Dinge defekt werden, und der Flash lebt noch. ;-) Ansonsten sollte die Datenerhaltsdauer im Datenblatt stehen. > Ich habe noch nie davon gehört dass man das machen sollte. Ich auch nicht. Menschen ohne Elektronikkenntnisse könnten es in der Regel auch gar nicht. Was wäre denn mit allen Industriegeräten, die Jahre lang zuverlässig laufen sollen? Bspw. eine große Produktionsanlage? Macht man da laufend Flash-Updates an allen SPSen? Oder die Steuergeräte im Auto, oder allen Elektronikgeräten im Haushalt? Bei einigen meiner Hameg-Meßgeräte sind Datenerhaltszeiten von 20 Jahren für z.B. die GAL-Bausteine angegeben. Sie werden auch auslesegeschützt sein. Die 20 Jahre sind aber jetzt um. Da muß man einfach abwarten, was passiert, und ob überhaupt was passiert. Sie könnten ja auch 40 oder 50 Jahre halten.
Jens G. schrieb: > Ich denke, ob 10 Jahre, oder 30, darum ging es hier wohl nicht. Sondern > einfach darum, daß der Flash irgendwann anfängt die Daten zu verlieren, > so daß man vorher, ehe es soweit ist, mal den Flash auffrischen soll. Hallo jens, wie soll das - vernünfigerweise - gehen? Der uP sichert eine FLASH-Page ins RAM sowie die Programmierroutine. Dann Startet er dir Programmierroutine, löscht die Page, überschreibt Sie und prüft Sie dann - das im Laufenden betrieb. Woher weiß er dass die page noch richtig ist? Klar ginge so etwas. Habe ich aber im Consumerbereich noch nie davon gehört dass das implementiert ist. Im Industrial-bereich wäre ich mit dem Einsatz solcher Techniken auch sehr vorsichtig, da würde ich gerne mal den TÜV dazu hören was der davon hält. Prüfung auf Codefehler - ja, mit im Hintergrund laufendem Speichertest sowie CRC. Und wenn's dann Fehler gibt abschalten. Jens G. schrieb: > daß der Flash irgendwann anfängt die Daten zu verlieren, Ich würde die im original "eingeforderte" maßnahem des Herstellers eher als Korrektor eines Flaws sehen. Entweder die Speicher halten - dann muss er sich keine Gedanken machen. Oder sie halten nicht - dann muss das datenblatt das eben sagen. Aber mal auf Verdacht nach einem jahr ... Komisch! rgds
6A66 schrieb: > Prüfung auf Codefehler - ja, > mit im Hintergrund laufendem Speichertest sowie CRC. Und wenn's dann > Fehler gibt abschalten. Gelegentlich macht man es in industriellen Anlagen auch so. Oder die Schaltung wird von einem externen Watchdog überwacht, z.B. über ein CAN-Bus-Protokoll. Wenn die Baugruppe nicht mehr antwortet, weiß die Steuerung Bescheid.
Jens G. schrieb: > Bei Atmel/PIC sind (oder zumindest waren) es auch nur 10 Jahre. Hm Ja, du bist nicht mehr so auf dem laufenden ;-) AVR (Mega168P) Datenblatt: > Reliability Qualification results show that the projected data retention > failure rate is much less > than 1 PPM over 20 years at 85°C or 100 years at 25°C. Hersteller wechseln! Ist ja Furchtbar. Jedes Jahr den Flash neu schreiben? Mit der obigen Lebenserwartung scheint es nahezu ausgeschlossen dass der Flash irgendwann in der Lebenszeit des Systems probleme machen könnte. Vor allem bei Zimmertemperatur. gruß cyblord
Danke für die Antworten. Ich arbeite als Freiberufler im Auftrag. Also muss ich das wohl so machen wie gewünscht. Prozessor hätte ich schon lange gewechselt. Der Temperaturbereich wird voll ausgereizt. Das Produkt wird ganzjährig draussen in der Sonne betrieben. Im Datenblatt steht dazu dass bei 85° 10 Jahre Flash Data Retention. Dazu noch ein tolles Diagram das bei 15° 30000Jahre :-) vorgibt und dann bei 85° auf 10Jahre abfällt. > Reliability Qualification results show that the projected data retention > failure rate is much less > than 1 PPM over 20 years at 85°C or 100 years at 25°C. Das ist wenigsten eine Angabe von Atmel mit der man rechnen kann. 32kByte = 256kBit bei 1ppm in 20 Jahren. Dann würde ich mir keine Sorgen machen bezüglich der Laufzeit. Aber so? Bleibt die Frage ob es Sinn macht das Flash aufzufrischen. Dadurch erhöht sich auch die Fehleranfälligkeit. Man kann das ja gar nicht 100% sicher machen. Die page auf die der Resetvector zeigt kann nicht ohne Risiko neu geflasht werden. Bricht die Versorgungsspannung zusammen oder wird das Gerät am Schalter ausgeschaltet während diese Page gelöscht wird ist das Gerät tod. Den Chiphersteller möchte ich hier nicht nennen. Da ich mich persönlich ganz gut mit denen verstehe und auch der Support gut ist.
Das Ding wird wohl kaum 10 Jahre bei 85° betrieben, Sonne hin oder her, es ist ja auch mal Nacht. Außerdem, musst Du 10 Jahre Garantie auf deine Bastellösung geben? Dann würde ich es lieber ganz sein lassen.
Wieso Bastellösung? Natürlich muss ich keine 10 Jahre Garantie geben. Aber trotzdem würde ich gerne das Gerät so entwickeln dass es so lange hält wie nur eben möglich. Ich möchte selbst auch nicht dass jedes Gerät nach der Garantie gleich kaputt gehen darf. Klar hat es keine dauerhaften 85°. Also sollte schon passen. Aber das muss der Projektverantwortliche entscheiden. So wie ich es jetzt aufgefasst habe ist es keineswegs "normal" dies jährlich zu machen.
Wilhelm Ferkes schrieb: > Gelegentlich macht man es in industriellen Anlagen auch so. Oder die > Schaltung wird von einem externen Watchdog überwacht, z.B. über ein > CAN-Bus-Protokoll. Wenn die Baugruppe nicht mehr antwortet, weiß die > Steuerung Bescheid. Hauptsache du weißt Bescheid.
Wenn Elkos in deiner Elektronik verbaut sind, so sind die sowieso 100%ig eher Platt als das Flash.
Daniel S. schrieb: > Bleibt die Frage ob es Sinn macht das Flash aufzufrischen. Wie soll das passieren? Seite löschen und neu programmieren? Ist imho riskant und bedeutet Stress für die Zellen. Eher würde es sich wohl anbieten, ohne zu löschen alles mit den gleichen Daten noch einmal zu programmieren, um die Ladungen in den Zellen aufzufrischen. Im Automotive Bereich sind solche Verrenkungen nicht üblich. Und dort sind auch hohe Umgebungstemperaturen üblich und 10 Jahre Lebensdauer wären deutlich zu wenig.
Das ist natürlich auch eine Idee mit nur neu programmieren. Aber bringt das was? Ist eine 1 Ladung vorhanden oder Ladung nicht vorhanden? Mann kann Zellen ja nur von 1 auf 0 programmieren beim Flash. Wenn 0 heißt Ladung aufbringen dann würde diese Art funktionieren. Sonst wohl eher nicht. Elkos gibt es aus dem Alterungsgrund nicht.
Daniel S. schrieb: > Natürlich muss ich keine 10 Jahre Garantie geben. Aber trotzdem würde > ich gerne das Gerät so entwickeln dass es so lange hält wie nur eben > möglich. Ich möchte selbst auch nicht dass jedes Gerät nach der Garantie > gleich kaputt gehen darf. Hallo Daniel, in der Industrie sind Geräte mit 20a erwarteten "Lebenszyklus" nicht unüblich. Das muss aber dann eben mit entsprechender Schaltung "ingineursmäßig entwickelt" (O-Ton TÜV) sein. Dazu solltest Du jedes Bauteil hinsichtlich der Ausfahllmöglichkeiten (ich sage jetzt nicht -wahrscheinlichkeit sonst kommt da jemand womöglich auf die 61508 und die macht hier keinen Sinn) betrachten. Das geht schon in die Richtung Zuverlässigkeiti und Reliability. Angesprochen wurden da speziell auch die AL-Elkos, da musst Du reinschauen. Auch in das Thema Quarzdrift. Und was alles noch so verbaut ist. rgds
Daniel S. schrieb: > Ich habe von einem Hersteller von Funkchips mit integriertem uC einen > Hinweis bekommen dass man den Code im Flashspeicher zyklisch (1 mal pro > Jahr) auslesen und neu schreiben sollte. Dies würde die Lebensdauer des > Codes im Flash erhöhen. Soll heißen nach 10 Jahren könnte der Flash > sonst anfangen seinen Inhalt zu verlieren. Dazu vielleicht einen anderen Vorschlag der sich vielleicht leichter umsetzen lässt. Das System wird nur auf Speicherfehler (backround Memtest, dazu musst du Dir einen guten raussuchen, mit CRC) des Flash geprüft. Wenn die Baugruppe tatsächlich ausgefallen (wird ja nicht gefahrbringend ausfallen) ist wird Sie gewechselt gegen eine die bei Umgebungstemperatur gelagert worden ist und daher in der Ausfallwahrscheinlichkeit midestens eine Dekade besser sein sollte, die sollte dann wieder solange halten. Damit brauchts Du keine Verrenkungen zur selbständigen "FlashAuffrischung" (ich gehe davon aus dass das gerät das selbständig durchführen soll und nicht ein Wartungstechniker) machen. Und ich nehme mal an dass da eher etwas anderes ausfällt als das Flash. rgds
Mach doch eine CRC über den Flash und prüfe somit die Integrität der Daten. Wenn dann was schief geht, dann kann immer noch der Kunde entscheiden ob er neu flasht. Edit: 6A66 war gerade schneller und ich hab zu langsam gelesen. :)
@6A66 (Gast) >wie soll das - vernünfigerweise - gehen? ... Du hast ja recht. Mir ging es jetzt schlicht und einfach nur darum: wenn der Hersteller nur 10 Jahre garantieren würde, und Du willst die Funktion auch noch darüber hinaus erhalten, und nicht zufällig irgendwann mal zu unpassender Zeit in Probleme wegen korruptem Code laufen, dann macht es sicherlich Sinn, deutlich vor der garantierten Zeit mal wieder den Flashinhalt zu erneuern (quasi als Wartungsmaßnahme). Wie Du das machst, oder ob Du das überhaupt machst, sei Dir überlassen. Mir ging es jetzt nicht darum, ob die 10 Jahre Garantie noch zeitgemäß sind, oder das 1 Jahr Interval nicht einen eingebauten Pfurz bedeuten könnten (ich gebe zu, das 1 Jahr Intervall kommt mir auch ziemlich übertrieben vor). @cyblord ---- (cyblord) >Hm Ja, du bist nicht mehr so auf dem laufenden ;-) Das darfst Du laut sagen. Sind bestimmt schon fast wieder 10J. her, daß ich mal ernsthaft und konzentriert was mit Atmel+Pic machte. SO ungefähr aus der Zeit stammt noch mein Altwissen ;-) Aber wie gesagt, es ging mir jetzt nicht um den konkreten Wert für die Retentionzeit. >AVR (Mega168P) Datenblatt: >> Reliability Qualification results show that the projected data retention >> failure rate is much less >> than 1 PPM over 20 years at 85°C or 100 years at 25°C. >Hersteller wechseln! Ist ja Furchtbar. Jedes Jahr den Flash neu Gut - dann wurde damit mein Flash auf dem Hals ja endlich mal wieder mit aktuellen Daten gefüttert ;-)
Daniel S. schrieb: > Ist eine 1 Ladung vorhanden oder Ladung nicht vorhanden? Wenn es denn so einfach wäre... die Ladung für 0 oder 1 besteht aus mehr als einem Elektron. Und die Schaltung, die entscheidet, was es denn nun ist, hat auch Toleranzen. Dazu kommt, dass nach und nach Elektronen durch die Barriere tunneln, viiiiiel langsamer als beim Löschen/Programmieren, aber sie tun es. Also wird man beim Programmieren immer reichlich Überschuss in das floating Gate einbringen, so viel als möglich. Und diesen Überschuss könntest du auffrischen. Dummerweise ist das aber auch mit Stress für die Isolierschichten verbunden und der Schuss kann nach hinten losgehen. Ich würde mit dem Hersteller (aber mit einem Ingenieur und nicht dem Vertriebler) noch einmal intensiv über das Thema diskutieren.
Im Extremfall den Chip mit einem kleinen Pelztier kühlen wenns zu warm wird... Oder wie schwer wäre es, ein RAM ~50 Jahre sicher unter Spannung zu halten? Man könnte das Programm auch in einem echten ROM unterbringen und ein System mit echter CPU und RAM verwenden. Wie lange würde es eigentlich dauern, 64K selbst neu zu flashen? Hat das mal jemand getestet?
Ben _ schrieb: > mit einem kleinen Pelztier kühlen Das stelle ich mir bei den Temperaturen reichlich schwierig vor. Wenn Du Umgebung +85DEG hast (und damit auf der Heißen Seite des Pelztiers :) ) dürfte das bis 100DEG warm werden damit es noch Wärme abgibt. Geht das überhaupt noch bis 100DEG :) Im übrigen Daniel: Das gilt auch für Dich: +85DEG ambient heißt an so manchem Bauteil so etwa 100DEG. Da solltest Du auch noch mal drüberschauen. rgds
Vielen Dank für die Antworten. Das soll schon in größeren Stückzahlen laufen. Der Kunde soll gar nichts daran machen. Auch einen Servicetechniker gibt es nicht. So wie es ausgeliefert ist soll es solange wie möglich laufen. Wenn ich feststelle das der Flashinhalt korrupt ist, dann ist es zu spät. Ich kann dann nix mehr machen. Naja vielleicht den Code doppelt in den Chip brennen wenn genug platz ist. Das würde die Lebensdauer wohl auch erhöhen. Wenn eine CRC nicht mehr passt einfach den code aus der Copie reinkopieren. Klar besteht die LAdung nicht aus einem Elektron. Anders gefragt. Wird beim Löschen einer Zelle Ladung neu aufgebracht oder abgezogen? Einfach noch mal drüber programmieren kann ja entweder Ladungen neu aufbringen oder nochmal abziehen. Nicht aber beides oder?
Wie warm das Ding wird ist ja einigermaßen egal (muß nur unterhalb der zulässigen Maximaltemperatur bleiben und die Differenz kalt-heiß darf nicht zu groß werden). Du mußt dann auf jeden Fall zusehen, daß das Ding entweder einen ausreichend großen Kühler bekommt, besser wäre direkter Kontakt zum Gehäuse oder so. Denke aber, daß man da keine hohe Leistung braucht, so 2-3 Watt Kühlleistung dürften den IC merklich abkühlen. Zuviel ist auch nicht gut, dann gibts Probleme mit Kondenswasser.
Daniel S. schrieb: > Klar besteht die LAdung nicht aus einem Elektron. Anders gefragt. Wird > beim Löschen einer Zelle Ladung neu aufgebracht oder abgezogen? Einfach > noch mal drüber programmieren kann ja entweder Ladungen neu aufbringen > oder nochmal abziehen. Nicht aber beides oder? Definiere Ladung :-) Das können Elektronen sein oder Löcher. Beides geht. Genaueres weiß nur der Hersteller. 85°C Umgebung dauernd sind eine echte Herausforderung. Hast du die Ausfallwahrscheinlichkeiten für das Hühnerfutter auch mal gerechnet? Da kommt man schnell auf böse Werte.
Ich weiß nicht inwieweit sich die Ladungen verhalten, aber wenn du ein Flash löscht, dann schreibst du 1en rein. Wenn du ihn programmierst, schreibst du 0en. D.h. ein erneutes Programmieren ohne löschen schützt dich nicht vor korrupten Code. Auch wenn du 2 Codebereiche hast, die dann vergleichst, wer gibt dir die Garantie das die Kopie noch korrekt ist. Das sind alles nur fehlervermindernde Maßnahmen, die aber einen Defekt nicht ausschließen können. Wenn das passieren soll, dann sollte deine Kunde seine Spec nochmal durchdenken.
So, was mich jetzt wirklich mal interessieren würde wäre wie lange der Controller braucht seinen Flash zu refreshen. Wenn das nur sehr wenig Zeit ist reicht es ja, ihm für diese Zeit eine sichere Versorgungsspannung zu bieten. Den Rest kriegt man durchaus sicher hin, vorausgesetzt der Controller kann nicht von außen resettet oder von irgendwas nicht abschaltbarem gestört werden. EDIT: Du könntest zwei Kopieen des Codes machen. Dann hast Du insgesamt drei Bereiche und wenn einer beschädigt wird, kriegst Du raus welcher. Das Problem ist aber, daß ein "Volltreffer" im Startbereich Deines Codes (also bevor die Kopieen verglichen und der Code ggf. korrigiert wurde) immer noch einen Ausfall verursachen würde. Um sich gegen sowas zu schützen nimmt man dann drei gleiche Rechensysteme, die sich gegenseitig überwachen und den Fehler korrigieren wenn zwei korrekt und einer fehlerhaft arbeiten.
Ich kann nicht kühlen oder heizen. Das ist low cost. Also nur so viel Hardware wie nötig. Es handelt sich um einen RF-chip mit integriertem uC. Da es nur Batteriebetrieben mit Solarunterstützung ist sollte nur so wenig wie möglich Energie verbraucht werden. Zu den Programmierzeiten: Page erase (1k) 2ms, 2byte write timee 20us. Ergibt bei 64k: 128ms + 650ms. Also rund 1sek 2 Bereiche könnte ich mit CRC die gültigkeit eines Bereichs (oder sogar Pageweise) sicherstellen. Aber das ist zu aufwendig denke ich
Du vergisst, daß auch Deine Prüfsummen (liegen ja auch im Flash) getroffen werden könnten. Dadurch würde ein völlig intakter Bereich für ungültig erklärt... Hmm eine Sekunde Vcc aus Kondi ohne daß die zum Programmieren zu weit absinkt... auch noch bei gealtertem Kondi... ich glaub das wird zu groß für ein RF-Modul.
Daniel S. schrieb: > Ich habe von einem Hersteller von Funkchips mit integriertem uC einen > Hinweis bekommen dass man den Code im Flashspeicher zyklisch (1 mal pro > Jahr) auslesen und neu schreiben sollte. Dies würde die Lebensdauer des > Codes im Flash erhöhen. Soll heißen nach 10 Jahren könnte der Flash > sonst anfangen seinen Inhalt zu verlieren. > > Ich habe noch nie davon gehört dass man das machen sollte. Ist ja auch > ziemlich aufwendig und fehleranfällig das Ganze. Ist dies ganz normal > bei Flash speichern, dass man diese zyklisch auffrischen muss? ist mir auch gänzlich neu diese Information. Darf man fragen welcher Hersteller hier gemeint ist?
@Eberhardt: Sorry wie gesagt würde ich das gerne nicht preisgeben. Ich verstehe mich ganz gut mit dem Support dort und würde das gerne nicht aufs Spiel setzen. Die 10 Jahre bei 85° sind aber anscheinend nicht aussergewöhnlich. Bei einem Nuvoton Cortex M0 Prozessor habe ich diese Flash-Data-Retention von 10 Jahren auch gesehen. Ich glaube sogar dass dieser Automotive grade ist.
>Es handelt sich um einen RF-chip mit integriertem uC. Da es nur >Batteriebetrieben mit Solarunterstützung ist sollte nur so wenig wie >möglich Energie verbraucht werden. Die Batterie geht aber auch irgendwann mal zum Sensenmann - wie wird denn da sichergestellt, daß die immer schön frisch bleibt? Ansonsten - wenn man schon Solarzellen hat, warum diese dann nicht als Schattenspender nehmen? Viel mehr als die Lufttemperatur der Umgebung kommt da ja nicht mehr zusammen, wenn die Schaltung selber nicht zuviel Wärme produziert.
Daniel S. schrieb: > Ich habe noch nie davon gehört dass man das machen sollte. Ich auch nicht. Daniel S. schrieb: > Ist ja auch > ziemlich aufwendig und fehleranfällig das Ganze. Stimmt, der Schuß kann ganz schnell nach hinten losgehen. Man muß sich schon den Kopf zerbrechen, das gegen alle Fehlermöglichkeiten abzusichern. Daniel S. schrieb: > Ist dies ganz normal > bei Flash speichern, dass man diese zyklisch auffrischen muss? Nein, das ist sehr unüblich. Ich würde den Hersteller wechseln. Ich vermute mal, nichtmal SSDs machen sowas. Und das sind ja richtig große Datenmengen und mehrere Bits pro Flashzelle. Peter
Daniel S. schrieb: > Ich habe von einem Hersteller von Funkchips mit integriertem uC einen > Hinweis bekommen dass man den Code im Flashspeicher zyklisch (1 mal pro > Jahr) auslesen und neu schreiben sollte. Was bedeutet denn überhaupt "Hinweis bekommen"? Bezieht sich dieser Hersteller auf ein ganz bestimmtes Produkt? Bezieht er sich auf sein eigenes Produkt? Ist das eine offizielle Spezikation, oder ein "guter Rat beim Mittagessen"? Ich hab auch schon interessante Hinweise bekommen: - Dateien auf Diskette immer zweimal hintereinander speichern, weil dadurch die Magnetisierung besser wird und die Daten sicherer halten... - Niemals in der Stadt im 4. Gang fahren, weil dann die Kurbelwelle nicht mehr im Öl dreht und der Motor zwangsläufig kaputt geht... - Interrupts grundsätzlich immer abgeschaltet haben und nur ganz kurz mal während des sog. "Interrupt-Fensters" aktivieren...
Peter Dannegger schrieb: > Ich vermute mal, nichtmal SSDs machen sowas. Und das sind ja richtig > große Datenmengen und mehrere Bits pro Flashzelle. Die haben dafür Fehlerkorrekturmechanismen, können also Bitfehler erkennen und korrigieren und wenn nötig sogar defekte Flashzellen erkennen und Reserveblöcke dafür benutzen. Je nach Controller sortieren sie die Daten auch einfach mal so im Betrieb um. Beim Mikrocontroller ist es halt recht kompliziert, wenn das laufende Programm, dass den Flash neu schreiben soll, selbst aus dem Flash heraus ausgeführt wird. Den Teil, der gerade ausgeführt wird, kann man ja nicht neu schreiben. Die Routine müsste also mindestens zwei Mal in verschiedenen Blöcken vorhanden sein. Prinzipiell müsste es aber schon machbar sein. Wenn man diese Erneuerung jedes Jahr macht, geht man ja davon aus, dass der Flash bis dahin noch in Ordnung ist. Man muss also nicht damit rechnen, dass das Programm defekt ist. Ob es sich lohnt, ist aber eine andere Frage. Dafür müsste man auch abwägen, wie hoch die Wahrscheinlichkeit ist, dass eine Flashzelle beim Neubeschreiben kaputt geht. Ich würde mal beim Hersteller nach den Ausfallwahrscheinlichkeiten fragen. Die wird ja hoffentlich nicht bei 50% nach 10 Jahren liegen sondern sehr viel niedriger. Erst dann lohnt es sich darüber Gedanken zu machen, ob man sowas implementieren sollte/muss.
Man sollte sich auch mal die Schreibzyklen durchdenken wenn man solche Routinen implementiert. Die sind bei Flashzellen heutzutage schon sehr hoch, aber bei zyklischen Refreshzyklen kommen auch mal ein paar Tausend zusammen.
Du kannst den Code zweimal schreiben! Also die Routinen 1:1 übernehmen aber anderst benennen! Beim Start (bzw im Betrieb) wird mit CRC geprüft ob der obere Code IO ist. Wenn nicht dann wird zum unteren Programm gesprungen und dort weitergerödelt. Wenn natürlich die "Checkroutine" fehlerhaft ist, wirds schwierig, vorallem wenn der Bitkipper an der Sprungadresse ist ;-)
Hinweis bekommen heißt dass der Hersteller auf die 10Jahre flash data retention hingewiesen hat (Welche ja auch im Datenblatt stehen) und wenn wir das verlängern wollen sollten wir jährlich das Flash neu beschreiben durch eine Routine zur Laufzeit. Ich sehe das auch so, dass das entweder gar nicht 100% sicher geht oder wenn dann nur mit sehr viel Aufwand. Deswegen wollte ich wissen ob das normal ist und zum Standard bei auf Langlebigkeit ausgelegte Produkte ist.
@Bronco (Gast) >- Dateien auf Diskette immer zweimal hintereinander speichern, weil >dadurch die Magnetisierung besser wird und die Daten sicherer halten... Ja - wenn Du beim zweiten Mal dieselbe Stelle triffst, dann geht das ... ;-) >- Niemals in der Stadt im 4. Gang fahren, weil dann die Kurbelwelle >nicht mehr im Öl dreht und der Motor zwangsläufig kaputt geht... deshalb fahre ich auch immer im 5. oder 6. Gang da durch ... @Thomas Schm (daimonion) >Man sollte sich auch mal die Schreibzyklen durchdenken wenn man solche >Routinen implementiert. Die sind bei Flashzellen heutzutage schon sehr >hoch, aber bei zyklischen Refreshzyklen kommen auch mal ein paar Tausend >zusammen. Aber nicht bei 1 mal pro Jahr
Hallo Daniel, kannst Du mir bitte verraten, ob es sich bei dem Speicher um FRAM handelt,, auf jeden Fall keinen normalen Flash? Ich habe neuerlich gelernt/gehört, ein bekannter IC-Hersteller benutzt FRAM statt Flash als Code-Speicher. Danke für die Antwort Gruß XSHEN
Hallo, nein es ist ganz sicher FLASH. Und es ist kein bekannter Hersteller.
XSHEN schrieb: > Ich habe neuerlich gelernt/gehört, ein bekannter IC-Hersteller benutzt > FRAM statt Flash als Code-Speicher. Texas Instruments hat MSP430 Mikrocontroller mit FRAM im Sortiment. Im folgenden Dokument habe ich gelesen, dass die so ausgelegt sind, dass sie bei 85°C Temperatur 10 Jahre halten. Das wäre ja dann gleich wie bei Flash. Das habe ich in diesem Dokument gelesen: http://www.ti.com/lit/an/slaa526/slaa526.pdf Ein wenig Offtopic, aber ich finde noch interessant, dass das Auslesen von Daten aus FRAM die Daten zerstört und diese wieder reingeschrieben werden müssen. Aber das passiert natürlich alles automatisch auf dem Chip.
Daniel, verrätst du uns bitte noch, was für eine Batterie du verwendest? 10 Jahre Lebensdauer als Solarpuffer bei 85°C sind ein Wort. Ich brauche nur 40°C und lade induktiv nach, aber 10 Jahre schaffe ich nicht.
Batterie ist doch keine drin. Ich war noch auf einem alten Stand der Hardware. Ich denke die Batterie wurde wegen der Haltbarkeit weggelassen. Der Prozessor wird nur über Solar versorgt und mit einem Kondensator gepuffert. Was für ein Kondensator weiss ich aber nicht.
Daniel S. schrieb: >Der Prozessor wird nur über Solar versorgt >und mit einem >Kondensator gepuffert. Was für ein Kondensator weiss ich aber nicht. Daniel S. schrieb vorher: >Elkos gibt es aus dem Alterungsgrund nicht. Entweder vereimerst du uns, oder das ist ein Kondensator aus dem Wunderland.
> - Niemals in der Stadt im 4. Gang fahren, weil dann die Kurbelwelle > nicht mehr im Öl dreht und der Motor zwangsläufig kaputt geht... Was soll denn dieser Bullshit hier schon wieder? Schon mal was davon gehört, daß heutige Motoren Ölpumpen haben, die das Öl an alle relevanten Teile wie zB. die Lager fördern? Wenn die Kurbelwelle im Öl drehen würde dann fängt das Zeug an zu schäumen und wenn die Ölpumpe dann diesen Schaum ansaugt ist das nicht gut für den Öldruck und für die Schmiereigenschaften. Sorry für OT, aber sowas nervt.
Martin Kreiner schrieb: > Daniel S. schrieb: >>Der Prozessor wird nur über Solar versorgt >>und mit einem >>Kondensator gepuffert. Was für ein Kondensator weiss ich aber nicht. > > Daniel S. schrieb vorher: >>Elkos gibt es aus dem Alterungsgrund nicht. > > Entweder vereimerst du uns, oder das ist ein Kondensator aus dem > Wunderland. langsam bekomme ich den Eindruck, dass hier ein Problem von Vaporware und nicht von Hardware diskutiert wird.
Ben _ schrieb: > Was soll denn dieser Bullshit hier schon wieder? Schon mal was davon > gehört, daß heutige Motoren Ölpumpen haben, die das Öl an alle > relevanten Teile wie zB. die Lager fördern? Es ging doch darum, daß man im Leben gelegentlich Ratschläge bekommt, die zwar gut gemeint, aber unnötig bis falsch sind.
Bronco schrieb: > - Interrupts grundsätzlich immer abgeschaltet haben und nur ganz kurz > mal während des sog. "Interrupt-Fensters" aktivieren... Wo liegt da das Problem / welche Nachteile kann das bringen?
Der schrieb: > Wo liegt da das Problem / welche Nachteile kann das bringen? Na, der Sinn eines Interrupts ist es, das Hauptprogramm zeitnah zu unterbrechen, wenn das entsprechende Ereignis auftritt. Wenn Du hingegen eine feste Zykluszeit hast und im Zyklus nur einmal ganz kurz die Interrupts erlaubst, kannst Du auch genauso gut pollen.
Bitte 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.