SD Karte nach Reset nicht mehr ansprechbar

[Sven S. (schwerminator)]

Hallo,

ich nutze derzeit die MMC-/SD-Karten-Bibliothek von Elm Chan auf einem 
ATmega (5V, 16MHz). Die SD-Karte läuft unter 3V, die Pegelwandlung 
übernimmt ein HC4050. Alles funktioniert bestens, nur nach einem Reset 
egal welcher Art (WDT, Hard-Reset) kann die Karte nicht mehr 
initialisiert werden. Klemme ich dann die Stromversorgung der gesamten 
Schaltung ab und wieder an, funktioniert wieder alles tadellos.

Das Ganze macht den Eindruck, als wäre die SD-Karte in einem internen 
Status, aus dem sie nicht mehr initialisiert werden kann. Ist es möglich 
die SD-Karte per Kommando zu resetten? Das Ganze ließe sich natürlich 
lösen, indem man die Stromversorgung der Karte per Transistor/FET bei 
einem Reset ausschaltet. Diese Möglichkeit habe ich aber nicht. Hat 
jemand einen Tipp zur Problemlösung parat?

Gruß Sven

[holger (Gast)]

>nur nach einem Reset
>egal welcher Art (WDT, Hard-Reset) kann die Karte nicht mehr
>initialisiert werden.

WDT und Hard-Reset sind eine super Idee bei einem
FAT Dateisystem. Da kannst du auch gleich die Karte
komplett formatieren. Das geht sowas von in die Hose;)

>Hat jemand einen Tipp zur Problemlösung parat?

Keine SD Karte mit FAT benutzen. Besser gar keine
SD Karte benutzen.

[Sven S. (schwerminator)]

Es sind zum Zeitpunkt des Resets alle Dateien geschlossen, also sollte 
es keine Probleme geben.

[holger (Gast)]

>Es sind zum Zeitpunkt des Resets alle Dateien geschlossen, also sollte
>es keine Probleme geben.

Und woher weisst du das? Deine Karte reagiert genervt. Da ist also
irgendwas nicht in Ordnung. Du hast den Schreib oder Lesevorgang
unterbrochen. Bei einem Hard-Reset kannst du eigentlich nur noch
beten das die Karte schon fertig war. Sonst gibt es Gurkensalat.

[einGast (Gast)]

kommando zum resetten ist CMD0

[Sven S. (schwerminator)]

holger schrieb:
>>Es sind zum Zeitpunkt des Resets alle Dateien geschlossen, also sollte
>>es keine Probleme geben.
>
> Und woher weisst du das? Deine Karte reagiert genervt. Da ist also
> irgendwas nicht in Ordnung. Du hast den Schreib oder Lesevorgang
> unterbrochen. Bei einem Hard-Reset kannst du eigentlich nur noch
> beten das die Karte schon fertig war. Sonst gibt es Gurkensalat.

Ich bin mir der Gefahren bewusst, darum soll es also hier nicht gehen. 
Ich kann GARANTIEREN, dass zum Reset-Zeitpunkt kein Zugriff auf die 
SD-Karte erfolgt und alle Dateien geschlossen sind.

[holger (Gast)]

>Ich bin mir der Gefahren bewusst, darum soll es also hier nicht gehen.
>Ich kann GARANTIEREN, dass zum Reset-Zeitpunkt kein Zugriff auf die
>SD-Karte erfolgt und alle Dateien geschlossen sind.

Ok, das ist doch mal ne Aussage. Also ich kann zB einen
AVR per ISP programmieren und die SD Karte wird dann
ohne ausschalten nach dem programmieren nach Reset
des AVR wieder initialisiert. Keine Probleme.
Tja, wo ist jetzt dein Problem?

[Sven S. (schwerminator)]

einGast schrieb:
> kommando zum resetten ist CMD0

Das wird in der Bibliothek von Elm Chan gemacht:

DSTATUS disk_initialize (
  BYTE drv    /* Physical drive nmuber (0) */
)
{
  BYTE n, cmd, ty, ocr[4];


  if (drv) return STA_NOINIT;      /* Supports only single drive */
  if (Stat & STA_NODISK) return Stat;  /* No card in the socket */

  power_on();              /* Force socket power on */
  FCLK_SLOW();
  for (n = 10; n; n--) rcvr_spi();  /* 80 dummy clocks */

  ty = 0;
  if (send_cmd(CMD0, 0) == 1) {      /* Enter Idle state */
[...]

und

static
BYTE send_cmd (    /* Returns R1 resp (bit7==1:Send failed) */
  BYTE cmd,    /* Command index */
  DWORD arg    /* Argument */
)
{
  BYTE n, res;


  if (cmd & 0x80) {  /* ACMD<n> is the command sequense of CMD55-CMD<n> */
    cmd &= 0x7F;
    res = send_cmd(CMD55, 0);
    if (res > 1) return res;
  }

  /* Select the card and wait for ready */
  deselect();
  if (!select()) return 0xFF;

  /* Send command packet */
  xmit_spi(0x40 | cmd);        /* Start + Command index */
  xmit_spi((BYTE)(arg >> 24));    /* Argument[31..24] */
  xmit_spi((BYTE)(arg >> 16));    /* Argument[23..16] */
  xmit_spi((BYTE)(arg >> 8));      /* Argument[15..8] */
  xmit_spi((BYTE)arg);        /* Argument[7..0] */
  n = 0x01;              /* Dummy CRC + Stop */
  if (cmd == CMD0) n = 0x95;      /* Valid CRC for CMD0(0) */
  if (cmd == CMD8) n = 0x87;      /* Valid CRC for CMD8(0x1AA) */
  xmit_spi(n);

  /* Receive command response */
  if (cmd == CMD12) rcvr_spi();    /* Skip a stuff byte when stop reading */
  n = 10;                /* Wait for a valid response in timeout of 10 attempts */
  do
    res = rcvr_spi();
  while ((res & 0x80) && --n);

  return res;      /* Return with the response value */
}

Allerdings gibt send_cmd(CMD0, 0) nach einem Reset nicht 1, nach Vcc 
off/on allerdings doch 1 zurück. Wie ist dieses zu erklären? Das hat ja 
auch nichts mit höheren Ebenen (FAT), sondern mit der Phy-Ebene zu 
tun...

[holger (Gast)]

>Allerdings gibt send_cmd(CMD0, 0) nach einem Reset nicht 1,

Bla, bla.

Häng mal einen Pullup an CS der Karte und einen
Pullup an MISO.

[einGast (Gast)]

wird die Card Select Leitung richtig angesteuert?

[Sven S. (schwerminator)]

holger schrieb:
>>Allerdings gibt send_cmd(CMD0, 0) nach einem Reset nicht 1,
>
> Bla, bla.

Auf solche Antworten kann ich gerne verzichten.

einGast schrieb:
> wird die Card Select Leitung richtig angesteuert?

Ich habe die entscheidende Sektion der Schaltung einmal angehängt. Wieso 
sollte ein Pullup an die /CS-Leitung, diese wird doch direkt von dem µC 
angesteuert?

[Turbo J (Gast)]

Bei meiner änlich aussehenden Variante sieht das mit dem CMD0 so aus:

ty = 0;
ntries = 16; // try CMD0 at least 16 times..
while ((ty == 0) && ntries) {
    if (send_cmd(CMD0, 0) == 1) { /* Enter Idle state */
    ...
  }
  release_spi();
  ntries--;
}

Die Function release_spi() macht nur ein dselect() gefolgt von 8 
Dummy-Clocks, also einem dummy SPI Zyklus.

Die SD Karte will u.U. einfach nur genug Daten via SPI haben, damit sie 
den vor dem Reset eventuell noch angefangenen Befehl abarbeiten kann.

[Sven S. (schwerminator)]

Besten Dank für die Antworten. Ich habe jetzt einen anderen 
Busteilnehmer als Fehlerquelle ausmachen können. Das Problem hat sich 
hiermit erledigt.

Gruß Sven