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.
@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ß
@ 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...
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...
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.
@ 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.
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.
>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?
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.
>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 ;)
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.
gab es nun eine vernünftige Lösung?
gleichs Problem hier bei verschiedenen Karten
mit und ohne Pull-Up
scheint ein Timing Problem zu sein, denn verändere ich den Speed der
SPI, kommen die fehlerhaften Bytes eine Byte versetzt
Thread beobachten
Seitenaufteilung abschalten