Hi,
in meinem uC Projekt verwende ich einen USB Stick mit FAT32.
Ich schreibe ein paar Logs und Tabellen, aber auch einen langsamen
Datenlogger, der bis auf 1s Abtastrate eingestellt werden kann. Die
ganze
Geschichte ist weder von der Datenmenge noch Geschwindigkeit sonderlich
speziell.
Das System wird einfach über einen Hauptschalter mitten im Betrieb
ausgeschaltet, wenn es nicht mehr gebraucht wird.
Jetzt kam immer mal wieder vor, dass entweder Dateien oder das ganze
Dateisystem korrupt war und ich den Stick am PC nicht mehr nutzen konnte
ohne zu formatieren.
ich habe nun ein Testprogramm geschrieben und ein Relais in die USB
Datenleitungen eingeschleift. Damit unterbreche ich beim Schreibvorgang
die Verbindung zum Stick um genau "Datenverlust" zu provozieren. Klappt
nicht.
Daher frage ich mich, ob ich das richtig mache.
file open()
loop:
file write()
file flush()
Bei flush versuche ich "zeitgleich" über das Relais den Stick zu
trennen.
Ist das die richtige zeitliche Stelle?
Bei file write() wird ja nur in den Buffer geschrieben und wenn dieser
voll ist wohl geflusht.
Ich bin dankbar über antworten:
1. Mache ich das richtig?
2. wie verhindere ich eine Datei(system)korruption?
3. Was muss gerade auf dem Dateisystem ablaufen, dass es zur Korruption
kommt?
Wäre wirklich toll, wenn ihr mir den Einstieg erleichtert. Dateisysteme
und USB Sticks sind mir im embedded Bereich zwar nicht neu, aber tief
bin ich nie eingestiegen.
---
IDE: e²studio
LIB: Reneas Synergy FileX aus dem SSP 2.2.0
HW: S5D9
---
Wie fahre ich so einen Schreibvorgang richtig herunter bei power loss?
kann ich das über interne Funktionen lösen, ohne Außenbeschaltung?
:
Bearbeitet durch User
Flöte schrieb: > Bei file write() wird ja nur in den Buffer geschrieben Kommt drauf an, wie das in Deinem µC-Projekt umgesetzt wird. Die USB- und die Dateisystemlibrary hast Du offenkundig nicht selbst geschrieben, welche verwendest Du also?
IDE: e²studio LIB: Reneas Synergy FileX aus dem SSP 2.2.0 HW: S5D9 Habs oben rein editiert.
:
Bearbeitet durch User
Flöte schrieb: > file open() Machst du die Datei auch jedesmal wieder zu, oder läst du die immer offen? Hast du brownout vernünftig eingestellt? Die Hast du wenigstens in der zugehörigen ISR drin das die Datei geschlossen wird. Reicht dein Puffer-Elko damit noch genug Zeit bleibt alle offenen Transaktionen abzuschließen?
> 1. Mache ich das richtig? Ja. Wahrscheinlich glichst du zum falschen Zeitpunkt und kannst es deswegen bisher nicht reproduzieren. > 2. wie verhindere ich eine Datei(system)korruption? Entweder genug (elektrischen) Puffer vorsehen, dass immer alles konsistent geschrieben wird (dazu zählt dann auch die Datei wieder zu schließen und das Dateisystem und das Gerät zu flushen). Oder eines Dateisystem mit Journaling verwenden (und das Journaling auch wirklich verwenden, nicht nur ein Dateisystem benutzen, dass es ∗könnte∗ wenn man wollte). Und am Besten beides zusammen. > 3. Was muss gerade auf dem Dateisystem ablaufen, dass es zur Korruption > kommt? Eine Aktion, die bei Unterbrechung zu einem inkonistenten Zustand führt. Schreiben ist häufig so eine :-)
Flöte schrieb: > Das System wird einfach über einen Hauptschalter mitten im Betrieb > ausgeschaltet, wenn es nicht mehr gebraucht wird. > > Jetzt kam immer mal wieder vor, dass entweder Dateien oder das ganze > Dateisystem korrupt war und ich den Stick am PC nicht mehr nutzen konnte > ohne zu formatieren. Genau. Dein Problem ist, dass Du "Manged Flash" benutzt. Mananged Flash hat neben dem eigentlichen Flash-Speicher noch einen uC mit eigener Software und eigenem RAM. Der Controller kann im Hintergrund Blöcke verschieben (fürs Wear Leveling) und sonstige Dinge machen, die Du nicht mitbekommst und auch nicht beeinflussen kannst. Wenn Du auf Managed Flash irgendwas schreibst, dann landet das noch lange nicht im Flash, sondern erstmal im RAM des Controllers und wird irgendwann mal weggeschrieben, wenn der interne Controller meint, dass es jetzt Zeit wäre. Du weißt auch nicht, in welchen Teil des Flashes Deine Daten landen - das weiß nur der Controller. Wenn da auf einmal der Strom weg ist, ist das eben doof. Zu Managed Flash gehören USB-Sticks, SD-Karten, EMMC und SSDs. Die andere Art von Flash ist Raw Flash, also rohes Flash, wo Du die Flash-Chips selber verwaltest und direkt ohne Controller ansteuerst. Dieses Flash gibts entweder mit SPI oder mit parallelem Interface. Da gibts keinen Controller, der irgendwas im Hintergrund macht, kein verstecktes RAM (außer vielleicht einem Spaltenpuffer), nichts. Wenn Du da einen Block schreibst und das Flash Vollzug meldet, dann sind die Daten tatsächlich sicher. Rohes Flash ist deterministisch, Managed Flash nicht. Wenn Du also eine robuste Lösung willst, nimmst Du rohes, unmanaged Flash. Wenn Du managed Flash verwenden willst oder musst, dann musst Du eben verhindern, dass der Strom einfach so plötzlich weg ist. Das darf dann nicht sein - wie auch immer Du das anstellst. Bei einem Power Loss musst Du dann alle Puffer wegschreiben und den USB-Stick auswerfen (was den internen Controller dazu veranlasst, seine internen Puffer wegzuschreiben und sich herunterzufahren). Dafür musst Du irgendwie die benötigte Energie vorhalten, üblicherweise in einer Kondensatorbank. fchk
ja, das file close habe ich vergessen, sorry. file create() loop: file open() file write() file flush() file close() Und dabei versuche ich im passenden Moment die USB Leitung zu trennen. Was hilft mir hier der WDT? Nur dass keine zufälligen Daten geschrieben werden oder auch, dass der (HW?) Prozess schnell abgeschlossen wird?
:
Bearbeitet durch User
Frank K. schrieb: > USB-Stick auswerfen Danke für Deinen Text. Wie werfe ich einen USB Stick denn aus? Ich kann dazu nichts finden.
Flöte schrieb: > Frank K. schrieb: >> USB-Stick auswerfen > > Danke für Deinen Text. > Wie werfe ich einen USB Stick denn aus? Ich kann dazu nichts finden. - SCSI SYNC-CACHE senden (oder das Äquivalent im MSD) - SCSI STOP senden (oder das Äquivalent im MSD) - USB suspend Das müsste es sein. Ich kenne jetzt Deinen USB-Stack nicht, die Implementationsdetails musst Du selber rausfinden. fchk
Korruption in Dateisystemen kannte ich noch nicht. Werden die Verantwortlichen nun vom Journal zur Rechenschaft gezogen?
Flöte schrieb: > Ist das die richtige zeitliche Stelle? Eher nicht. Die empfindliche stelle ist meistens das fclose() weil da der Verszeichniseintrag mit der Dateigröße aktualisiert wird. Außerdem wird oft auch erst da die FAT aktualisiert - falls der Dateisystem Code einen FAT Puffer hat. Relais braucht ein paar ms um abzufallen, das kann u.U. zu lagsam sein. Ich würde hier eher das Bedienkonzept überdenken - der Schalter ist entweder virtuell (also nur an µC Ports die einfach ausgelesen werden) oder nur ein Taster. Falls man den Hauptschalter beibehalten möchte, bräuchte man ziemlich dicke Elko in der Schaltung die ein paar Sekunden Schreiblast puffern können. Dann kann der µC auf die Abschaltung der Versorgung noch reagieren.
Ich habe die Erfahrung gemacht, dass Flash Speicher manchmal ihren Inhalt verlieren, wenn beim Zugriff (auch read-only) die Stromversorgung instabil ist. Kontrolliere das.
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.