Ich habe eine benutzerdefinierte Platine basierend auf einem ST Microcontroller STM32F103VE, mit einer MiniSD-Karte über den SDIO-Bus des Mikrocontrollers gesteckt. Die elektrischen Verbindungen wurden genau wie in der STM3210E-EVAL board schematics gefunden, überprüft und erneut überprüft, so dass ich starke Zuversicht habe, dass sie korrekt sind. Leider habe ich dieses Evaluierungsboard nicht, um zu testen, ob das, was ich erlebe, ein Hardwareproblem ist, aber es scheint nicht so. Für die folgenden Tests verwende ich eine Kingston 2 GB MicroSD-Karte (Modell MBLYG2/2GB), die erst kürzlich gekauft wurde (sie sollte also der neuesten SD-Kartenspezifikation entsprechen) mit dem mitgelieferten MicroSD-zu-MiniSD-Adapter; habe noch nicht mit anderen Karten getestet.SD-Karte über SDIO-Bus Initialisierungsproblem wegen fehlgeschlagener CRC
Ich folge der SD-Karte physikalische Ebene vereinfachte Spezifikation zu verstehen, was vor sich geht. Der Code, den ich verwende, ist der Beispiel-SDIO-Code, der mit der Standard-Peripheriebibliothek von ST Micro für diesen Mikrocontroller geliefert wird. Es beginnt mit dem Senden von CMD0 (GO_IDLE_STATE), dann CMD8 (SEND_IF_COND) und dann ACMD41 (SD_SEND_OP_COND), was durch Senden eines CMD55 (APP_CMD) gefolgt von CMD41 erfolgt. Die Taktleitung wird mit 400 kHz getaktet, und als Teil meiner Debugging-Bemühungen habe ich eine Verzögerung von etwa 100 Taktzyklen zwischen CMD0 und CMD8 hinzugefügt, da ich irgendwo gelesen habe, dass es notwendig war, zumindest wenn es in SPI arbeitet Modus. Abgesehen von den unten genannten Änderungen entspricht der Code genau dem Beispielcode.
Als ich zuerst versuchte, den Beispielcode auszuführen, hatte CMD55 ein Problem, das passierte, weil der Mikrocontroller die Antwort auf CMD8 pufferte, aber der Beispielcode die Antwort von CMD8 nicht abrufen konnte, also beim Überprüfen der Antwort auf CMD55 , der Code sah tatsächlich auf die Antwort auf CMD8 und wurde dadurch verärgert. Ich habe dieses Problem behoben, indem ich das CMDREND-Flag auf dem SDIO-Peripheriegerät des Mikrocontrollers gelöscht habe, bevor CMD55 gesendet wurde. Wenn also der Code die Antwort auf CMD55 überprüfte, war die Antwort des CMD8 nicht mehr gepuffert.
Das nächste Problem, und das, bei dem ich derzeit feststecke, ist, dass in der Antwort auf CMD55 Bit 23 des Kartenstatusfeldes (COM_CRC_ERROR) gesetzt ist, das anzeigt, dass die CRC-Prüfung des vorherigen Befehls fehlgeschlagen ist zur Spezifikation. Obwohl der Mikrocontroller automatisch den CRC berechnet, schloss ich einen Logikanalysator an den Schaltkreis an, um zu verifizieren, dass er korrekt war. Ich benutze eine Web-App (Sorry, kann nicht verlinken, weil ich ein neuer Benutzer bin, aber nur Google für "CRC ghsi" und es ist das erste Ergebnis), um die CRCs zu überprüfen, mit dem Polynom x^7 + x^3 + 1 gemäß der Spezifikation. Dies ist der Ausgang Logikanalysator, formatierte und von mir kommentiert:
// uC sends CMD0, CRC OK, no response:
01 000000 00000000000000000000000000000000 1001010 1
// uC sends CMD8, CRC OK, check byte = 0xAA:
01 001000 00000000000000000000000110101010 1000011 1
// SD card responds to CMD8, CRC OK, check byte echoed back = 0xAA:
00 001000 00000000000000000000000110101010 0001001 1
// uC sends CMD55, CRC OK:
01 110111 00000000000000000000000000000000 0110010 1
// SD card responds to CMD55, CRC OK, note card status bits 23, 8 and 5 set;
// bit 23 = COM_CRC_ERROR, bit 8 = READY_FOR_DATA and bit 5 = APP_CMD:
00 110111 00000000100000000000000100100000 0000100 1
Beachten Sie auch, dass, wenn ich CMD55 ein zweites Mal unmittelbar nach dem Austausch über versuchen, Bit 23 ist nicht gesetzt:
// uC sends CMD55, CRC OK:
01 110111 00000000000000000000000000000000 0110010 1
// SD card responds to CMD55, CRC OK, bits 8 and 5 still set but 23 not set:
00 110111 00000000000000000000000100100000 1000001 1
Beachten Sie, dass Ich habe versucht, CMD8 zweimal zu senden, bevor CMD55 gesendet wurde, aber es machte keinen Unterschied, der erste CMD55 gibt immer Bit 23 zurück. Ich kann dies jedes Mal wiederholen, wenn ich es versuche, also glaube ich nicht, dass es ein Problem mit Störungen oder Rauschen ist. Wenn man bedenkt, dass die CRCs vom Mikrocontroller selbst berechnet werden, sehen sie korrekt aus, wenn sie von einer externen Instanz (dem Logikanalysator) gesehen werden, und wurden auf der oben erwähnten Website verifiziert. Ich sehe nicht, wie die CRC-Prüfung der Karte ausfallen könnte.
Wird das irgendwie erwartet? Vielleicht sollte ich eine bestimmte Anzahl von Taktzyklen zwischen jedem Befehl warten (irgendwo, wo ich es gelesen habe, sollte es 8 Zyklen sein, und ich glaube, ich respektiere das)? Kann ich einfach eine zweite CMD55 senden, wenn die erste fehlschlägt und unterwegs ist, oder wird es negative Folgen haben? Auch wenn das das Problem behebt, würde ich gerne wissen, warum die CRC-Prüfung fehlschlägt, da ich glaube, dass ich nichts falsch mache.
Ich habe die Version 3.4.0 noch nicht ausprobiert, weil meine Entwicklungsumgebung kein fertiges Projekt dieser Version hatte, aber da Sie vielleicht erwähnen, dass es behoben sein könnte, erstelle ich ein Projekt dafür. Aber ich sollte hinzufügen, dass ich bereits die relevanten Teile des Codes betrachtet habe und keine Änderungen bemerkt habe, die für mein Problem relevant sein könnten. – swineone