Wie SD-Karten-Problem debuggen

  • Wie SD-Karten-Problem debuggen

    Hi Leute,

    ich habe ein Lochraster-SD2IEC nach larsp (ATMEGA1284), das sei langem zuverlaessig mit (fast) allen SD-Karten, die ich so finden konnte funktioniert. Leider aber nicht mit meiner transcend FlashAir SD-Karte - diese Karte hat ein integriertes WLAN und soll eigentlich dazu dienen die Kommunikation zw. C64 und einem PC herzustellen.

    Die SD-Karte funktioniert anscheinend bei anderen Leuten durchaus in einem SD2IEC (siehe hier), nur bei mir eben nicht. Meine Karte spielt auch problemlos in anderen Geraeten. Nur eben nicht in meinem SD2IEC.

    Gibt es irgend eine Moeglichkeit die Kommunikationsprobleme mit der SD-Karte zu debuggen? Irgend eine Moeglichkeit, die Kommunikation zu loggen oder per Logic Analyzer auf die Signale zu schauen und daraus schlau zu werden? Oder gibt es womoeglich eine Konfiguration der Firmware, die meine Problematik erzeugen/vermeiden kann? Ich uebersetze die SD2IEC-Firmware seit laengerem selbst und habe daher die Freiheit an saemtlichen Settings zu drehen. Bei den SD-Karten spezifischen hardware-Settings gibt es einiges, was ich aber nicht ausreichend verstehe, um sinnvoll daran rumzuschrauben.

    Was kann ich nur tun, um die Problematik weiter einzugrenzen???

    Ich waere fuer jede Hilfe dankbar!

    Andi
  • andi6510 schrieb:

    Die SD-Karte funktioniert anscheinend bei anderen Leuten durchaus in einem SD2IEC (siehe hier), nur bei mir eben nicht. Meine Karte spielt auch problemlos in anderen Geraeten. Nur eben nicht in meinem SD2IEC.
    Zu langes Kabel?

    Gibt es irgend eine Moeglichkeit die Kommunikationsprobleme mit der SD-Karte zu debuggen?
    Mein üblicher Ansatz dafür ist es, in sdcard.c:send_command zwei printfs hinzuzufügen, die den zu sendenden Befehl und die Antwort der Karte darauf über die serielle Schnittstelle ausgeben. Damit kann man parallel zum Quellcode recht gut verfolgen, ab wo die Karte nicht mehr mitspielen mag. Wenn es schon beim ersten Kommando Fehler hagelt ('x' in der seriellen Ausgabe) empfiehlt sich ein Blick auf die Hardware. Wenn die Initialisierung durchläuft und dann die ersten Lesezugriffe scheitern empfiehlt sich das ebenfalls, da am Ende der Initialisierung die SPI-Geschwindigkeit erhöht wird.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Danke, @Unseen, das ist schon mal ein Ansatz. Serielle Verbindung zum Debuggen habe ich schon angetueddelt. Jetzt brauche ich nur noch mal etwas mehr Zeit, um die Firmware mit debug outputs zu ergaenzen.

    Kabellaenge betraegt ca 5cm von den 5V->3,3V Spannungsteilern. Es geht aber von einem Wannenstecker auf ein Flachbandkabel (5cm) und von Dort an eine kleine Platine mit dem SD-Karten-Slot. Direkt am Slot sind die Signale aber recht knackig laut Oszi-Messung. Die Karte sendet laut Oszi-Messung am Anfang auch ein paar bits zurueck und schweigt danach fuer immer. Koennte also tatsaechlich am Hochschalten der SPI-Clock liegen. Kann man das testweise wegkonfigurieren???

    Ich habe noch ein paar Levelshifter rumliegen. Ich glaube die baue ich mal rein. Das mit den Spannungsteilern ist mir doch etwas suspekt.
    Der Karte habe ich einen dedizierten 3,3V Regler verpasst. Die sollte daher sauber versorgt sein. Ich messe auch keine Glitches auf der Versorgungsspannung.
  • andi6510 schrieb:

    Koennte also tatsaechlich am Hochschalten der SPI-Clock liegen. Kann man das testweise wegkonfigurieren???
    Ja, einfach das spi_set_speed(SPI_SPEED_FAST) auskommentieren, dann läuft der Bus die ganze Zeit über mit <400kHz. Merkt man vor allem bei langen Directories und beim ersten Berechnen des freien Speicherplatzes auf FAT32-Karten.

    Der Karte habe ich einen dedizierten 3,3V Regler verpasst. Die sollte daher sauber versorgt sein. Ich messe auch keine Glitches auf der Versorgungsspannung.
    Gut, dann kann ich mir den Tip mit 100nF zwuschen Vcc und GND direkt am SD-Sockel sparen.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    Gut, dann kann ich mir den Tip mit 100nF zwuschen Vcc und GND direkt am SD-Sockel sparen.
    Na den habe ich natürlich ganz automatisch mit eingebaut. Direkt am Sockel selbstverständlich
    Werde mal die SPI-clock runter drehen - wenns dann geht muss ich an der Hardware wohl noch ein bisschen optimieren ;)
    Wenn nicht, dann kommen printfs rein...
  • Benutzer online 1

    1 Besucher