Hallo, Ich bin gerade dabei mich mit MMC und SD-Karten zu beschäftigen. Die Initialisierung, das Auslesen des CID- und des CSD-Regsisters, sowie das Lesen und Schreiben von Blöcken funktioniert. Beim letzteren, also beim Lesen und Schreiben, stimmen die Adressen noch nicht ganz. Bisher bin ich davon ausgegangen, dass bei den MMC/SDC's die Adresse byteweise angegeben wird. Also des erste Byte hat die Adresse 0x00, das zwölfte 0x0b und das 100. 0x63. Da in einem Filesystem wie Fat16 die Adresse sektorweise angegeben wird hab ich mit gedacht, dass ich die Sektoradresse mit 512 multiplizieren muss um die "richtige" Adresse in der MMC/SDC bekomme!? Dem Anschein nach aber stimmt dies nicht so. Ich lasse z.B.: Daten in den Sektor 155(0x13600)schreiben. Mittels WinHex kann ich die Daten aber im Block 54 (0x6C00) finden. Noch komischer finde ich dass ich beim selben Befehl die Daten auf einer MMC ab der Adresse (0x6F00) finde!? Nutzen den MMC und SDC unterschiedliche Adressaufteilungen? Ich habe dazu beide Datenblätter studiert, konnte aber keine Angabe über Adressen, sowie die Codierung der Adressen im Argument des Commands finden. Außerdem zeigt sich nur bei der MMC, dass wenn ich die CID (oder CSD) auslese und danach sofort einen Sektor lese oder schreibe ein Fehler auftritt. Wenn ich diese Register nicht auslese geht es ohne Probleme. Muss ich demnach eine "Pause" zwischen Befehlen einbauen? Danke Hias
Vielleicht solltest du mal deinen Code zum Lesen zeigen, zumindest wäre mir kein Problem mit den Adressen bekannt. Wie's bei den MMCs ist kann ich aber nicht sagen, davon habe ich keine. Allerdings kenne ich das Problem mit dem Lesen nach CID/CSD. Weiss aber nicht, was man dagegen tun kann. Als ich das mal bemerkt hatte, hab' ich mir dann glaub' mit irgendeinem Dummy-Befehl dazwischen geholfen. Ist ja egal was, sollte einfach möglichst wenig zurückliefern.
Hi, ich selbst habe zwar noch keine MMC/SD lib geschrieben, aber habe mal kurz diejenige die ich benutze(Beitrag "MMC/SD Karte: mmc_lib Version 2.0") mit deiner verglichen. uint8_t cmd[] = {0x51, 0x00, 0x00, 0x00, 0x00, 0xff}; ^^ Bei dir ist das Sechste Befehlsbyte, um einen Sektor zu lesen 0xff, bei Stefan Seegel's Version ist es 0x95. Allerdings kann ich nicht erklären, was und ob dieses letze Byte überhaupt Auswirkungen darauf hat, wohin der Sektor im Flash auf der Karte geschrieben wird, aber vielleicht hilft es dir dennoch. Ciao, Nik
Danke für den Hinweis. Hab im nochmal im Datenblatt nachgelesen. Das letzte Byte ist lediglich eine Checksumme (CRC7). Im SPI Modus ist die Kontrolle der Checksumme deaktiviert (Nur bei CMD0 braucht man sie). Von dem her ist egal was im letzten Byte steht, Hauptsache das letzte Bit ist Eins. Außerdem würde ich als Response einen CRC Error bekommen, falls eine Checksumme berücksichtigt werden sollte. Hias
Hab gerade noch etwas bemerkt: Stefan Seegel verwendet in seiner lib andere CMD's um blocks zu lesen/schreiben. lesen : 0x40 + 0x17 => 0x57 und zum blockschreiben 0x40+0x24 => 0x64. Aber ansonsten fällt mir gerade nichts mehr auf was anders aussieht.. Nik
Hi! Vorsicht, die CMD's sind dezimal, das Übertragungsbit($40) hex. CMD 17(Block lesen) ist also $40+17= $51 CMD 24(Block schreiben) = $40 + 24 = $58 Fehler bei CSD lesen: hängst du auch immer schön ein Dummy an die letzte Übertragung(8 Takte), wenn nein, mache mal. Viel Erfolg, Uwe
@Uwe Das mit den Dummy Bytes war wahrscheinlich die Ursache. Muss allerdings zwei Byte schicken, aber dann funktioniert auch das Sektorschreiben nach dem Auslesen der CID oder CSD. Vielen Dank für den Hinweis! @All Das Problem mit den Adressen bleibt leider noch. Wie ist der Speicher in der MMC bzw. SDC adressiert? Hias
HI, ich kann mal nachschauen wie ich es bei meiner MMC (SPI) mal gemacht habe. War bissl selsam mit der Adressierung aber bei mir hats dann geklappt. Ich poste es mal hier demnächst. Marc989
Danke! Wär a tolle Sache! Was mich verwundert ist, das Ich selben Input bei den beiden Karten (gleicher Befehl), verschiedene Outputs bekomme (andere Adressen im Speicher) Hias
Hi! 2 Fragen: Ist/sind die Karte(n) Formatiert? Schreibst du in eine Datei, oder einfach so in die Sektoren? Winhex kann, wenn ich mich recht entsinne, nicht alle Sektoren anzeigen (erst >32?). Wenn ich jedenfalls mit Fat16 arbeite finde ich alle Adressen und Sektoren an der Stelle wo sie hingehören. Nicht das dich Winhex austrixt. Viel Erfolg, Uwe
Danke UWE! Ich habe beide Karten mit Fat16 (allerdings unter Windows) formatiert. Ich lasse in den Sektor 155 schreiben. Um die Adresse zu ermitteln schiebe ich die 155 um 9 Stellen nach links. Damit bekomme ich 0x13600.(155*512). Aus diesem Wert berechne ich mittels eine AND-Operation sowie einer Verschiebung um x Stellen die Command-Sequenz. Die sieht dann folgendermaßen aus: 0x58,0x00,0x01,0x36,0x00,0xff Ich erwarte nun das ich in WinHex die Dateien unter einem Offset von 0x13600 finde. Leider tue ich das nicht, sondern die Daten befinden sich bei 0x6c00 (SD) und 0xF600 (MMC) Hias P.S.: Grade Nochmal getestet: Beide mit Fat16 formatiert und mit obengenannten Befehl beschrieben. Leider das selber Ergebnis.
Haha! Ich hab eine Kleinigkeit gefunden. Die Daten werden an der richtigen Stelle abgespeichert! Man unterscheidet nämlich zwischen physikalischer und logischen Sektor-Nr. Die Adresse in die ich schreibe ist immer die physikalische Sektor Nummer. Die logische Adresse stimmt nicht mit der physikalischen überein, und ist wohl von Karte zu Karte unterschiedlich: meine MMC hat log (132) phy (155) und die SDC log (54) phy (155). Woher kann ich diese Abweichung beziehen. Die steht bestimmt irgendwo im FAT, oder in der Card selber? Bingo-> steht im Boot Sector und nennt sich HiddenSectors :) Die Frage ist nur noch wie lese ich den Bootsector aus, ohne dass ich die HiddenSectors-Größe kenne? Hias
Hi! Also die Adressen gehen alle in Sektoren auf. $6C00 = Sektor 54 $F600 = Sektor 123. Das spricht für unterschiedlichen Offset oder sowas. Du musst jetzt nur mal rausbekommen an welchem Sektor dein Datenbereich beginnt. Ich vermute mal das das für die beiden Karten unterschiedlich ist(Grösse,def.Sektoren?), ganz erklären kann ich es aber noch nicht, da müsste man MBR+PBR+Vat) sehen. Aus den dort abgelegten Daten lassen sich die Bereiche berechnen. Wenn du jetzt in absolute Sektoren schreibst werden die in Winhex natürlich auch an anderer Stelle gefunden. Mal was anderes, hast du dir mal Root angesehen? Sind bei dir auch Dateieinträge in Unicode drinn? Damit kämpfe ich momentan. Die Fat16/32 Beschreibung behandelt das Thema nur als lange Dateinahmen, es sind aber keine, weil die Einträge sind nur 32 Byte lang. Ich weiss jedenfalls nicht so richtig wie ich damit umgehen muss. Hast du da irgendwelche Unterlagen drüber? Viel Erfolg, Uwe
>>Die Frage ist nur noch wie lese ich den Bootsector aus, ohne dass ich >>die HiddenSectors-Größe kenne? Es gibt zwei Möglichkeiten einer Formatierung: FAT mit MBR (Master Boot Record) und FAT ohne MBR, nur mit Bootsector (Volume ID) Im physikalischen Sector 0 der Karte befindet sich entweder ein MBR oder ein Boot Sector. Im MBR stehen die Einträge für die jeweiligen Partitionen, für jede Partition gibt es einen Eintrag, der angibt, wo die jeweilige Partition beginnt, also welches der 1. physikalische Sector der Partition ist -> der Boot Sector. Im Boot Sector steht dann drin, wieviele Reserved Sectors usw. es gibt, damit läst sich alles weitere berechnen. Wenn es keinen MBR gibt, gibt es demzufolge nur eine Partition und die beginnt dann im physikalischen Sector 0 der Karte. Im Anhang eine Datei, die ich mir zusammengeschrieben habe, als ich gelernt habe mit FAT umzugehen und meinen eigenen C Code dafür zuschreiben. Sehr hilfreich: http://www.pjrc.com/tech/8051/ide/fat32.html @ Uwe Kannst du mal einen hex dump posten, mit so einem Eintrag.
Hi! Muss ich jetzt unbedingt meinen Schlepptop hochfahren oder findest du es auch selbst in der Fat16/32 Beschreibung? Auf jedenfall geht es im phys. Sektor 0 los(Adr.???) Da steht der Offset(in Sektoren) bis PBR. Den musst du zerlegen und bekommst alle relevanten Daten. Übrigens x 512 = x 2 und hinten 2 Nullen drann: Offset $27(Sektoren)x2 = $4E + 00 = $4E00 (Das letzte Adressbyte ist also immer 00) Vereinfacht das Rechnen. Viel Erfolg, Uwe
Hi! jetzt habe ich doch tatsache den Schleptop noch aktiviert und hänge mal die Root.log mit an. Lässt dich allerdings nur mit einem Hexeditor richtig lesen. Es sind eigentlich nur 3 Dateien drauf. test.txt, lösch.txt und test1.txt. Die Lösch.txt ist mit test.txt identisch nur eben gelöscht um die Auswirkungen in Root & Fat zu beurteilen. Wenn mir jemand wirklich die Unicodeinträge erklären könnte wäre, ich echt froh. Übrigens das ist alles unter WinXP erstellt worden. MFG Uwe
Das mit UNICODE sind LFN Einträge, die nur aus einer Sequence bestehen, also ein 32 Byte Feld. >>Es sind eigentlich nur 3 Dateien drauf. test.txt, >>lösch.txt und test1.txt. Das ist nicht ganz richtig, die Dateien heissen: Test.txt Lösch.txt Test1.txt Warum du zu jedem SFN auch einen LFN hast ist einfach zu erklären: Du benutzt Groß- und Kleinschreibung im Dateinamen, das entspricht nicht der SFN Vorgabe, also wird ein LFN mit angelegt, auch wenn der Dateiname kürzer als 8+3 Zeichen ist. Benutze nur Kleinbuchstaben im Namen und max. 8+3 Zeichen und du wirst sehen, das du auch nur SFN Einträge hast.
Danke Michael für deine Erklärung, verstehe ich auch erstmal. Kann man das irgendwo nachlesen? (ich kann momentan mit SFN/LFN noch sehr wenig anfangen) besten Dank, Uwe
jetzt fällts mir wie Schuppen von den Augen LFN = Long File Name? Wenn ja stehts bei Fat16/32. MFG Uwe
Angehängte Dateien:
-
Bootsector.png
36 KB
Michael Wolf wrote: > Im physikalischen Sector 0 der Karte befindet sich entweder ein MBR oder > ein Boot Sector. > > Wenn es keinen MBR gibt, gibt es demzufolge nur eine Partition und die > beginnt dann im physikalischen Sector 0 der Karte. > Hallo zusammen. Ich bin grad ein wenig verwirrt. Bei mir steht auf beiden Karten der Bootsector nicht in dem phy. 0-Sektor sondern mit einem Offset versehen. Somit kann ich ja quasi gar keinen Offset ermitteln (Hidden Sectors). Oder kann es sein, dass in der physikalischen Adresse auch nochmal ein Bootsector eingetragen ist? Meine Karte sagt allerdings das Gegenteil. Möglich aber das da auch ein Fehler ist... Im Anhang findet ihr ein Abbild von Winhex und dem Bootsector. Was sagt ihr dazu? Hias
Hi! Das ist nicht Sektor0 deiner Karte sondern der PBR an Sektor??(steht in Sektor0) schaue dir bitte "FAT32_Know-How.txt " von oben an, da steht alles drinn. MFG Uwe
du hast ja sogar einen Pfeil auf den physikalischen Sektor gemacht. Ist dir dabei kein komisches Gefühl gekommen wie "bin ich überhaupt in Sektor0" ? Kenne mich mit Winhex nicht wirklich aus, aber evetuell ist irgendwo ein Häkchen versteckt wie "lese physikalischen Sektor" oder so. Viel Erfolg, Uwe
@ Hias Du öffnest in Winhex die Karte als logisches Laufwerk, demzufolge ist Sector 0 hier der Bootsektor, also der logische Sector 0 der gewählten Partition. Öffne das Laufwerk als Physikalisches Laufwerk und du wirst sehen, das Sector 0 auch der physikalische Sector ist, und im dem befindet sich dann der MBR und die Angabe wo deine Partition beginnt. Du kannst dann auch die Informationen der Partition anzeigen lassen, bzw. diese öffnen. Am wichtigsten ist es hier der Unterschied zwischen physikalischen und logischem Sector. Die Karte selbst wird mit den SPI Commands immer mit physikalischen Sectoren (Addressen) angesprochen! Das Filesystem, also FAT arbeitet dagegen mit logischen Sectoren!
Hallo! Vielen Dank für die Hinweise. Gibt es den einen Hex_Editor der mir meine Karte als physikalisches Laufwerk anzeigt. Ich habe schon 5 durchgetestet und finde bei keinem diese Option... Hias
In Winhex geht das doch. Drücke F9 um die Disk Auswahl anzuzeigen. Bei mir gibt es dann zwei Tree's: Logical Drives und Physical Media Bei Logical Drives kannst du die Laufwerke nach Buchstabe auswählen und als logisches Laufwerk öffnen. Bei Physical Media werden die Datenträger direkt geöffnet, als als Festplatte, CDROM oder SD Karte. Aber auch HexWorkshop bietet die Möglichkeit physikalische und logische Laufwerke zu öffnen. Da über STRG-D
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.