FatFs SD Keine Antwort

[Matthias (Gast)]

Hallo zusammen

Ich hänge nun seit mehreren langen Tagen dabei eine Speicherkarte an 
einem PIC zu betreiben. Dazu verwende ich die FATFs Lib von ElmChan. 
Benutzt wird ein dsPIC33E. Von der ElmChan Seite habe ich "FatFs sample 
projects for various platforms" das Beispielprogramm PIC24 benutzt und 
dort in der diskio.h die SPI Funktionen ergänzt.
An den SPI Leitungen hängen jeweils ein 10k Pullup.

Problem ist: Speicherkarte reagiert nicht, es passiert nichts.

Micro Speicherkarte funktioniert, da ich diese bereits mit anderen 
"fertigen" SD Modulen betrieben habe. (habe auch eine andere 2te 
Speicherkarte, gleiches Szenario)

Habe mir per Oszi und Debug Codes mal das Programm angeschaut:
-so wie ich das sehe, kommt das Programm NICHT in den IDLE STATE Modus 
in der Funktion DSTATUS disk_initialize() in der Datei diskio.c.

 if(send_cmd(CMD0, 0) ==1) {//enter Idle State}

schlägt immer fehl.

Schaue ich mir die send_cmd() funktion an:
Am Oszi erkenne ich die gesendeten Daten auf der MOSI Leitung welche 
durch die send_cmd() funktion gesendet werden.(siehe bild2). Es kommt 
jedoch keine Antwort seitens der Speicherkarte..

Bild1 zeigt die komplette Datenübertragung, Bild2 reingezoomt die Daten.

Benutzt wird folgender Beispiel Code:

 
if (f_mount(&FatFs, "", 0) == FR_OK) {  /* Mount SD */  
            //"0:" bringt auch nichts            
             writeLCD("MOUNTED ");//kommt hier rein.  

            if (f_open(&Fil, "he2.txt", FA_OPEN_ALWAYS | FA_READ | FA_WRITE) == FR_OK) {  /* Open or create a file */
                writeLCD("OPENED ");//wird NICHT ausgeführt.
                //if ((Fil.fsize != 0) && (f_lseek(&Fil, Fil.fsize) != FR_OK)) goto endSD;  /* Jump to the end of the file */

                f_write(&Fil, "Hello world!\r\n", 14, &bw);  /* Write data to the file */

                //endSD: f_close(&Fil);                /* Close the file */
                f_close(&Fil);
            }
        }

Gebe ich mir jeweils in f_mount und f_open den return FRESULT res an, so 
kommt immer die Meldung 3, welche also für "FR_NOT_READY" steht.
Aber warum?

Meine SPI Funktion sieht folgendermaßen aus:

 
uint8_t ExchangeSPI(uint8_t wert){
    SPI1BUF=wert;
    while(!SPI1STATbits.SPIRBF)// warten bis Werte aus dem Schieberegister rausgeschoben sind
        ;
    return SPI1BUF;
}

Was mache ich falsch bzw was kann ich noch testen/anders machen ?

Bitte um Hilfe..

Vielen Dank
-Matthias

[Jim M. (turboj)]

Da ist was oberfaul...

Meine -funktionierende- SPI-SD Implementation macht vor dem 0x40 
Kommando Byte keine 0xFF bei CS=LOW.

Das macht sie zwar bei alle anderen Kommandos, aber nicht bei 
0x40(CMD0).

IMO schaltet die Karte mit den zwei 0xFF nicht korrekt auf den SPI Modus 
um.

Im oberen Bild sieht man Daten auf MOSI bei CS=HIGH. Seeeehr gefährlich, 
denn im SD Mode (in dem die Karte per default ist) wäre das ein SD 
Kommando.

Hängt da noch was anderes am SPI mit dran? Dann muss die SD Karte 
zwingend zuerst initialisiert werden.

[Matthias (Gast)]

Die 0xFF sind doch die dummy Bytes um in den SPI Modus zu schalten, oder 
nicht?

Es hängen andere Teilnehmer am Bus, diese werden aber in dem Momentanen 
Programm NICHT angesprochen.

[Jim M. (turboj)]

Matthias schrieb:
> Die 0xFF sind doch die dummy Bytes um in den SPI Modus zu schalten, oder
> nicht?

Nein. Die müssen da weg.

Entsprechende Ausschnitt vom Code hier (

static
BYTE send_cmd (
  BYTE cmd,    /* Command byte */
  DWORD arg    /* Argument */
)
{

// [...]

/* Select the card and wait for ready */
  DESELECT();
  rcvr_spi (); // wait 8 clocks LOW
  SELECT();
  if (cmd!= CMD0) {

    xmit_spi(0xFF);xmit_spi(0xFF);
    if (wait_ready() != 0xFF) return 0xFF;
  }

  /* Send command packet */
  xmit_spi(cmd);

Man sieht deutlich das für CMD0 die 0xFF weggelassen werden.

[Matthias (Gast)]

Die beiden 0xFF kommen gar nicht aus dem if (cmd!=CMD0)..
Einer der beiden 0xFF kommt aus dem BYTE select(),( bzw bei dir im Code 
zwischen deselect() und select(), mein code ist etwas anders, aber habs 
auch mit deinem ausschnitt getestet) indem ein DummyClock gesendet wird. 
Das andere 0xFF kommt aus dem wait_ready, in der die For schleife genau 
nur einmal durch läuft und dann abbricht. Die beiden 0xFF konnte ich 
jetzt rauskicken, trotzdem meldet sich die Karte nicht.

Aber was wäre denn ne mögliche Ursache, ich kann ja nicht anfangen die 
ganze LIB abzuändern?

lG

[holger (Gast)]

>Aber was wäre denn ne mögliche Ursache, ich kann ja nicht anfangen die
>ganze LIB abzuändern?

Hat dein PIC einen FIFO für SPI? Dann solltest du den mal abschalten.

[Matthias (Gast)]

Danke. FIFO ist aber ausgeschaltet.:/

[Matthias (Gast)]

Weiß jemand was?

[Patrick B. (p51d)]

Hallo

Ich hatte mich letzten Sommer auch an FatFs die Zähne ausgebissen. Mein 
Problem damals war, dass das mitgelieferte Beispiel irgendwie nicht 
funktionierte und das SPI 16Bit Register hatte.
DMA, Multi-Byte Funktionen etc. habe ich entfernt und entgegen dem 
Beispiel auf den Byte-Funktionszugriff reduziert.

Nach langem suchen und vielen Fehlschlägen bin ich bei der angehängten 
Version gelandet.
Ist sicher nicht die schnellste Lösung, aber es funktioniert und für 
mich zum Konfiguration laden und ab und zu ein Log-Eintrag zu machen 
reicht es völlig aus.

Und die Symptome waren auch immer an einem anderen Ort. Aber 
schlussendlich war es doch die SPI Implementierung.

Musst du halt auf deinen Controller portieren.
Gruss

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Hier wäre noch etwas Code von mir, die SPI Ansteuerung ist dort etwas 
herausgetrennter.
Beitrag "Re: STM32 Chan FAT mit SD karte über SPI"
Der Init der SD Karte entspricht der Beschreibung auf elmchans Webseite.

Irgendwann (tm) wirds auch mal eine IRQ/DMA Lösung geben, aber für 
Konfigs reicht das da auch.
(SDIO ist in Arbeit)