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.
> 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
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!!
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
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.
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
