Hardware Debugging mit dem Oszi: Banana Pi BPI-M6 will nicht von SD Karte booten

Als kleiner Einstieg in die Thematik empfehle ich, meine vorhergehenden Artikel zu lesen. Zum einem die allgemeine Vorstellung des neu auf den Markt gekommenen Banana Pi BPI-M6, dann meine Anleitung, wie man Images, also Betriebssystemabbilder wie die Android Tablet Firmware ins eMMC hochlädt / flasht.

Mein Problem derzeit ist, dass es ein neues Ubuntu Linux Image gibt, dass allerdings nur von SD-Karte gebootet werden kann und sich mein Banana Pi M6 bisher standhaft weigert, von SD Karte zu booten. Solch ein Unterfangen wurde immer mit einem dwcmshc_send_cmd, wait command 0 complete time out! quittiert und abgebrochen.

Da ich irgendwie den Verdacht habe, dass mein Board einen Fehler bei den Leitungen zum SD-Port hat, habe ich den Bootvorgang mittels FTDI-Adapter gedebuggt. Das heißt, ich habe mir über einen FTDI-Adapter an der seriellen Schnittstellte die Debug-Meldungen ausgeben lassen und gemutmaßt, was diese im Zusammenhang mit dem Fehlverhalten wohl bedeuten werden.

Im letzten Artikel dann habe ich dann weiteres Debugging auf Firmware-Ebene betrieben und zwar mit der von Support empfohlenen SD-Karte und anhand von Debug-Logs vom Entwicklungsteam bei Banana Pi Org. Da kristallisierte sich schon heraus, dass wahrscheinlich die Hardware des SD-Card-Slots auf meinem BPI-M6-Board defekt sein würde.

Um die eingegrenzte Fehlerursache, nämlich, dass der SD-Card-Slot nicht richtig kommuniziert, weil nicht richtig angeschlossen oder dergleichen, schließlich auch bewiesendermaßen zu bestätigen, habe ich heute ein kleines Experiment in Hardware vor.

Der Micro SD Card Sniffer

Es gestaltet sich schon aus rein mechanischen Gründen nicht so einfach, den Datenverkehr auf dem SD-Kartenslot mit einem Oszilloskop mitzulesen, denn die Anschlüsse sind sehr klein und Platz für eine Messung ist natürlich auch keiner mehr, wenn eine SD-Karte eingeschoben ist.

Ich habe mir darum aus China zu einem annehmbaren Preis von wenigen Euro einen sogenannten "microSD Sniffer" bestellt, der nun auch angekommen ist. Im Grunde ist das eine kleine Platine, dessen eine Seite wie eine µSD-Karte geformt ist und auch die gleichen Kontaktflächen hat. Diese wird wie eine SD-Karte in den zu untersuchenden Slot eingeführt.

Auf der anderen Seite hat der Sniffer einen weiteren µSD-Slot, in den man die untersuchende SD-Karte einschieben kann. Zwischendrin gibt es dann ein paar Header-Pins, an denen man die Signale abklemmen kann. Hier kann man dann bequem ein Oszilloskop anschließen.

Die Idee

Die Kommunikation mit dem SD-Slot muss einem bestimmten Protokoll folgen. Wie bei den meisten Bustypen in der digitalen Mikroelektronik gibt es dazu ein Taktsignal und ein Datensignal, dass sich an diesem Taktsignal orientiert. Pro Takteinheit wird ein Bit übertragen.

Wie man auf dem Schaltplan des Banana Pi M6 sieht, findet sich das Prinzip auf hier wieder: CLK (für Clock) stellt ein Taktsignal gegen GND (Ground, Masse) zur Verfügung, auf den Datenleitungen DAT0 bis DAT3 werden dann die Daten übertragen, je vier Bits pro Taktzyklus.

Ohne Takt keine Kommunikation. Wenn ich also mit dem Oszilloskop zwischen GND und CLK messe, sollte ich bei jedem Kommunikationsversuch einen Takt sehen und - wenn Daten übertragen werden - auch etwas auf dem DAT0-Kanal.

Der Versuchsaufbau

Zuallererst will ich schauen, ob meine Idee / Theorie richtig ist. Dazu nehme ich ein Gerät her, von dem ich sicher weiß, dass es funktioniert und auf dem SD-Card-Slot kommuniziert: einen Raspberry Pi Zero. Der wird versuchen beim Einschalten von der SD Karte zu booten. Dazu muss er mit dem Slot kommunizieren und die Blocks von der SD Karte abrufen.

Ich stecke also den SD Sniffer in den SD Slot des Raspberry Pi und dann schließe ich Channel 1 (gelb) meines Oszis an GND und CLK und Channel 2 (blau) an GND und Data0 des Sniffers.

Um mir die Sache mit dem Einschalten zu erleichern, benutze ich eine Powerbank, die ich leicht ein- und ausschalten bzw. an- und abbstecken kann.

Test mit einem Raspberry Pi Zero

Zuerst versuche ich den Raspberry Pi Zero ohne eingelegte SD-Karte.

Die Versorgungsspannung ist übrigens nicht 1.8V, wie zuvor angenommen, sondern liegt hier bei 3.3V, wie ich mit dem Multimeter nachmessen kann. Die Spezifikation für SD gibt übrigens 2.7V bis 3.3V, max. bis 3.6V vor.

Ein bisschen irritiert bin ich zuerst, weil ich DAT3 auf dem Sniffer Board nicht finden kann. Allerdings teilen sich CD (Kartenerkennung) und DAT3 (Datenleitung Bit 3) eine Leitung. CD ist also auch DAT3. Da fehlt nichts auf dem Sniffer Board, die Beschriftung ist nur ein bisschen kurz.


Als ich Strom über die Powerbank auf den Raspberry Pi gebe, sehe ich, dass ich Recht gehabt habe. Für eine kurze Weile, vielleicht eine Sekunde, versucht der Raspberry Pi Zero auf die SD-Karte zuzugreifen, was man an dem Takt auf CLK erkennen kann. Da die SD-Karte aber nicht antwortet, gibt der Raspi bald auf und stellt den Takt wieder ein.

Das Protokoll ist hier übrigens auffallend langsam getaktet, wohl um auch zu langsamen Karten Kontakt aufnehmen zu können. Erlaubt sind laut SD-Spezifikation 0 bis 25 MHz, für High Speed Cards auch bis 50 MHz

Es gibt übrigens auch eine SPI-Modus im SD-Protokoll, dass dann nur ein Datenbit benutzt. Mit Verwendung von DAT0 liege ich aber auf jeden Fall auf der sicheren Seite.


Als nächstes versuche ich es mit einer eingelegten SD-Karte. Diese wird sofort vom Raspi erkannt und der setzt den Takt hoch, um mehr Daten in einem Zeitabschnitt übertragen zu können. Es soll ja schließlich flott gehen.

Rechts ist die gelbe Kurve das Taktsignal und die blaue Kurve sind die Datenbits auf Data0. Wie man sieht, werden hier Daten übertragen. Und zwar solange, bis der Raspi merkt, dass er von dieser leeren SD-Karten nicht booten kann. Dann stellt er die Kommunikation ein. Alles genau richtig gemacht, Raspi.

Und es ist klar, dass es eine Kommunikation geben muss: zumindestens soviele Daten müssen übertragen werden, um daran erkennen zu kennen, dass es nicht die richtigen sind.

Grundsätzlich funktioniert das SD-Protokoll so, dass ein Command über die CMD-Leitung vom Host (also dem Raspberry Pi oder Banana Pi) an die SD-Karte geschickt wird. Diese wird dort von dem auf der SD-Karte befindlichen Controller mit einem Response beantwortet. Danach kann dann der Datentransfer über die vier Datenleitungen erfolgen. Durch die Trennung auf Command und Data Channel kann der Host auch auf dem Command Channel "zwischenrufen", das er jetzt doch keine Daten mehr braucht.

Ansonsten braucht es immer ein Block Signal für Data und Command Channel. Und jeder Datenblock wird mit einer CRC, einer Checksumme abgeschlossen, die verglichen wird. So kann festgestellt werden, ob ein Block fehlerhaft übertragen wurde, zum Beispiel durch Störungen auf der Leitung, und erneut übertragen werden muss.

Test mit meinem wohl defekten Banana Pi M6

Nachdem der Raspi Zero meine Theorie bestätigt hat und die Kommunikation auf dem SD-Bus wie erwartet war, schließe ich nun den Banana Pi M6 mit dem SD-Boot-Problem an den Micro SD Sniffer und mein Oszilloskop an.

Das geht vom Platz her eigentlich ganz gut. Die Länge der Sniffer Karte läßt genügend Platz und der M6 ist ja auch nicht verbaut. Außerdem ist es natürlich von Vorteil, dass kein Gehäuse im Weg ist.


Zuerst versuche ich es ohne eingelegte µSD-Karte. Ich halte den SPI-Button des M6 gedrückt, womit der sich in einer Dauer-Boot-Schleife befinden sollte, solange ich den Knopf drücke.

Doch nichts, rein gar nichts, tut sich auf dem Bus. Weder liegt irgendein Takt an, noch tut sich irgendwas auf der Data0-Leitung.

Eigentlich sollte doch bei jedem Boot-Versuch etwas über den SD-Port geschickt werden. Aber es kommt nichts an.

Und ich glaube, genau das will mir die Fehlermeldung dwcmshc_send_cmd, wait command 0 complete time out! sagen: Es wurde ein Command an die SD-Karte geschickt, aber es kam kein Response von der SD-Karte bzw. vom Controller darauf zurück. Ganz einfach, weil hier keine Verbindung besteht.

Aber wie das halt mit Fehlermeldungen so ist. Was sie wirklich bedeuten, weiß nur der Entwickler des Codes, der die Fehlermeldung da rein geschrieben hat. So konnte auch der Banana Pi Suport das für eine Fehlermeldung halten, die auftritt, wenn die SD Karte nicht kompatibel ist. Denn eigentlich ist sie ja schon aussagekräftig, wenn man weiß, dass

• dwcmshc wohl für das SD-Karten-Kommunikationsfunktion steht. SHC gibt einem ja schon einen Hinweis in der Richtung. Es gibt ja den SDHC Standard bei SD-Karten
• send_cmd für "send command" steht. Da kann man drauf kommen. Und gemeint ist das Senden des Commands auf der Command-Leitung des SD-Ports. Gut, wenn man weiß, dass ein Command das erste ist, was über die Leitung geht
• wait command 0 complete time out steht dann dafür, dass die Funktion eine gewisse Zeit auf Antwort, auf den Response gewartet hat, der nie kam und dann abbrach.

Wenn keine Verbindung besteht, also keine Signale durchkommen, dann muss die erste Übertragung, das Command, ja wie ein Ruf ohne Echo im Nichts verhallen. Und das ist die Fehlerursache.


Als nächstes lege ich eine µSD-Karte in den Sniffer, aber auch hier: nichts, rein gar nichts. Der SD-Card-Slot von meinem BPI-M6 ist komplett tot. Wie ein toter Fisch. Da zappelt nichts mehr.

Quod erat demonstrandum

Nun habe ich wenigstens Gewissheit: Der Patient leidet unter teilweisem Organversagen: Der SD Slot ist ohne Funktion. Was aber nicht heißen muss, dass der BPI-M6 gar nicht mehr am Leben teilnehmen kann.

Ich hoffe auf ein brauchbares eMMC-Image irgendwann in der Zukunft, von dem ich dann booten kann und den teil-invaliden M6 doch nur einem Zweck zuführen kann. Das edle Gerät wäre einfach zu schade, wenn man es nicht doch noch zu irgendwas gebrauchen würde.

Video

Bestimmt werdet ihr das folgende Video zu schätzen wissen, in dem ich live das Experiment durchführe. Da kann man dann auch besser sehen, wie lange die Signale andauern:



Natürlich gibt es wieder - wie ja immer - ein paar extra Kommentare von mir.

Die weiteren Aussichten

Gute Nachrichten indes von der Banana Pi Org: Man ist dort nun auch überzeugt, dass ich dummerweise ein Exemplar mit Fehler erhalten habe und will mir bald ein Neues schicken. Aber jetzt ist erst einmal chinesisch Neujahr. Da feiert China zwei Wochen lang und alles geht ein wenig gemählicher. Gegönnt sei es ihnen.

Sobald mein neuer, dann hoffentlich heiler, Banana Pi M6 ankommt, mache ich natürlich den versprochenen Test des Ubuntu Images.

Das Ersatzgerät ist da! Hier geht es zum Test des Ubuntu Linux Images.

Quellen, Literaturverweise und weiterführende Links