F_Mount /FATFS / STM32F401RE

[FATHM (Gast)]

Hallo,

folgendes Problem beschäftigt mich seit kurzem:

Ich bekommen Daten über UART1 und Interrupt des F401RE rein, speichere 
diese in einem Buffer und möchte dessen Inhalt auf eine µSD-Karte 2GB 
Class 4  speichern.
Die HW lass ich mir mittels CubeMX erstellen.

Dazu folgenden Code, der auch funktioniert:

while(1)
{
fresult1=f_mount(&myFATAFS,SDPath,1) ;
      
 if(fresult1==FR_OK)
        {
         
        char MyPath[]="testfile.TXT";
        char MyData[]="Wieder ein Test.";
        f_open(&myFILE,MyPath,FA_WRITE|FA_CREATE_ALWAYS);
        f_write(&myFILE,MyData,sizeof(MyData),&testByte);
        f_close(&myFILE);
        f_mount(&myFATAFS,SDPath,0);
}
}

-> Funktioniert, Datei und Inhalt können z.B. am PC gelesen werden.

{
if(received)
    { fresult1=f_mount(&myFATAFS,SDPath,1) ;
       if(fresult1==FR_OK)
        {
         
        char MyPath[]="testfile.TXT";
        char MyData[]="Wieder ein Test.";
        f_open(&myFILE,MyPath,FA_WRITE|FA_CREATE_ALWAYS);
        f_write(&myFILE,MyData,sizeof(MyData),&testByte);
        f_close(&myFILE);
        f_mount(&myFATAFS,SDPath,0);
     }
   received=0;
}

-> funktioniert nicht. Der Code bleibt bei f_mount stehen. Nichts geht 
mehr.

Was genau übersehe ich? Hat jemand Lösungen für dieses Problem?

[Mod: Fehlendes C-Tag eingefügt]

[Falk B. (falk)]

Warum hast du das Mount in der while(1) Schleife? Das macht man einmal 
am Programmanfang und dann nie wieder. Damit die Daten komplett 
geschrieben werden reicht das f_close(), das schreibt alle Restdaten aus 
dem Puffer in die Datei.

[Εrnst B. (ernst)]

FATHM schrieb:
> Ich bekommen Daten über UART1 und Interrupt des F401RE rein, speichere
> diese in einem Buffer

Du hast dein f_mount &co aber schon im Haupt-Programm, nicht in der ISR?
Wird aus deinem Beispiel-Code nicht ersichtlich...

[FATHM (Gast)]

Danke für die schnelle Antworten.

>Du hast dein f_mount &co aber schon im Haupt-Programm, nicht in der ISR?
>Wird aus deinem Beispiel-Code nicht ersichtlich...


Ja, das ist mein Hauptprogramm, nicht die ISR. In der ISR wird nur die 
globale variable receive = 1  gesetzt.

>Warum hast du das Mount in der while(1) Schleife? Das macht man einmal
>am Programmanfang und dann nie wieder. Damit die Daten komplett
>geschrieben werden reicht das f_close(), das schreibt alle Restdaten aus
>dem Puffer in die Datei.

Danke für den Tipp. Ich habe nun das f_mount vorher initialisiert. Jetzt 
hängt sich das Programm im f_open auf. Also eine Zeile weiter. :(

[Falk B. (falk)]

@ FATHM (Gast)

>Danke für den Tipp. Ich habe nun das f_mount vorher initialisiert.

Hast du auch dessen Rückgabewert geprüft?

http://elm-chan.org/fsw/ff/doc/mount.html

[FATHM (Gast)]

>Hast du auch dessen Rückgabewert geprüft?

Der Rückgabewert lautet FR_OK. Wenn die Karte nicht im Slot steckt: 
FR_NOT_READY

[Johannes S. (Gast)]

Wie ist die SD angeschlossen? Per SDIO hatte ich auch gerade das Problem 
das der HAL Code im Pollingmode zu langsam ist, besonders im debug build 
ohne Optimierungen. Das führte zuverlässig zu Fehlern bei der 
Datenübertragung. Mit DMA sieht es besser aus und es läuft mit 24 MHz 
SDIO Clock.

[FATHM (Gast)]

>Wie ist die SD angeschlossen? Per SDIO hatte ich auch gerade das Problem
>das der HAL Code im Pollingmode zu langsam ist, besonders im debug build
>ohne Optimierungen. Das führte zuverlässig zu Fehlern bei der
>Datenübertragung. Mit DMA sieht es besser aus und es läuft mit 24 MHz
>SDIO Clock.

Ich nutze SDIO 1Bit. Somit sind CMD, D0 und CLK an der Karte 
angeschlossen + 3,3V und gemeinsame Masse aufgebaut auf einer 
Lochrasterplatine.

Ich habe das Problem, dass das gesamte Programm abschmirrt.

[Frank M. (ukw) (Moderator)]

FATHM schrieb:
> funktioniert nicht. Der Code bleibt bei f_mount stehen.

Wenn Dein Testcode ohne ISR funktioniert und der identische Code mit 
ISR nicht, dann muss es an dem Code liegen, den Du nicht gepostet 
hast.

[Falk B. (falk)]

Kann es sein, daß die Interruptfunktion für das Timeout fehlt? Dann 
bleibt der Zugriff natürlich stehen . . .

[kyrk.5 (Gast)]

Hallo,

was heißt genau: abschmirrt

Kannst du mit dem debugger stop machen? Ist der Context dann ok? Wo bist 
du? While schleife oder interrupt? Sind die Variablen die du da hast 
noch ok? Kommen noch irgendwelche interrupts durch? Timer?

Versuche mal den f_mount zu debuggen. Wie lange kommst du noch durch? 
Ist nicht so schwer, ich habe den auch paar mar gedebugt nach paar Tagen 
geht es wie geschmiert.

[Falk B. (falk)]

@ kyrk.5 (Gast)

>Versuche mal den f_mount zu debuggen. Wie lange kommst du noch durch?
>Ist nicht so schwer, ich habe den auch paar mar gedebugt nach paar Tagen
>geht es wie geschmiert.

Genau sooo macht man es bestimmt nicht. FATfs ist sehr gut getestet, da 
muß man nicht in den Innereien rumdebuggen. Man sollte einfach die 
Rückgabewerte auswerten und ernst nehmen. Einzig und allein die Low 
Level Funktionen, die man an die Hardware selber anpassen muß sind 
debugwürdig.

[FATHM (Gast)]

>Kann es sein, daß die Interruptfunktion für das Timeout fehlt? Dann
>bleibt der Zugriff natürlich stehen . . .

Tut mir leid Falk, aber das habe ich nicht verstanden. Könntest du mir 
das genauer erklären, bzw. eine Quelle nennen wo ich die Hintergründe 
genauer nachlesen könnte?

[kyrk.5 (Gast)]

Ich habe das genau so gemacht und festgestellt dass es bei mir damals an 
der Low Level Funktion gelegen hat. Wobei bei mir war ein Delay Funktion 
nicht richtig integriert wurde und deswegen nie zu Ende lief. Dadurch 
gab es keinen Rückgabewert. Dann hatte ich noch ewig probleme mit nicht 
laufenden SD Karten, weil der SPI nicht dediziert war und ein MP3 chip 
hing da auch drauf. Die SD Karte nahm das aber über, weil er ja in SDIO 
mode hochstartet und wenn da erst der MP3 chip initializiest wird nehmen 
das manche karten nicht so gut an (sprich denken die werden gerade 
angesprochen)

Aber prinzipiell hast du recht. Erstmal Doku lesen und so machen wie es 
da drin steht. Wenn aber immer noch nicht tut dann muss man einfach 
reindebuggen. Die 2 Dinge helfen in 80% der Fällen.

[Johannes S. (Gast)]

in der hsd Struktur ist noch ein Member 'ErrorCode', das ist der letzte 
Fehler vom LL Treiber. Die Bedeutungen sind in stm32f4xx_ll_sdmmc.h zu 
finden.

[Falk B. (falk)]

@ FATHM (Gast)

>>Kann es sein, daß die Interruptfunktion für das Timeout fehlt? Dann
>>bleibt der Zugriff natürlich stehen . . .

>Tut mir leid Falk, aber das habe ich nicht verstanden. Könntest du mir
>das genauer erklären, bzw. eine Quelle nennen wo ich die Hintergründe
>genauer nachlesen könnte?

Für FATfs muss im 10ms Zeitraster eine kleine Funktion aufgerufen 
werden, welche die Timeouts regelt. Die liegt im avr Beispiel in

mmc_avr_spi.c

/*-----------------------------------------------------------------------*/
/* Device Timer Interrupt Procedure                                      */
/*-----------------------------------------------------------------------*/
/* This function must be called in period of 10ms                        */

void mmc_disk_timerproc (void)
{

[Jim M. (turboj)]

FATHM schrieb:
> eine µSD-Karte 2GB
> Class 4  speichern.

Hast Du mal eine andere SD(HC) Karte probiert? Die billigen 2GB Class 4 
sind mitunter ab Werk defekt beim Kunden angekommen.

Das mit dem Timeout hilft Dir auch kaum weiter, denn wenn der zuschlägt 
kannste die Karte nur durch Unterbrechen der Stromversorgung resetten.

Im Normalbetrieb sollte kein Timeout auftreten - dann ist immer 
irgendwas nicht OK.

[Johannes S. (Gast)]

für die Timeouts nutzt die HAL Implementierung den SysTick, das wird 
alles im generierten Code vom Zauberwürfel gemacht.
In main.c ist noch eine leere Fehlerbehandlung:

void _Error_Handler(char *file, int line)
  /* USER CODE BEGIN Error_Handler_Debug */
  /* User can add his own implementation to report the HAL error return state */
  while(1)
  {
  }
  /* USER CODE END Error_Handler_Debug */

da wäre ein printf() mit Fehlerausgabe auf Display oder UART hilfreich. 
Oder wenigstens hektisches LED blinken damit man sieht der µC hängt in 
der Fehlerschleife.
Aber wie Uwe schon schrieb, wenn der nahezu gleich Code schon lief 
müssen noch woanders Änderungen sein.
Fehlerträchtig ist auch das Konzept mit den __weak Deklarationen das mit 
HAL viel genutzt wird. Ich hatte Interrupthandler und Callbacks in eine 
C++ Quelle verschoben und schon wurde es wegen C++ name mangling nicht 
mehr aufgerufen, der Compiler kann da aber nichts prüfen und dem Linker 
ist es egal ob eine __weak Funktion überschrieben wird oder nicht.