Adressierung der Daten auf einer SD-Karte?

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.

du liest den Masterbootrecord
mit der partiionstabelle

33 00 0F 04 D3 CD EF

dort steht wo der bootsector liegt etc

@Travel Rec.

ich verwende das Evaluationsboard nach 
http://heldt-intern.dyndns.org/index.php?page=atmega32-644-experimentierboard, 
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é

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.

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ß

Achso und Vorsicht, Fat benutzt little Endian.

@ 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!

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.

@ 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...

dein Volume Bootrecord sollte in sector

00 00 00 EF

beginnen

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....

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ß

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??

auch bei ner anderen SD?


wenn ja dann stimmt was an deinem programm (leseroutine ?) 
(anzeigeroutine ?) nicht.

sonst könnte es ein kommunikationsfehler sein.

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ß

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:

1

Do

2

   Spiin Tmp , 1

3

Loop Until Tmp = &HFE

4

5

For J = 0 To 511

6

   Spiin Buffer(j) , 1

7

Next J

8

9

Spiin Tmp , 1

10

Spiin Tmp , 1

Hätt ich also doch nicht die günstigste Karte bei ebay kaufen sollen, 
wenn die SanDisk geht? ;)

>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?

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...

Zeig mal die spiin oder machst du mit HW SPI

Laufen noch irgendwelche Timer oder andere Interrupts?

wo liegt Buffer.

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

? 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.

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.

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.

Mir erklärt das, warum ich anfänglich erhebliche Schwierigkeiten mit der 
Initialisierung hatte.

Ich sende CMD0 exakt ein einziges Mal, bei allen der 10 bisher 
probierten Karten.

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é

Da es ja verschiedene Aussagen zur Notwendigkeit eines Pullups gibt, 
hier meine Erfahrung.
Eine SanDisk Karte hing sich ohne Pullup nur beim Power up des 
Gesamtsystems (STM32F3-Discovery) auf. Nach Entnahme und wieder 
Einsetzen lief sie dann.
Mit 10kOhm Pullup an DataOut lief sie aber auch direkt beim Power up.
Ich werde ihn jedenfalls immer einbauen!
Gruß
Armin

Weil dieser Thread im Wiki erwähnt wird: bei meiner Karte, einer Samsung 
2GB, brauchte es einen Pullup an DO, um dort überhaupt ein Signal zu 
bekommen. Ohne den Pullup war dieses Signal konstant auf Low.

@Markus H. (traumflug)

>Weil dieser Thread im Wiki erwähnt wird: bei meiner Karte, einer Samsung
>2GB, brauchte es einen Pullup an DO, um dort überhaupt ein Signal zu
>bekommen. Ohne den Pullup war dieses Signal konstant auf Low.

So will es auch die Spezifikation. Dass einige Karten scheinbar 
zusätzlich einen Pull-Up eingebaut haben, sollte einen nicht dazu 
veranlassen, diesen Widerstand einzusparen. Das lohnt sich nicht.

@Xaver: Dieser Thread ist bereits 7 Jahre alt. Schildere bitte Dein 
Problem detailliert in einem neuen Thread.