Hallo allerseits, ich hab seit heute meine microsd-Karte mit uC am laufen. Beschrieben wird sie mit FAT16/FAT32. Mich würden Eure Erfahrungen interessieren, wenn der uC während des Betriebs abgeschaltet wird. Meine Anwendung ist ein Logger, der in 1..3 Files auf der Karte schreibt, Auswertung dann auf PC. Dazu gibts noch Files auf die nur lesend zugegriffen wird (config etc.) Hattet Ihr durch unkontrolliertes Abschalten schon Datei-System Probleme? Oder geht's Euch wie zu DOS-Zeiten dass meist nichts passiert? Mußtet Ihr Gegenmaßnahmen treffen (chkdisk embedded, interrupt fclose bei spannungsverlust...) Gruß Gerd.
P.S.: Auch beim debuggen passierts daß man fread() oder fwrite() unterbricht, dann kein fclose() mehr kommt und beim nächsten debuggen wieder fopen() auf ein eigentlich geöffnetes File. Hattet ihr je irgendwelche Probleme damit? Gruß Gerd.
Aus ähnlichen Gründen habe ich eine Lösung mit fest angelegten Dateien gewählt, wo nur einzelne Sektoren beschrieben werden, ganz ohne FAT-Zugriffe.
> Hattet Ihr durch unkontrolliertes Abschalten schon Datei-System > Probleme? Da passiert genau dasselbe wie bei richtigen Computern, das Dateisystem wird zerstoert. > Oder geht's Euch wie zu DOS-Zeiten dass meist nichts passiert? Das ist falsch, oder besser gesagt kommt daher das du meistens den Rechner abschaltest wenn er nichts mehr macht. Man muesste ja schon besonders dumm gewesen sein wenn man z.B in seiner Textverarbeitung "save" ausgewaehlt hat und gleichzeitig den Stecker zieht. Ich sehe nur zwei Loesungsansaetze: 1. Du schaffst dir eine LED welche anzeigt wenn eine Datei offen ist und schaltest dann nicht ab. Das ist sozusagen die DOS-Loesung. 2. Dein Controller kann sich selber abschalten und bekommt eine Taste mit der du ihn lediglich mitteilst das er sich nun abschalten soll. Dann schaltet er sich einfach erst ab wenn er alles geschrieben hat. So machen das z.B Digitalkameras. Olaf
Und nicht zu vergessen: Es gibt Leute die einfach die Karte ziehen ohne vorher abzuschalten. Da hilf nur sehr oft den Carddetect Kontakt abzufragen und dann die Kartenzugriffe zu unterbrechen.
ich glaub das ist mir passiert. Program ist unter SD-Zugriff hängengeblieben. Das nicht geschlossenen File blockiert jetzt glaub ich alle Schreibzugriffe. SD Karte lässt sich nicht mehr beschreiben/formatieren. Ich glaub die ist hinüber. mfg J.K
>Ich glaub die ist hinüber.
Schreib in den Sektor 0 einfach mal alles Nullen.
Dann solltest du wieder formatieren können.
selten so ein mist gelesen... erstens: durch Dataisystemoperationen kannst du keine Hardware (also die Karte selber) beschädigen. Schon mal mit chkdsk probiert??? Zweitens: ob eine Datei geöffnet wurde oder nicht, wird gar nicht auf dem Datenträger gespeichert. Die Datei wird beim öffnen nicht verändert! Probleme mit dem Dateisystem gibts nur, wenn schreibzugriffe unterbrochen werden. Das hat nix mit dem vorhanden sein von geöffneten Dateien zu tun!!
p.s. Das bezieht sich natürlich auf gast666, nicht auf holger.
chkdsk hab ich probiert, streikt keine ahnung von was das genau kommt. die Karte mit 0 zu beschreiben hab ich schon probiert (mit µC) hat nicht funktioniert, hat nichts beschreiben können. gibt es pc Programme die das können? vllt. ist die Karte zufällig gerade kaputt geworden?! mfg J.K
>Probleme mit dem Dateisystem gibts nur, wenn schreibzugriffe >unterbrochen werden. Das hat nix mit dem vorhanden sein von geöffneten >Dateien zu tun!! Um mit deinen Worten zu antworten "99.9% Schwachsinn". Denn Probleme gibts nur dann wenn die FAT auf der Karte noch nicht korrekt aktualsiert wurde und nur dann wenn die gerade zu schreibende Datei ihre Größe verändert hat. Wenn die FAT Software gut programmiert ist so wird sie die FAT sofort verändern noch bevor die zu schreibenden Daten der Datei geschrieben werden. Dann kann im Grunde nur der kurze Zeitraum in dem man die FAT aktualisiert zur Zerstörung der FAT führen. Alle weiteren Fehler beziehen sich dann nur auf die Daten der Datei selber, dh. die Dateiinhalte sind falsch. Da man aber die Lebenszeit der FAT, bzw. der Speicherbereiche der SD-Karte an dem die FAT liegt, verlängern möchte, schreibt man die FAT nicht ständig neu. Oft benutzt man also eine lokale Kopie der FAT die im SRAM liegt und modifiziert dann bei Dateiänderungen in dieser Kopie. Erst nach einem Timout oder explizit wird diese Kopie der FAT auf die SD Karte zurückgeschrieben. Macht die FAT Software das exakt so dann verlängert sich der Zeitraum bei dem in der FAT Fehler entstehen können drastisch. Gruß Hagen
in wie fern widerspricht das jetzt meiner Aussage? Ich habe nicht geschrieben, dass jeder unterbrochene Schreibzugriff zu Dateisystemfehlern führt. Aber danke, dass du meine Aussage nochmal im detailierter erläutert hast. Zum Thema Lebenszeit der SD-Karte: Die SD-Karten haben intern einen mechanismuss, mit dem schreibzugriffe auf den selben logischen Sektor immer wieder auf andere physikalische Sektoren umgeleitet werden. Davon bekommt die Software natürlich nix mit. So wird versucht zu verhindern, dass die FAT Sektoren vorzeitig ihren Geist aufgeben.
>Probleme mit dem Dateisystem gibts nur, wenn schreibzugriffe >unterbrochen werden. Stimmt eben nicht. Es gibt keine Probleme mit der FAT wenn Schreibzugriffe in eine Datei unterbrochen werden. Denn dann gibts nur Probleme mit Fehlern innerhalb dieser Datei und nicht der FAT (mal abgesehen von den letzten par Bytes im Sektor der ja ebenfalls zu FAT gehört). Ist die Software sauber so betrifft dies 99.9% aller Fehler, rein statistisch müsste man also schon exakt den kurzen und seltenen Moment abpassen indem man die FAT schreibt. Und diese Zeitspanne kann man schon sehr stark verkürzen falls man eben keine Kopie der FAT im SRAM hält. Nee, was mich stört ist die Annahme das alle Menschen exakt das gleiche Wissensniveau haben müssen als man selber. Und wenn dies logischerweise nicht der Fall ist beleidigt man die Leute von oben herab ohne eigentlich das eigene Wissen vollständig und nachvollziehbar zu transferieren. Sogesehen nur ein kleiner Hieb gegen Dich ;) Exakt müsste es so lauten: Problem mit dem Dateisystem gibts nur wenn Schreibzugriffe in die relevante Struktur dieses Dateisystemes unterbrochen werden. Die FAT wird zb. nicht zerstört wenn man den Schreibzugriff auf das Dateidatum unterbricht. Das Datum wäre dann zwar falsch aber die FAT immer noch funktionsfähig. Gruß Hagen
>erstens: durch Dataisystemoperationen kannst du keine Hardware (also die >Karte selber) beschädigen Indirekt geht das schon, die Frage ist was man als "Hardwarefehler" interpretiert. Eine SD Karte kann man über diejenigen Befehle die als Sicherheitsfeature verkauft werden sehr wohl blockieren. Das würde ein Laie dann als Hardwarefehler interpretieren. Zb. das Passwort heutiger Festplatten. Wenn man es als böser Bube einfach mal aktiviert und der berechtigte Anwender davon nichts weiß so hat man dieses ausgesperrt. Dieser als Laie würede denken er kann seine HD nicht mehr ansprechen, sie ist kaputt. Evntuell hat also der OP eines dieser Kommandos gesendet, zb. weil er einen Pegelwandler von 5V auf 3.3V per Widerstände benutzt, und somit die SD karte das Kommando falsch interpretiert hat. Halte ich zwar für sehr unwahrscheinlich aber machbar ist es. An den OP: Einige SD Karten besitzen einen Hardware Lock, also nicht der mechanische Schalter an der Seite. Dieser kann per Software de/aktiviert werden. Dazu solltest du man den CSD auswerten. Gruß Hagen
> Es gibt keine Probleme mit der FAT wenn Schreibzugriffe in eine Datei > unterbrochen werden. Denn dann gibts nur Probleme mit Fehlern innerhalb > dieser Datei und nicht der FAT So gesehen wäre man doch auf der sicheren Seite, wenn man wie oben vorgeschlagen die Files vorher mit ausreichender Größe anlegt und wärend des Loggens nur überschreibt? Bei Spannungsausfall/Abschalten wärend des Schreibens hätte man dann maximal die falsche Dateilänge und es fehlten hinten evtl. die letzten Daten im File, oder? Gruß Gerd.
>So gesehen wäre man doch auf der sicheren Seite, wenn man wie oben >vorgeschlagen die Files vorher mit ausreichender Größe anlegt und wärend >des Loggens nur überschreibt? Korrekt, solange der reservierte Speicher der Datei auch ausreichend ist. Verbleibt das Problem wie man nun erkennt wieviel dieser Datei schon benutzt wurde. >Bei Spannungsausfall/Abschalten wärend des Schreibens hätte man dann >maximal die falsche Dateilänge und es fehlten hinten evtl. die letzten >Daten im File, oder? Nein, bzw. im günstigsten Falle. Im ungünstigsten Falle fehlen/bzw. sind falsch am Ende eines Sektors der Datei die Verlinkungen zum nächsten zugehörigen Sektor der Datei. Dann entstehen sogenannte Crosslinks, also zwei Dateisektoren zeigen als nächsten Sektor auf den gleichen. Beide Dateien enthalten ab einem bestimmten Dateiinhalt auf die gleichen Daten. Erkennt man dies nicht und füllt nun eine der Dateien mit neuen Daten so überschreibt man die Daten der anderen Datei. Löscht man nun ein der Datei so gibt man die Crosslink-Sektorenkette ebenfalls mit frei und die Fehler werden immer gravierender je öfter man das macht. Das hängt aber auch von der FAT Softare ab, also wie diese das alles verwaltet und ob sie diese Daten überhaupt manipuliert. Zerstörungen an der FAT kommen eigentlich nur dann häufig vor wenn man diese stark umstrukturiert hat. Also zb. im SRAM eine FAT Kopie hat, darin nun viele Dateien/Verzeichnisse löscht, verändert, umbenennt, neue anlegt und dann beim Zurückschreiben dieser FAT Kopie ein Fehler auftritt. Denn vorher hat man ja alle diese Dateioperationen schon auf die SD Karte geschrieben aber eben nicht die FAT synchron dazu aktualisiert. Gruß Hagen
Theorie & Praxis... Ich habe auch 2 (Zwei) SD-Karten mit dem µC geschrottet.
der Schalter an der Karte ist in der Richtigen Position, dieser wird von meinem µC aber gar nicht ausgewertet
Der hat auch (fast) keine Wirkung. Es kommt drauf an, ob der Kartenleser einen Kontakt hat, der je nach der Position des Schiebers offen oder geschlossen ist.
>erstens: durch Dataisystemoperationen kannst du keine Hardware >(also die Karte selber) beschädigen So stehts auch in der Werbung, aber da hätte ich dann z.B. noch ein paar Compact-Flashs, die durch Abschalten der Versorgungsspannung in ungünstigen Augenblicken das Zeitliche gesegnet haben. Frag mal einer den Hersteller einer Speicherkarte, wieviel Zeit nach dem Schreiben des letzten Blocks die Versorgungsspannung noch anliegen muss, dass der sicher ins Flash geschrieben wird.
was wär denn der Erfahrungswert?
Wenn die Frage >was wär denn der Erfahrungswert? sich auf die Asusage >wieviel Zeit nach dem Schreiben des letzten Blocks die Versorgungsspannung >noch anliegen muss, dass der sicher ins Flash geschrieben wird. bezieht, dann habe ich eine Antwort. Die Zeit, die für ein sicheres Schreiben des letzten übertragenen Blocks nötig ist, nachdem fclose() (oder betriebssystemäquivalente Funktionen) Erfolg melden konnte, ist bei den angesprochenen CF mindestens 300ms. Mit dieser Zeit funktionierten alle untersuchten CF von 6 Herstellern in Größen von 256-1024 MB auf 3 Betriebssystemen. Die Untersuchungen für die SD-Cards musst du selber machen ;-) BTW: Du kannst deine Karte mit FAT-FS übrigens ganz leicht beschädigen oder zerstören: kopiere eine große Datei drauf und ziehe sie während des Kopierens ab.
Ich gehe einfach mal davon aus, dass die weiter oben angesprochenen internen logistischen Funktionen im Flash-Controller auf der Karte eben auch Informationen aus dem Flash benötigen und dort ablegen. Anders kann die Sektor-Relokation ja nicht funktionieren. Der Controller muss sich eben merken, welchen FAT-Sektor er physikalisch wo abgelegt hat. Wird beim Schreiben die Stromzufuhr unterbrochen, so passieren gleichzeitig zwei Dinge: Die 3V versorgung bricht ein und Register kippen nach und nach auf 0. Für das Flashen gibt es noch einen internen DC/DC Wandler im FLASH, der aber nicht zeitgleich mit den Registern spannungslos wird. Ein gutes Beispiel ist hier die Application-Note von ATMEL bzgl. des EEPROMs. Hier wird bei Applikationen, die zur Laufzeit abgeschaltet werden können, abgeraten die Adresse 0x00 im EEPROM zu verwenden. Auch hier kippt zuerst das Address-Register für das EEPROM auf 0, bevor der interne Spannungsgenerator für das Programmieren aufgibt. Die Folge ist eine zerstörte Zieladresse, weil nicht fertig programmiert und eine zerstörte Information an Adresse 0x00, weil 'anprogrammiert'. Schreibt man nun eine Datei auf eine Flash-Card 8 (CF, SD, MMC, egal) und klemmt die Versorgung ab, dann werden auch hier die Spannungen in den unterschiedlichen Sektionen von Controller und FLASH wegkippen und damit durchaus auch wichtige Bytes des logistischen Teiles des Flashes zerlegen, die der Controller für seine Funktionalität benötigt. Damit ist die Karte dann tot. Womöglich gibt es Tools, die die Hersteller auch in der Produktion verwenden, die diese Sektionen wieder herstellen können. Ich vermute aber, dass man an diese Tools nicht so einfach heran kommt. Gruß, Ulrich
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.