Wie groß ist eigentlich der interne RAM einer SD-Karte? Also wenn ich Daten auf die SD-Karte abspeichern will, muß der Controller diese Daten ja irgendwie erstmal zwischenspeichern und dann auf der Karte verteilen. Hintergrund: Habe einen Datenrekorder gebaut, µC schreibt eine Textdatei auf die SD-Karte. Es wurden schon ein paar wenige kB an die Karte geschickt, diese wurden offensichtlich aber noch nicht physikalisch in den Flash geschrieben (habe mir im Anschluß ein Image der SD-Karte gezogen und mit dem Hex-Editor angeschaut). Jedenfalls habe ich keine zusammenhängenden 5 Byte gefunden, die hätten aufgezeichnet sein müssen. Ich würde jetzt nicht erwarten, daß der Controller die Daten derart zerstückelt (eher clusterweise?). Da gibt es ja diesen fflush-Befehl, diesen habe ich noch nicht ausgeführt. Der µC ist mir leider abgeschmiert und ich konnte die Datei nicht schließen. Deswegen frage ich mich, wann ist der interne RAM einer SD-Karte voll und wann sich deswegen die Karte genötigt sieht, die Daten in den Flash abzulegen, auch wenn die Datei noch nicht geschlossen wird? Können überhaupt z.B. 100 MB am Stück reingeschrieben werden ohne den "fflush-Befehl", oder verweigert die Karte dann die Annahme von Daten, weil ihr Cache voll ist?
F. P. schrieb: > Da gibt es ja diesen fflush-Befehl, diesen habe ich noch nicht > ausgeführt. Der µC ist mir leider abgeschmiert und ich konnte die Datei > nicht schließen. Dan pack die Karte in einen PC und lass sie "prüfen" und reparieren. Danach stimmt zwar die Größe nicht 100%ig, aber die geschriebenen Daten sind drin. Je nach FAT-Implementation könnten aber signifikant Daten noch gar nicht weggeschrieben worden sein. Was Du da an Software verwendetst hast Du uns leider nicht verraten. SD Karten haben nach dem Schreiben ein "Busy", aber wenn der Zustand vorbei ist darf man den Strom komplett wegnehmen, ohne Daten zu verlieren.
Jim M. schrieb: > Dan pack die Karte in einen PC und lass sie "prüfen" und reparieren. > Danach stimmt zwar die Größe nicht 100%ig, aber die geschriebenen Daten > sind drin. Wie gesagt: Die Daten sind definitiv noch nicht physikalisch im Flash gelandet, sondern müssen irgendwie noch im RAM/Cache der SD-Karte geblieben sein (bis zum Stromausfall).
F. P. schrieb: > Da gibt es ja diesen fflush-Befehl, diesen habe ich noch nicht > ausgeführt. Der schickt lediglich alle Daten vom Puffer des Treibers an die Karte. SD-Karten kennen keinen Befehl der den RAM leert. Allerdings garantiert die Spezifikationen, dass nach Abschluss eines Schreib Befehls die Daten "sicher" sind. Somit muss der Absturz während des Schreibens erfolgt sein, oder bevor der Treiber überhaupt angefangen hat den Puffer zu leeren.
Der µC hat lediglich 512 Byte Puffer und hat diesen mehrfach mit unterschiedlichem Inhalt zur Karte geschickt (Schreibbefehl), insgesamt waren es ein paar kB an Daten. Da nahm ich an, daß die Karte diese Daten auch auf den Flash geschrieben hat, aber offenbar hat sie einen Cache (wie eine Festplatte) und schreibt die Daten erst endgültig in den Flash, wenn der Befehl zum Schließen der Datei eingeht oder wenn ihr eigener Cache voll ist. Jedenfalls konnte ich im Image nicht die neuen vermeintlich geschriebenen Daten finden, der mutmaßliche Cache der SD-Karte war wohl noch nicht voll.
> Da nahm ich an, daß die Karte diese Daten auch auf den Flash geschrieben > hat, aber offenbar hat sie einen Cache (wie eine Festplatte) und schreibt > die Daten erst endgültig in den Flash, wenn der Befehl zum Schließen der > Datei eingeht oder wenn ihr eigener Cache voll ist. Nein. > Jedenfalls konnte ich im Image nicht die neuen vermeintlich geschriebenen > Daten finden, der mutmaßliche Cache der SD-Karte war wohl noch nicht voll. Nein. Such mal eher in die Richtung 'µC ist abgeschmiert, hat er davor(!) überhaupt das getan, was er tun soll?' (i.e. korrekten Puffer korrekt befüllen und korrekt mit den korrekten Kommandos an die korrekte SD-Karte an die korrekte Stelle übertragen, oder so ähnlich).
Wenn man Daten in Flash-Medien mit Filesystem schreibt, dann sind das mindestens 2 Stufen: - Die Daten selbst werden geschrieben. - Die Metadaten der Flash-Verwaltung werden angepasst. Es kann also sein, dass die Daten bereits auf den Flash-Chips sind, aber die Metadaten noch auf dem alten Stand sind. Deshalb ist die Cache-Grösse des Flash-Controllers nicht wirklich relevant.
:
Bearbeitet durch User
Ich hatte mit einem Dataflash ein ähnliches Problem. Da das Dataflash seitenweise geschrieben wird, also erst wenn die laufende Seite voll ist, waren im Problemfall etliche Daten weg. Weshalb ich noch ein FRAM hinzu fügte, in dem die letzten Daten ebenfalls enthalten sind. Da ein FRAM praktisch verzögerungsfrei schreibt, ist dessen Inhalt stets aktuell.
Ich kenne das von SD-Karten. Ich verwende FATFS, muss ich dazu sagen. Aber wenn man mehrere kByte auf die SD schreibt, ohne das File expliziet zu schließen, sind viele Daten dann weg. Irgenwo wird also zwischengespeichert. Wenn man sicher für einen Stromausfall sein will, muss man nach dem Ausfall der Versorgung mehrere hundert ms haben, um alle Files schließen zu können. Das ist nicht immer einfach umzusetzen, und einer der größten Nachteile einer SD-Karte (auch wenn viele das nicht wahrhaben wollen). wie man das löst, wenn man direkt auf die Karte schreibt, weiß ich auch nicht.
g457 schrieb: > Nein. Such mal eher in die Richtung 'µC ist abgeschmiert, hat er > davor(!) überhaupt das getan, was er tun soll?' (i.e. korrekten Puffer > korrekt befüllen und korrekt mit den korrekten Kommandos an die korrekte > SD-Karte an die korrekte Stelle übertragen, oder so ähnlich). Ja, wenn ich ganz normal die Datei schließe, sind die Daten korrekt geschrieben. Aber angenommen, ich würde 100 MB auf die Karte schreiben (und warten, bis die Karte nicht mehr "busy" ist), ohne die Datei danach zu schließen, dann müssen doch die Daten physikalisch im Flash gelandet sein. Die FAT ist natürlich noch nicht aktualisiert, aber wenn ich den Saft wegnehme und anschließend den Flash byteweise auslese (Image erstellen), müßte ich meine Daten irgendwo wiederfinden (je nachdem, wo der SD-Kartencontroller die Daten im Flash verteilt hat).
F. P. schrieb: > Aber angenommen, ich würde 100 MB auf die Karte schreiben (und warten, > bis die Karte nicht mehr "busy" ist), ohne die Datei danach zu > schließen, Die Frage ist, ob der Treiber die 100MB auch abschickt wenn du kein fclose () aufrufst. Vermutlich nicht. Nochmal: Die Karte hat keinen Puffer , der nach einem abgeschlossenen Schreib Befehl an die Karte noch Daten enthält. Der Puffer ist im Treiber.
fclose() reicht übrigens ggf. auch nicht, das Dateisystem muss auch unmounted werden (Windows: auswerfen, Linux: umount, FatFs: f_umount), damit der Treiber wirklich alles an die Karte schickt.
F. P. schrieb: > müßte ich meine Daten irgendwo wiederfinden In den Flash-Chips findest du sie vielleicht wieder, aber nicht notwendigerweise auch alle über das µSD Interface. Erst wenn die Metadaten der Flash-Verwaltung ebenfalls aktualisiert wurden - was die letzte Aktivität ist - sind auch alle Informationen persistent gespeichert.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Nochmal: Die Karte hat /keinen/ > Puffer , der nach einem abgeschlossenen Schreib Befehl an die Karte noch > Daten enthält. Das ist richtig, besonders wichtig ist dabei das "abgeschlossen". Denn Puffer-RAM besitzt die Karte sehr wohl, zwingend mindestens in der Größe der kleinsten schreibbaren Einheit des verbauten Flash, üblicherweise aber wohl eher das Doppelte bis Vierfache davon. Aber wie du richtig schreibst: wenn nach dem Schreibbefehl nicht mehr busy zurückkommt, dann hat der Inhalt sämtlicher dieser Puffer im Flash gelandet zu sein. Wird aber vorher die Versorgung geklaut, ist natürlich nur ein Teil der Daten aus dem Puffer der Karte in den Flash geschrieben worden. Und man muss diesen Teil nicht einmal dann sehen können, wenn man ein Image zieht. Es ist vor allem bei bereits zuvor mehrfach "vollgeschrieben" Karten sogar recht wahrscheinlich, dass man den Teil nicht sieht, weil er im aktuellen Spare gelandet ist und das wear leveling den noch nicht umgemapped hat. Dann taucht er im Image nicht auf. Er ist aber im Flash, wenn man diesen "roh" ausliest, unter Umgehung des Controllers, bekommt man ihn auch zu sehen.
OK, läßt sich der Controller für das "rohe" auslesen softwaremäßig umgehen, gibt es da Spezialprogramme?
F. P. schrieb: > OK, läßt sich der Controller für das "rohe" auslesen softwaremäßig > umgehen, gibt es da Spezialprogramme? Ja, vom Hersteller des Controllers. Dem muss man ja auch mitteilen wieviel Flash wo angeschlossen ist, man muss ihn dazu bringen, einen bad block scan auszuführen und im letztendlich auch noch sagen, mit welchem Namen und welcher User-Kapazität er sich am Bus melden soll. Diese Tools unterliegen einem NDA (genau wie die Beschreibung der Algorithmen des Controllers). Ab und zu diffundiert trotzdem mal was raus, da dürfte dann Google Dein Freund sein. https://www.bunniestudios.com/blog/?p=3554
OK, so weit will ich es nun doch nicht treiben. :) So wichtig waren die Daten nicht, aber man hat wieder etwas dazugelernt.
soul e. schrieb: > Ja, vom Hersteller des Controllers Quelle? Ich lese dies hier fortlaufen, aber bei den Herstellern findet man diese Tools nicht! Setze mal bitte einen Link!
Marc H. schrieb: > Ich lese dies hier fortlaufen, aber bei den Herstellern findet man diese > Tools nicht! Schon mal höflich angefragt? Wenn die nur per NDA verfügbar sind, dann werden sie kaum offen zum Download rumliegen.
:
Bearbeitet durch User
bunnie wurde oben doch schon verlinkt. xobs gäbs da auch noch. Und einen Vortrag mit der Nummer 5294 auf dem ccc. Viel Spaß beim Staunen!
A. K. schrieb: > Marc H. schrieb: >> Ich lese dies hier fortlaufen, aber bei den Herstellern findet man diese >> Tools nicht! > > Schon mal höflich angefragt? Wenn die nur per NDA verfügbar sind, dann > werden sie kaum offen zum Download rumliegen. Ist dein Wissen verlässlich, oder nur Vermutung?
Marc H. schrieb: > Ist dein Wissen verlässlich, oder nur Vermutung? Der Lieferant handelt mit Eurem Einkauf und Eurer Rechtsabteilung eine Geheimhaltungsvereinbarung (NDA) aus. Wenn die unterschrieben ist, bekommst Du die für Dein Projekt notwendigen Unterlagen. Üblicherweise ganz oldschool auf einer DVD, nicht zum runterladen. Wenn Du Glück hast lädt mal jemand was bei Wikileaks hoch. Es kann aber auch sein, dass den Leuten an ihrem Job und ihrem Eigenheim (die Höhe der Vertragsstrafe liegt darüber) gelegen ist und sie sich an ihre Verträge halten.
soul e. schrieb: > Wenn Du Glück hast lädt mal jemand was bei Wikileaks hoch. Das passt dann aber üblicherweise nicht zu aktuell erhältlichen Karten. Da ändert sich auch der Controller bzw. dessen Software öfters mal. soul e. schrieb: > Der Lieferant handelt mit Eurem Einkauf und Eurer Rechtsabteilung eine > Geheimhaltungsvereinbarung (NDA) aus. Das machen die üblicherweise aber nur wenn damit ein Auftrag mit >10k oder 100k Karten rauskommt. Und die Infos für Karte A nutzen Dir für Karte B wenig.
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.