STM32 SDIO Multiblock Write klappt nicht korrekt.

[M. Н. (Gast)]

Hallo,

ich habe aktuell mal weider ein Problem mit meiner SD Karte am 
STM32F407.
Ich nutze FatFS und einen eigenen SDIO Unterbau.

Ich möchte eine Datei auf die SD Karte schreiben. Dazu generiert FatFS 
irgendwann einen Aufruf an mein SDIO Layer, dass 10 Blöcke geschrieben 
werden sollen. Dieser Aufruf schreibt den Inhalt der gewünschten Datei.

Jetzt habe ich das Problem, dass nur der erste und der letzte Block 
korrekt in der Datei stehen. D.h: Die ersten 512 Bytes in meiner Datei 
stimmen, danach kommen nur 0-Bytes und ab dem letzten Block passt wieder 
alles.

Weder CMD13 (SEND_STATUS) noch die Antwort auf CMD12 zeigen irgendwelche 
Fehler der SD-Karte an. Ich habe testweise auch die komplette 
Kommunikation auf 400 kHz herunter geschraubt. Das Verhalten bleibt 
dasselbe.

Es handelt sich hierbei um eine 64 GB SDXC Samsung EVO+ Karte.
Mit einer 8 GB SDHC von Intenso und einer 4 GB SDHC No-Name-Karte kann 
ich das nicht reporduzieren. Hier klappt alles einwandfrei. Auch nach > 
50 Versuchen.
Im Anhang habe ich die beiden Dateien. Es handelt sich hierbei um Base64 
kodierte Daten. In "kaputt.txt" sind zwischendurch einfach NULL-Bytes 
reingerutscht. Es sieht so aus, als ob die Karte diese Blöcke nicht 
geschrieben hätte. Das Busy-Handling der Karte sollte die 
Data-State-Machine des SDIO Moduls ja von sich aus machen. Morgen werde 
ich vermutlich mal den Logic-Analyzer versuchen anzuklemmen.

Mein Ablauf sieht wie folgt aus:
CMD13 Senden und prüfen, ob Karte in Transfer-State, wenn ja:
CMD25 Senden mit Adresse des Sektors

Danach die Datenübetragung des SDIOs:
1) Alle Fehlerflags in SDIO->STA mittels SDIO->ICR löschen
2) SDIO->DLEN = Blockanzahl * 512 Bytes
3) SDIO->DCTRL mit Blockgröße (512 Bytes) und DTEN konfigurieren.

Danach Daten ins FIFO schaufeln.

Abschließend wird ein CMD12 geschickt. Die R1b Antwort von CMD12 zeigt 
keine Auffälligkeit. Ein davor eingefügtes CMD13 leifert auch keine 
Info. Zustand der Karte vor CMD12 ist RCV, so wie es sein soll.

Ich nutze diesen Code nun fast schon 3 Jahre und bisher hat auch alles 
geklappt. Hat jemand eine Idee, woran es liegen könnte?

TX Underrun des FIFOs habe ich auch geprüft: Flag wird nicht gesetzt und 
die Datenrate ist zudem so stark reduziert, dass das FIFO nicht 
unterlaufen kann.

[Jim M. (turboj)]

Meine Glaskugel sagt: Karte zu schnell für den STM32F4, und Du 
erkennst/behandelst den DMA Underrun nicht korrekt.

[M. Н. (Gast)]

Jim M. schrieb:
> Meine Glaskugel sagt: Karte zu schnell für den STM32F4, und Du
> erkennst/behandelst den DMA Underrun nicht korrekt.

Es gibt keinen DMA in diesem Design, aufgrund folgender Thematik:
Beitrag "FatFs + STM32F4 SDIO. DMA Speicheralignment"

Ebenso kann die Karte nicht zu schnell sein. Der STm ist der Master. Es 
kann höchstens das SDIO schneller sein, als man Daten in den FIFO 
bekommt. Das ist allerdings auch ausgeschlossen (siehe Eröffnungspost: 
Flags werden nicht gesetzt. Ebenso ist die Clock auf ~400 KHz 
reduziert.) Wäre es ein Underrun, würde das Phänomen bei allen Karten 
auftreten.

[M. Н. (Gast)]

Jim M. schrieb:
> Karte zu schnell für den STM32F4

Das Problem hat sich nun gelöst. Ich habe mir auf deinen Kommentar hin 
das Ganze nochmals genau angeschaut. Es hat sich herausgestellt, dass 
ich ein wichtiges Fehlerflag weggelesen habe, ohne es zu prüfen. Die 
Karte war zu LANGSAM für den STM. Es kommt das DTIMEOUT Flag.

Eine Erhöhung des Data-Timeouts auf umgerechnet 300 ms schafft Abhilfe.