Hallo zusammen, ich will die Daten einer SD-Karte auslesen. Dazu habe ich die Karte im SPI-Modus initialisiert (CMD0 während CS=0), danach ACMD41 und CMD16 (SET_BLOCKLEN). Hier bekomme ich auch die korrekten Responses. Wenn ich jetzt Daten auslesen möchte (von Adresse 0) mit CMD17 (READ_SINGLE_BLOCK), dann empfange ich als Repsonse 0x00 und dann das Token 0xFE, danach kommen aber nur mehr 0x00. (Dort müssten aber andere Daten stehen) Wenn ich Daten von Adresse 1 auslesen möchte, empfange ich als Response 0x20, was ja ok ist, weil lesen von Adresse 1 nicht erlaubt ist (sondern nur von Vielfachen von 512) Wenn ich diverse Register auslese, dann funktioniert es und es kommen Daten daher. Ich versorge die Karte mit 3V, sollte aber kein Problem darstellen, weil sie für den Bereich von 2,7-3,6V spezifiziert ist. Ich habe auch schon an allen Datenleitungen Pull-ups und am CLK einen Pull-down. Habe auch schon versucht sie wegzulassen bzw andere Werte probiert (47k und 100k). Ich habe schon gelesen, dass andere Leute auch das Problem hatten, aber es gab dann keine Lösung dafür. Ich bin für jeden Lösungsansatz dankbar. Schöne Grüße Christian
Christian Swoboda schrieb: > Wenn ich jetzt Daten auslesen möchte (von Adresse 0) mit CMD17 > (READ_SINGLE_BLOCK), dann empfange ich als Repsonse 0x00 und dann das > Token 0xFE, danach kommen aber nur mehr 0x00. Auch am Ende des 512 Byte Blocks, wo die Partitionstabelle steht? Unter Windoof ist es schwerer, den echten Sektor 0 statt des Sektor 0 der ersten Partition zu lesen. Benutze mal die Suchfunktion, das hatten wir hier schon mal. Ach ja: Ich gehe davon aus, das es eine SD-Karte (<=2GB) und keine SDHC ist, letztere braucht eine andere Initialisierung.
Gast
#3848920
Woher wissen Sie, dass im Block 0 nicht tatsächlich nur Nullen stehen? Wozu nutzen Sie CMD16? Vorschlag: erstmal 1/10 der Karte durchlesen, und wenn dann immer noch nur Nullen kommen, nochmal über die Bücher gehen, pardon, die Dokumentation lesen.
Hallo Jim Danke für die rasche Antwort. Ja vollkommen richtig, es ist eine 1GB-Karte. Ich habe einen Screenshot von WinHex angehängt. Lese ich mit dem Befehl (0x51,0x00,0x00,0x00,0x00,0x01) nicht die Daten von Offset 0000000000? (0xEB,0x3C,0x90,...)
Angehängte Dateien:
Mit CMD16 stelle ich die Blockgröße auf 512 Byte ein
Gast
#3849084
CMD16 habe ich in all den Jahren nie benutzt; ich würde es herausnehmen, ist bestenfalls eine mögliche Fehlerquelle. Zu WinHex kann ich nichts sagen, sieht aber gut aus. Sie könnten mal versuchen, direkt nach CMD41 mit CMD9 das CSD auszulesen, das jedenfalls mache ich immer in meiner Initialisierungsroutine.
Gast
#3849100
>Wenn ich jetzt Daten auslesen möchte (von Adresse 0) mit CMD17 >(READ_SINGLE_BLOCK), dann empfange ich als Repsonse 0x00 und dann das >Token 0xFE, danach kommen aber nur mehr 0x00. >(Dort müssten aber andere Daten stehen) Vieleicht ist ja deine Ausleseroutine Müll. Oder dein Fehler liegt beim ausgeben der Daten. Können wir ohne kompletten Code alles nicht sehen.
Gast
#3849105
hi, >Lese ich mit dem Befehl (0x51,0x00,0x00,0x00,0x00,0x01) nicht die Daten >von Offset 0000000000? (0xEB,0x3C,0x90,...) nein, du liest mit Winhex den Startsektor einer Partition. mit deinem Progr. Sektor 1 und da stehen meist nur 0-en Im Sektor 0 steht der MBR welcher auf die verschidenen Partitionen verweist. Dazu müstest du deine Karte unter Winhex physisch öffnen. viel Erfolg, Uwe
Ok, anstelle von CMD16 habe ich jetzt CMD9 versucht -> hat keinen Erfolg gebracht. Den Code zu posten wird wahrscheinlich nichts bringen. Ich lese die SD-Karte über ein DLP-2232 Modul von FTDI aus und benutze LabVIEW mit fertigen Bausteinen zum Ansteuern der SPI-Schnittstelle des DLP-Moduls. Allerdings habe ich jetzt gesehen, dass die Daten 0x55 0xAA (Offset 510 und 511) + 2 Byte CRC richtig daherkommen. Würde jetzt mal behaupten, dass das Auslesen soweit korrekt ist. Warum aber von Offset 0 - 509 alles 0x00 ist, ist mir immer noch ein Rätsel.
Gast
#3849115
>Im Sektor 0 steht der MBR welcher auf die verschidenen Partitionen >verweist. Dort kann auch schon ein Bootsektor drin stehen bzw. eine Partition beginnen. Es muss kein MBR sein. Aber selbst wenn dort ein MBR drin steht ist dieser nicht komplett Null. Die letzten beiden Bytes sind z.B. 0x55,0xAA wie im Bootsektor. Wenn im MBR alles Null ist würde Win die Karte als nicht formatiert ansehen.
Gast
#3849122
Sieht normal aus. Erste 512 Byte Bootlader. (Dos-Diskette ?). Danach 00 bis Spur 1. Wo fängt Spur 1 an. (64 x 512 Byte ?). Bei Spur 1 sollten deine Partition anfangen. Partition mit was erstellt. Gieb mal Fdisk Daten an. (Mit Fdisk von Dos 5.0). mfg SchlosserdBtr
Gast
#3849217
>Würde jetzt mal behaupten, dass das Auslesen soweit korrekt ist. Warum >aber von Offset 0 - 509 alles 0x00 ist, ist mir immer noch ein Rätsel. Sind da vieleicht doch noch ein paar Bytes an Offset 0x01BE die nicht Null sind?
SchlosserdBtr schrieb: > Sieht normal aus. Nur, wenn ers der erste Sektor der FAT Partition ist. Ein Sektor 0 einer SD Karte anders aus! > Erste 512 Byte Bootlader. (Dos-Diskette ?). Man lese mal die Doku zu FAT16 durch... > Danach 00 bis Spur 1. Falsch. Offset 0x0E ist 4, also insgesamt 4 reservierte Sektoren bis die eigentliche FAT anfängt. Daher kommen die nachfolgenden Nullen. Ich schrieb oben aus gutem Grund, dass man SD Karten unter Windoof schlecht auslesen kann. Physisches Lesen der Parition ist als LUser möglich, an die Paritionstabelle im echten Sektor 0 kommt man nur als Admin ran. Der Laufwerksbuchstabe bezeichnet ebenfalls nur die Partition! Winhex kann als Admin aber den physischen Datenträger durchaus im Disk-Editor öffnen. Dann sieht man, dass Sektor 0 einer SD Karte aus vielen Nullen besteht, das erste nicht-null Byte kommt bei mir ab 0x1BF.
Gast
#3849504
Sorry, habe dazwischenliegenden Bootmanager vergessen ! Stichwort: BOOTMGR ib der angehängten Datei. Jim Meba schrieb: > Nur, wenn ers der erste Sektor der FAT Partition ist. Ein Sektor 0 > einer SD Karte anders aus! Kommt auf das erstellende Programm an. Jim Meba schrieb: > Man lese mal die Doku zu FAT16 durch... Trift nur bedingt zu, da Bootlader für Bootmanager. Hält er sich an die Spezifikationen? (Unsicher!) Jim Meba schrieb: > Offset 0x0E ist 4, also insgesamt 4 reservierte Sektoren bis die > eigentliche FAT anfängt. Warscheinlich Boormanager, danach freier Bereich oder FAT. Jim Meba schrieb: > Physisches Lesen der Parition ist als LUser > möglich, an die Paritionstabelle im echten Sektor 0 kommt man nur als > Admin ran. Inzwischen leider. Jim Meba schrieb: > Der Laufwerksbuchstabe bezeichnet ebenfalls nur die > Partition! Das ist Richtig. Jim Meba schrieb: > , das erste nicht-null Byte kommt bei mir ab > 0x1BF. Normal 0x1BE ,da noch 4 x 16 Byte + 2 Byte überig sein müssen. 0x000 zählt auch mit! mfg SchlosserdBtr
Hallo
Danke für eure Beiträge.
Also ich habe gesehen, dass das Auslesen über das DLP-Modul doch
funktioniert. Ich bekomme auch dieselben Daten wie im WinHex. Ich habe
auch soweit den FAT-Aufbau verstanden, wie man die Dateinamen und die
Adresse für den Start der Daten usw. findet.
Was mir aber noch unklar ist, die Daten die in WinHex ab Offset 0 stehen
(0xEB,0x3C,0x90,...) lese ich beginnend bei Adresse 0x01E600 aus
(SPI-Befehl an die SD-Karte: 0x51,0x00,0x01,0xE6,0x00,0x01). Danach ist
alles gleich, aber halt immer um diesen Offset 0x01E600 verschoben.
WinHex | DLP-Modul
Bootsektor: 0x000000 | 0x01E600
FAT1: 0x000800 | 0x01EE00
FAT2: 0x01F400 | 0x03DA00
Verz.: 0x03E000 | 0x05C600
Datei 1: 0x042000 | 0x060600
Datei 2: 0x126000 | 0x144600
Kann mir bitte jemand erklären, warum dieser Unterschied zu WinHex
zustande kommt?
Rechnet WinHex eventuell den Offset einfach weg?
Müsste ich dann mit meinem Programm einfach nach der Bytefolge
(0xEB,0x3C,0x90) suchen, um den Bootsektor zu finden und somit den
Offset zu bestimmen?
Gibt es vielleicht auch Doku, wo das genau und verständlich erklärt ist,
ich lese auch gerne selber nach.
Vielen Dank und Gruß
Christian
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.