Datum:
Hallo zusammen, ich habe für einen ATmega644 ein Programm zum auslesen einer SD-Karte (Fat16, 512MB) geschrieben. (3,3v-Regler und Levelshifter verwendet). Das klappt auch wunderbar, die Karte antwortet auf die CMD0 und CMD1-Kommandos wie sie soll! Lese ich jetzt per CMD17 mit Argument "00 00 00 00" den ersten Block aus, empfange ich auch 512 Bytes Daten, soweit so gut! Allerdings unterscheidet dich dieser erste Block, vom Sektor 0 der Karte! Über den PC ausgelesen, sieht der Sektor (=Bootsektor) so aus, wie er soll (FAT16), Sprunganweisung am Anfang, "55 AA" am Schluss, und so weiter. Die Antwort auf mein CMD17 zum auslesen des Blocks sieht allerdings etwas anders aus: 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 03 33 00 0F 04 D3 CD EF 00 00 00 1F 04 0E 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 55 AA Wie kommt das? Immerhin ist das ausgelesene auch ein Bootsektor (55 AA am Schluss). Habe ich den falschen Sektor/Block gelesen? Wie setzt sich das Adress-Argument im CMD17-Command zusammen? Startbyte? Oder Startblock? Und was habe ich dann ausgelesen? Danke schonmal für Eure Hilfe!!
Autor:
Knut Ballhause
(Firma: TravelRec.)
(travelrec)
Datum:
Hast Du am Datenasgang der Karte einen PullUp nach 3.3V? Falls nicht, kannst Du die Antworten der Karte gar nicht richtg auswerten, da diese den SPI-Bus erst dann korrekt bedient, wenn die ersten Init-Kommandos erfolgrech angekommen sind . Eine erfolgreiche Init ist auch die Grundvoraussetzung für plausible Daten beim Leseversuch.
Datum:
du liest den Masterbootrecord mit der partiionstabelle 33 00 0F 04 D3 CD EF dort steht wo der bootsector liegt etc
Datum:
@Travel Rec. ich verwende das Evaluationsboard nach http://heldt-intern.dyndns.org/index.php?page=atme..., da sollte mit der Beschaltung alles stimmen, und das init funktinoiert ja auch korrekt (CMD0 und CMD1)! @Bereits Fort: Das ist interessant, ich werde mal googeln wie ich daraus den Sektor des Bootsektors errechne! Interessant auch, das das PC-Tool den mbr-Sektor ignoriert, und die Anzeige erst mit dem Bootsektor beginnt - obwohl, so abwegig ist das auch nicht... Was ich jetzt allerdings noch wissen müsste ist, wie ich den Parameter berechnen muss, den ich der Karte im CMD17 zum Block-read übergeben muss, weis das jemand? Viele Grüße André
Datum:
wenn ich heute abend zeit habe such ich dir raus was ich schon raus gefunden habe. Leider gibt es SD mit und ohne partitionstabelle und das lässt sich nicht so leicht unterscheiden. im MBR ist lauffähiger 86er-Code enthalten der entweder Teil des Bootrecords selbst ist oder die Partitionstabelle auswertet welche auf den Bootrecord der Bootpartition verweist. und an diese übergibt. Leider habe ich noch kein eindeutiges Merkmal zur Unterscheidung von Bootrecord und MBR gefunden ohne den 86er-Code auszuwerten.
Datum:
Hi, Master Boot Record =0 Volume Boot Record =1C6h(4Byte) in Master Boot Record FAT-Einträge = Volume Boot Record + 0Eh(2Byte) in Volume Boot Record Verzeichniseinträge = FAT-Einträge + (16h(2Byte) * 10h(1Byte)) in Volume Boot Record Datenbereich (Cluster 0) = Verzeichniseinträge + (11h(2Byte) * 32 / 512 )in Volume Boot Record Viel Spaß
Datum:
Achso und Vorsicht, Fat benutzt little Endian.
Datum:
@ Fabian Ostner Hmm, leider habe ich Dein posting nicht so ganz verstanden... Also den Karteninhalt der mir am PC angezeigt wird, also VolumeBootRecord, FAT, Stammverzeichnis, Datenbereich, das hab' ich alles verstanden. Die Partitionstabelle im mbr hab ich inzwischen auch durchstiegen, allerdings nicht in meinem konkreten Fall, da machen die Angaben irgendwie keinen Sinn, vor allem die periodischen "0F 04" irritieren mich!
Datum:
die 0f 04 irritieren mich auch sieht nach nem systematischen Fehler aus nimm mal ne andere SD und /oder nen andern Sector/Block und Kontrolliere deine Routine da scheint mir auch was faul.
Datum:
XX 0 1 2 3 4 5 6 7 8 9 A B C D E F 00 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 01 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 02 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 03 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 04 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 05 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 06 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 07 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 08 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 09 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 0A 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 0B 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 0C 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 0D 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 0E 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 0F 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 10 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 11 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 12 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 13 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 14 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 15 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 16 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 17 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 18 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 19 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 1A 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 1B 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 03 1C 33 00 0F 04 D3 CD EF 00 00 00 1F 04 0E 00 00 00 1D 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 1E 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 00 00 1F 00 00 0F 04 00 00 00 00 00 00 0F 04 00 00 55 AA |
Datum:
@ Bereits Fort > die 0f 04 irritieren mich auch sieht nach nem systematischen Fehler aus > nimm mal ne andere SD und /oder nen andern Sector/Block eine andere SD muss ich erst besorgen, und einen anderen Sektor/Block zu lesen klappt nicht, denn andere Argumente beim CMD17 als "00 00 00 00" liefern eine ungültige Antwort von der Karte, daher auch die Frage nachd er korrekten Adressierung der Sektoren.... > und Kontrolliere deine Routine da scheint mir auch was faul. Hmm, okay, ich schaus mir nochmal an, aber die Routine mach im Prinzip nix anderes als nach Senden des Kommandos und Erhalt der Antwort 512 Bytes über SPI einzulesen...
Datum:
dein Volume Bootrecord sollte in sector 00 00 00 EF beginnen
Datum:
Bereits Fort wrote: > dein Volume Bootrecord sollte in sector > 00 00 00 EF > beginnen Danke schonmal! das deckt sich lustigerweise auch mit der Angabe der 239 (=EF) "versteckten" Sektoren aus dem VolumeBootRecord, den ich mit Windows auslesen konnte ;) Jetzt muss ich nur noch die Angabe "EF" in eine Adresse umrechnen, die ich der SD-Karte übergeben kann....
Datum:
Hallo Andre, also die Addressierung erfolgt Sektorweise. Das heisst du kannst immer nur mit einem vielfachen von 512 addressieren. Z.B 0x00000000 = MBR , oder 0x00000200 , oder 0x00000400 , usw.... Gruß
Datum:
Die vielen 0F 04 Gruppen sehen auf jeden fall nach schrott aus. Dein PC Programm arbeitet mit dem Logischem und nicht mit dem Physikalischem Laufwerk.
Datum:
Okay, habs grad ausprobiert. Die Adressierung mit vielfachen von 512 funktioniert, und der VolumeBootRecord liegt auch an EF, so wie ich ihn vom PC her kenne! Allerdings wird jeder Sektor beim Auslesen von Diesen 8 Byte-periodischen 0F 04 überlagert, wenn auch nicht immer mit dem gleichen Offset! Woher kann das kommen??
Datum:
auch bei ner anderen SD? wenn ja dann stimmt was an deinem programm (leseroutine ?) (anzeigeroutine ?) nicht. sonst könnte es ein kommunikationsfehler sein.
Datum:
Hallo, lade dir mal WINHEX runter und schau mal nach ob die 0F 04 wirklich da stehen. Falls nicht dann poste doch mal deine SD_lese Routine. Bzw. ich rate einfach mal du speicherst den gelesenen #Sektor im EEPROM, also auch die Routine mal posten. Gruß
Datum:
Angehängte Dateien:Hmm, mit einer anderen Speicherkarte funktionierts einwandfrei, kein Byte das da nicht hingehört! Am PC wird der Inhalt der fehlerhaft dargestellten Karte aber korrekt angezeigt, ohne die "0F 04"... Anbei der Code, leider schlecht kommentiert, aber die relevanten Sachen laufen am Ende vom Programm bzw. in den SUBs und Funktionen ab... Ach ja, hab' ich schon erwähnt das ich das ganze in Bascom mache? ;) hier noch schnell die Lese-Routine auf einen Blick: unmittelbar nach Sendendes Kommandos und Erhalt der R1-.Antwort (0x00) folgt:
Do Spiin Tmp , 1 Loop Until Tmp = &HFE For J = 0 To 511 Spiin Buffer(j) , 1 Next J Spiin Tmp , 1 Spiin Tmp , 1 |
Hätt ich also doch nicht die günstigste Karte bei ebay kaufen sollen, wenn die SanDisk geht? ;)
Datum:
>Hmm, mit einer anderen Speicherkarte funktionierts einwandfrei, kein >Byte das da nicht hingehört! >Am PC wird der Inhalt der fehlerhaft dargestellten Karte aber korrekt >angezeigt, ohne die "0F 04"... Das spricht für einen zyklischen Kommunikationsfehler. etwas langsamer takten?
Datum:
Bereits Fort wrote: > Das spricht für einen zyklischen Kommunikationsfehler. > > etwas langsamer takten? Habe den identischen Fehler bei minimaler (/128) und maximaler(/4) Geschwindigkeit! (Zwischenwerte nicht getestet...). Der Mega644 läuft auf 16 MHz...
Datum:
Zeig mal die spiin oder machst du mit HW SPI Laufen noch irgendwelche Timer oder andere Interrupts? wo liegt Buffer.
Datum:
Bereits Fort wrote: > Zeig mal die spiin oder machst du mit HW SPI spiin ist die Bascom-Interne Routine. Benutze HW-SPI. > Laufen noch irgendwelche Timer oder andere Interrupts? keine Timer, keine Interrupts... einzige weitere Peripherie ist ein LCD-Display, aber das tut eigentlich nichts während dem Einlesen der Daten > wo liegt Buffer. Äh, denke mal im SRAM? -> Dim Buffer(512) As Byte
Datum:
? mist! wenn das bei anderen SD funktioniert kanns der buffer nicht sein sind die 3V stabil ? nen Blockkondensator direkt an der SDkarte ? ich hatte damal eine da ist die spannung beim lesen periodisch eingebrochen gab nen ähnliches Bild. Bis hin zum absturz(aufhängen der SPI) ach ja dan gabs da noch verschiedene SPI modi an der HW-SPI das timing bezüglich der Flankenfolge betreffend.
Datum:
@ Travel Rec. >Hast Du am Datenasgang der Karte einen PullUp nach 3.3V? Falls nicht, >kannst Du die Antworten der Karte gar nicht richtg auswerten, Das ist mir neu. Pullup braucht man nicht. Es sei denn man möchte ein 0xFF falls die Karte nicht drin ist und der Eingang demzufolge floaten würde.
Autor:
Knut Ballhause
(Firma: TravelRec.)
(travelrec)
Datum:
Der Ausgang der SD-Karte floatet so lange, bis der SPI-Modus angewählt ist. Eine Reaktion der Karte auf das erfolgreiche Auswählen des SPI-Modus kann man nur dann abfragen, wenn man in der Init solange weiterclockt, bis die Karte mit einem Wert ungleich $FF antwortet. Ohne PullUp ist dieser anfängliche Status undefiniert und die Init kann in eine Sackgasse laufen.
Datum:
>The SD Card is powered up in the SD mode. It will enter SPI mode if the CS >signal is asserted >(negative) during the reception of the reset command (CMD0). Eigentlich muss man doch nur CS auf low ziehen wenn CMD0 gesendet wird. Dann ist sie im SPI Mode. Pullup nicht mehr nötig. Oder habe ich das falsch verstanden?
Autor:
Knut Ballhause
(Firma: TravelRec.)
(travelrec)
Datum:
Das hast Du schon korrekt verstanden, aber die Karte zieht den DataOut erst dann auf einen definierten Pegel, wenn der SPI-Mode aktiviert wurde und das ist erst nach erfolgreicher Ausführung des CMD0 der Fall. Vorher floatet der Pin. Du bekommst bei der Response R1, die dem CMD0 folgen muß also möglicherweise zu früh eine vermeintlich korrekte Antwort, weil der Pin gerade auf 0 geht, obwohl die Karte noch gar nicht bereit ist. Du versuchst dann weiter zu initialisieren und bekommst nur noch Müll oder gar nichts zu lesen. Mit PullUp ist die Leitung definiert logisch 1, solange die Karte benötigt, um den Ausgang zu aktivieren.
Datum:
>Mit PullUp ist die Leitung definiert logisch >1, solange die Karte benötigt, um den Ausgang zu aktivieren. Ja ok. Dann frag ich mich nur noch warum ich noch nie einen Pullup brauchte? Mit zwölf unterschiedlichen Karten geht es ohne. Bei einigen muss man nur CMD0 bis zu drei mal senden. Vieleicht versuch ichs mal irgendwann mit Pullup ;)
Datum:
Mir erklärt das, warum ich anfänglich erhebliche Schwierigkeiten mit der Initialisierung hatte.
Autor:
Knut Ballhause
(Firma: TravelRec.)
(travelrec)
Datum:
Ich sende CMD0 exakt ein einziges Mal, bei allen der 10 bisher probierten Karten.
Datum:
Hmm, also ich habe zwischenzeitlich sowohl einen extra 100nF Kondensator an der Versorgungsspannung, als auch einen 10k Pullup an Do der Karte gehängt. Trotzdem werden Die Daten der billigen SC-Karte von den periodischen Störungen überlagert, die SanDisk-Karte funktiniert einwandfrei... Werde dann wohl gezwungenermaßen die billige Karte aussortieren (Oder möchte sie einer von Euch in seiner Schaltung ausprobieren?) Oder ich teste Sie mal in der Digicam, vielleicht kommt die ja damit zurecht! Danke trotzdem für Eure Unterstützung, und wenn noch jemandem was einfällt... :) Viele Grüße André
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten