Hallo, ich steuere mit einem Mega128 eine Sd Card (128MB, Hersteller Ridata) über SPI an. Spannungsversorgung über LM317 mit 3,6V. Im wesentlichen halte ich mich dabei an die Schaltung und Software von Ulrich Radig. Reset mit Cmd0 und Initialsierung mit Cmd1 klappen und ich erhalte die richtigen Responses (0x01 für Cmd0 und 0x00 für Cmd1). Die Karte wird also erkannt. Allerdings kann ich keine Datenblöcke wie z.B. die Antwort auf Cmd9 (SEND_CSD Card Specific Data) auslesen. Das erste Byte der Antwort sollte ja 0xFE (Data Token Start Block) sein. Die SD Card antwortet allerdings immer mit 0xFF. Die Leseroutine von Ulrich Radig bleibt somit in einer Endlosschleife, die auf das richtige Data Token wartet. Hat jemand einen Tip? Ich verstehe ausserdem auch nicht warum ich ausgerechnet 0xff als Antwort für den Lesezugriff erhalte. Bit 4-7 eines Data Error Token müssten doch laut Spec. 0 sein. Danke
Schonmal die Suche bemüht? http://www.mikrocontroller.net/forum/read-1-312491.html#321153 hab ich bestimmt schon 10x auf eine Anfrage wie Deine verlinkt.
Erstmal Danke. Aber ich habe die Suche bemüht und deinen Thread auch bereits schon gelesen gehabt. Leider hilft er mir nicht weiter. Ich hab die MISO Leitung über zwei Transistoren um wieder einen Pegel von 5V für den Mega128 zu erhalten an die Sd Card angeschloßen (wie in der optimalen Anbindung von Ulrich Radig vorgeschlagen). Die Ausgänge des Mega128, MOSI, CS und SCK sind über einen MM74HC4050 (Hex Logic Level Down Converter) zur Pegelanpassung auf 3,3V an die Sd Card angeschloßen. Ich kann die Argumetation mit Flankensteilheit auch nicht ganz nachvollziehen. Konsequenterweise müsste ja dann auch schon die Initialisierung scheitern.
Warum versuchen alle das Rad neu zu erfinden? Benutz doch einfach EFSL (http://sourceforge.net/projects/efsl/). EFSL unterstützt Super-Floppy SD-Cards, partitionierte SD-Cards, Fat12, FAT16, VFAT, FAT32, läuft auf vierschiedenster Hardware (u.a. auch Atmega128) und lässt sich supereinfach an neue Hardware anpassen.
Ich kann mir das mit der Flankensteilheit so erklären: In einer SD-Karte sitzen mehrere "Prozessoren". Einer für die Kommunikation nach außen, einer für die Datenverwaltung im Inneren. (Weiß jetzt nicht, wie die heißen, aber in der Spec ist da bestimmt ein schönes Bildchen dazu.) Die Einfache Lösung beim Daten-Lesen wäre, dass der Datenverwalter (D) die Daten an den Kommunikator (K) schickt und der reicht sie raus. Geschickter wäre es, wenn der K an den Stellen, an denen die Daten kommen müssen, D kurz in die Seite rempelt und der liest dann seine Bits vor, dann ist wieder K dran. Wenn D bezüglich der Flankensteilheit etwas empfindlicher ist als K, dann ergibt sich unser Szenario: Initialisierung geht wunderbar, sobald die Daten kommen sollen hapert's aber. Das war aber nur so eine Idee von mir. Keine Ahnung, ob das so realistisch ist. Tatsache ist aber, dass die Symptome gleich sind (Initialisierung geht, Daten - insbesondere Start-0xFE - gehen nicht) und dass schon einige den gleichen Fehler bei Spannungsteilern und/oder zu langen Leitungen hatten (was widerum auf die Flankensteilheit deutet). Ich habe hier auch irgendwann mal einen Thread gelesen, der schreib, dass Ulrich Radigs "optimale" Anbindung überhaupt nicht optimal ist, weil die Transistoren irgendwie zu langsam wären. Flankensteilheit, ick hör Dir trapsen. ;-) @yummy Cookie 1. weil's Spaß macht 2. weil man viel dabei lernt 3. weil viel Raum zum Spielen und Optimieren da ist, wenn man nicht nur fertige Bausteine zusammensteckt. Mein MP3-Player beispielsweise braucht zum SD-Lesen nur wenige Byte RAM. Während des Abspielens verbrauche ich beispielsweise kein einziges Bit RAM für die MP3-Daten, die gehen komplett am µC vorbei.
zu Punkt 1 kann man natuerlich wenig einwenden, wenn's denn Spass macht... zu Punkt 2 und 3. Lernen kann man auch einiges aus fertigen Libraries, auch wenn man deren Code nicht direkt nutzt. Vor allem der Code von Chan ( http://elm-chan.org/fsw/ff/00index_e.html ) ist sehr kompakt (kompakter und weniger speicherhungrig als die EFLS, die ich selbst ebenfalls bevorzuge, da mehr Konfiurationsmoeglichkeiten). Chan bietet auch fertige Testbeispiele in den "sample projects". Zu den "Prozessoren": Es mag nach Hersteller/Baureihe verschiedene Aufbauten geben, aber ein Vertreter eines Kartenherstellers hat mir den internen Aufbau mit nur einem Controller beschrieben, in dem das Speicher- als auch das Kommunikationsinterface integriert ist. Zur eigentlichen Frage: SPI-Frequenz mal variiert (schneller/langsamer nach langsamen Init = pulse an MOSI mit CS unselected). Einen Testaufbau ganz ohne Pegelwandler gemacht? Also Microcontroller und SD-Karte mit gleicher Spannung und direkt verbunden. Damit sollte sich ein Hardwarefehler/"Flankenverschmieren" ausschliessen lassen und man kann sich bei der Fehlersuche auf die Software konzentrieren.
Okay, nachdem bei langsamer SPI Frequenz alles klappte hab ich die MISO Leitung mal direkt an den Mikrocontroller angeschloßen. Siehe da, jetzt gehts auch bei schnellerem SPI Takt! Die Pegelwandlung für die Inputleitungen der SD Card über MM74HC4050 funktioniert allerdings. Danke
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.