Warum kann ich nach CMD8 keine Befehle an eine SDHC-Karte im SPI-Modus erteilen?

Ich verwende die folgende Befehlsfolge bei 250 kHz SPI, um SD-Karten zu initialisieren:

  • (1 ms warten, dann 80 Takte)
  • CMD0 mit Argument 0x00000000
  • CMD59 mit Argument 0x00000001 (CRC-Prüfung einschalten)
  • CMD8 mit Argument 0x000001AA
  • CMD55 mit Argument 0x00000000 (Präfix für ACMD)
  • ACMD41 mit Argument 0x40000000 (HCS-Bit gesetzt)

Natürlich CMD55-ACMD41 wiederholen, bis der Ruhezustand verlassen wird. Die CRCs sind korrekt (sie werden mit dem entsprechenden Algorithmus berechnet). Chip Select wird nach jedem Befehl (einschließlich zwischen CMD55 und ACMD41) mit acht nachlaufenden Takten freigegeben.

Diese Sequenz funktioniert gut für drei SDSC-Karten, die ich habe; Ich kann Daten von ihnen nach Abschluss der Initialisierung lesen. Allerdings scheitern die beiden SDHC-Karten, die ich habe, daran.

Beide schreiten ordnungsgemäß bis CMD55 fort (einschließlich einer 0x01 R1-Antwort von CMD8), dann reagieren sie auf CMD55 wie folgt:

  • Maxell X Series SDHC Class 4 8 GB (S708G1249 TP2T0M2B49059): Kein R1, selbst nach dem Empfang von 256 0xFF Stuff Bytes.

  • PQI SDHC Class 4 4 GB (BH1013316030G): 0xC2 kommt nach 5 0xFF Stuff-Bytes, bei denen Bit 7 gesetzt ist (bei einem R1 sollte dieses Bit nicht gesetzt sein), sonst ist nicht einmal Bit 0 gesetzt (Idle). sollte sein.

Das Ausgeben von ACMD41 danach auf einer der beiden Karten führt zu einem R1 von 0x05 (unzulässiger Befehl + Leerlauf). Was jetzt? Ich habe noch nicht versucht, sie mit CMD1 zu initialisieren (aber da sie SDHC sind, sollten sie darauf nicht reagieren).

(Beide Karten funktionieren normal, wenn von einem PC oder in einer Digitalkamera, die ich habe, darauf zugegriffen wird.)

Ich habe versucht, andere Befehle auszugeben; sie scheitern auch auf diese Weise. Es scheint also eher so, als wäre die Karte nach CMD8 trotz gültigem R1 irgendwie völlig unzugänglich geworden.

Ich versuche gerade, Daten mit einer SDHC-Karte im SPI-Modus zu lesen/schreiben. Ich habe ein sehr ähnliches Problem.
Ich bekomme nach dem Senden von CMD8 ein korrektes R1 zurück, aber meine CMD55+ACMD41-Befehlsfolge schlägt fehl. Der Hauptunterschied besteht darin, dass CMD55 zurückgibt, was meiner Meinung nach ein korrektes R1 ist (ich bekomme 0x00; ich denke, 0x00 UND 0x01 sind akzeptable Werte), aber mein ACMD41 gibt 0x01 zurück, wenn es 0x00 zurückgeben soll (zumindest nach meinem Verständnis). Außerdem habe ich CMD59 in keinem der SPI-Initialisierungsflussdiagramme verwendet gesehen. Warum haben Sie es verwendet und wie hat es geholfen? Wie auch immer, ich hatte gehofft, Sie könnten den Code posten, den Sie geschrieben haben, damit Sie den vollständigen R7 lesen können?
@CalvinWallenIV Sie erhalten die richtige Antwort für diesen ACMD41 (Leerlauf), Sie müssen die Karte abfragen (könnte mehrere Dutzend Millisekunden dauern), bis die Karte aus dem Leerlauf herauskriecht. Wenn Sie möchten, können Sie den Code überprüfen, es handelt sich hier um einen neuen Bootloader für die Uzebox-Spielekonsole: uzebox.org/forums/viewtopic.php?f=3&t=9405 , vollständiger AVR-Assembler (später wird er dem Projekt hinzugefügt GitHub Repo, derzeit ist es nur als experimentelles Ding da).
@CalvinWallenIV CMD59 ist nicht erforderlich, Sie können die Karte auch ohne initieren. Dieser Befehl kann verwendet werden, um die CRC-Prüfung einzuschalten, was sich als nützlich erwiesen hat, da Karten oder Kartenkonverter möglicherweise schlampige Kontakte haben (und im Fall von Uzebox auf selbstgebauten Versionen auch unzureichende Verdrahtung oder Löten als potenzielle Quellen ins Spiel kommen können wegen Korruption). Es stellt sicher, dass Sie die richtigen Daten erhalten.

Antworten (1)

Ich habe es endlich gefunden.

Sie müssen das vollständige R7 von CMD8 lesen, sonst scheinen SDHC-Karten in irgendeiner Weise blockiert zu sein, sodass sie überhaupt nicht mehr zugänglich sind (ich habe versehentlich das Lesen über R1 hinaus ausgelassen).

Warum kann ich nach CMD8 keine Befehle an eine SDHC-Karte im SPI-Modus erteilen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v