FATFS und SDIO, Verzeichnisproblem

[J. -. (Gast)]

Hallo FATFS-Fans,

seit ein paar Jahren habe ich mit der Anwendung von FATFS auf SDIO ein 
kleines Problem. Es geht um die Verzeichnisebene. Nehmen wir z.B. eine 
MP3-Sammlung, man geht vom root-Verzeichnis nach 'MP3', dann nach 
'MP3/Deep Purple' etc. und schaut sich die LFN an. Dann passiert es bei 
manchen Ordnern schon in der zweiten Verzeichniseben (also wenn man in 
'MP3/Deep Purple' ist), daß im Ordner 'Deep Purple' die Dateinamen nur 
noch Grütze anzeigen. Grütze bedeutet kryptische Sonderzeichen, so 
zwischen 5-10 chars lang, die überhaupt keine Beziehung mehr zu echten 
LFNs haben.
Also ersten stimmen die LFN nicht. Zweitens die Attribute, und drittens 
die Filesize, und viertens auch nicht die Zahl der Ordner und Files in 
dem Ordner 'Live'. Es sind konkret 41, während FATFS 48 anzeigt. Wobei 
auch die Zahl der Ordner und die Zahl der Files (ohne AM_DIR-Attribut) 
nicht übereinstimmt.

Nun könnte man sagen, ja Doofi, da hast Du beim SDIO-Treiber Mist 
gebaut. Kann auch sein, nur ist der geklaut vom MCD-Team, die Library 
ist von Tilen MaJerle 
(http://stm32f4-discovery.net/2014/07/library-21-read-sd-card-fatfs-stm32f4xx-devices/) 
und nur geringfügig modifiziert.
Der Witz ist auch (das habe ich heute nach längerer 'Analyse' 
herausgefunden), daß nur die alphabetisch jeweils ersten Ordner 
betroffen sind. Wenn man vom root ausgehend also bei den Ordnern mit 
Anfangsbuchstabe A in deren nächste Verzeichnisebene geht, ist alles in 
Ordnung, man kann beliebig viele Ebenen tiefer gehen. Aber ab 
Anfangsbuchstabe D z.B. geht's los, daß nichts mehr stimmt. Es hängt 
jetzt aber nicht konkret vom Buchstaben D ab, sondern wieviel Ordner 
insgesamt enthalten sind, oder wie halt die FAT32 organisiert ist, oder 
noch von anderen Parametern, die aber nicht so leicht zu lokalisieren 
sind.

Noch zur Info, ich habe das Problem bei allen Karten, ob FAT16, FAT32, 
oder ExtFat formatiert. Auch unabhängig von der Kapazität, und von der 
SDIO-Taktfrequenz, Board, CPU (F103RCT,F103VET, F407,F429). Ich benutze 
die StandardPeripheralLibrary und habe eigentlich keinen Bock, das mit 
HAL zu testen... In ff_conf war ich auch zugange, habe extFAT 
abgeschalten, relative Pfade ein/ausgeschalten, Zusatzfunktionen 
abgeknipst und variiert - no change. Es ändert sich dadurch nichts an 
der Fehlfunktion. Auch die neue LBA-Funktion, bei der die Sektoren in 
QWORDS statt DWORDS gerechnet werden (ich glaube seit FATFS12), habe ich 
nochmal zurückgespult und die disk_ioctl, disk_read und disk_write 
entsprechend angepaßt. Nix. Es hängt auch nicht von der MP3-Sammlung ab, 
sondern ist ein allgemeines Unterverzeichnisproblem bei SDIO ;-)

Mit dem gleichen Filesystem (FATFS14, aktuell, aber es ist bei früheren 
Versionen genauso) betreibe ich neben der SDIO-Karte auch noch eine 
SPI-Karte und eine SPI-FlashDisk (25Q32, davon 4MByte mit FATFS 
genutzt). Auf den SPI-getriebenen 'Karten' funktioniert das alles 
reibungslos. Ich kann auch die Karte aus dem SPI-Slot in den SDIO-Slot 
stecken und folglich die gleiche Karte mit dem gleichen Filesystem und 
dem gleichen FATFS testen, Ergebnis: Am SPI-Slot alles ok, und beim SDIO 
eben die o. a. Probleme, da kann man ein paar Folder im ersten 
Unterverzeichnis anschauen, ein paar sind völlig verhunzt.

Kapier ich nicht. Ist in den Treibern vom MCD-Team die Verzeichnistiefe 
oder die Clusterwurschtelei vermurkst, und keiner hat das bisher 
beobachtet? Ich hatte bisher auch nicht nur stur die Library von Tilen 
benutzt, sondern auch die vom alten Eval-Board abgestrippt (bevor Tilen 
seine Lib veröffentlichte) und da war es genauso. Deutet also einiges 
auf die SDIO-Treiber vom MCD-Team hin, aber das wäre doch schon mal 
berichtet worden ... es betrifft ja schon die erste 
Unterverzeichnisebene.
(Ich habe 3 Fotos angehängt, der lange Text ist damit redundant. Drive 
0: ist SPI, Drive 2: SDIO, gleiche Karte. Das Root-Verzeichnis und /MP3 
wird bei beiden (SPI und SDIO) noch gleich angezeigt.)


Ist kein tragisches Problem, ich will auch keine Lösung. Wenn es drauf 
ankommt, kann man ja die SPI-Treiber nehmen. Wäre aber hilfreich, wenn 
das Beobachtete hier bestätigt oder widerlegt würde. Da kann man sich 
das Grübeln vielleicht sparen (so fit bin ich in FAT und den SDIO-cmds 
sowieso nicht, daß ich das in vertretbarer Zeit deduktiv knacken kann).

[fop (Gast)]

Wenn ich mich recht erinnere, belegen die Verzeichnisse von Unterordnern 
bei FAT Cluster des Datenbereichs. Vermutlich hat das Betriebssystem, 
mit dem Du die Daten auf die SD kopiert hast, die Unterverzeichnisse in 
alphabetischer Reihenfolge angelegt und befüllt. Dadurch liegt das 
Verzeichnis für ZZ-Top in einem Cluster sehr weit hinten auf der SD, da 
ja vorher noch die Daten Deiner ganzen Lieblingshits von ABBA etc. 
stehen.
Kann es sein, dass Du durch z.B. einen Überlauf den falschen Cluster 
liest, wenn ein Cluster vom Ende der SD angefordert wird ?

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

SPI und SDIO Treiber wissen nix von Unterverzeichnissen, die lesen und 
schreiben nur Blöcke.
Die Logik hat das fatfs und fordert diese Blöcke an.

Um zu wissen wo der SDIO Pfad falsch abbiegt musst du mal beim Block 
lesen callback des fatfs mitschneiden welche Basisadresse und welche 
Länge er will.
Das muss bei SPI und SDIO ja gleich sein wenn du imemr die gleichen 
Operationen auf der GUI ausführst.

Gucken wir doch erstmal obs dort schon unterschiede gibt und dann noch 
den INhalt loggen ind vergleichen.

Läuft SDIO in 1 oder 4 Bit?
Welche Frequenz?
Schalte den SDIO doch mal auf 1MHz.
GPIO sind richtig für SDIO eingestellt?
Der RX DMA hat eine hohe Prio und kann von keinem anderen DMA Transfer 
gestört werden?

[J. -. (Gast)]

fop schrieb:
> Kann es sein, dass Du durch z.B. einen Überlauf den falschen Cluster
> liest, wenn ein Cluster vom Ende der SD angefordert wird ?
An sowas hatte ich mit Grausen auch gedacht. Was Windows beim Kopieren 
anstellt und in welcher Reihenfolge Ordner und Dateien nachher unter 
FATFS erscheinen, hat mich schon früher dazu gebracht, in FATFS die 
DIR-cluster auszulesen und in ein Indexarray(uint16_t) zu speichern. 
Dieser Index kann sortiert werden nach Datum, Name und Dateigröße.
Aber das ändert nichts daran, wie der Kopiervorgang stattfindet, da 
liegst Du wahrscheinlich richtig, daß Windows schon ein wenig auf's 
Alphabet schaut und von daher die Annahme, daß ZZ-Top bei großen 
Cluster- oder Sektorenwerten zu finden ist. Sieht man unter Windows 
selbst ja nicht ;-)

Mw E. schrieb:
> Um zu wissen wo der SDIO Pfad falsch abbiegt musst du mal beim Block
> lesen callback des fatfs mitschneiden welche Basisadresse und welche
> Länge er will.
> Das muss bei SPI und SDIO ja gleich sein wenn du imemr die gleichen
> Operationen auf der GUI ausführst.
Gute Idee, das Loggen hätte ich in der diskio bzw. den entsprechenden 
disk_read-Routinen machen können und hätte mir die Clusterdifferenzen 
VIELLEICHT angezeigt.


VIELLEICHT deshalb großgeschrieben, denn das Problem hat sich 
tatsächlich mit so einer size-Geschichte aufgelöst. Nach Jahren. Ich 
weiß nur noch, daß ich vor kurzem zuletzt bei einem mir noch unbekannten 
STM32F103RCT zähneknirschend und nach Wochen dieses Sektorenproblem 
(DWORD vs. QWORD) als Ursache ausfindig machte, warum der SDIO-Treiber 
nichts liefert. Da ging aber gar nichts ohne diese Korrektur, da war 
alles Müll und die Karte konnte nicht gemountet werden.
Und .. ich hatte gedacht, daß ich die F4-Treiber auch alle aktualisiert 
hätte ... hatte ich aber nicht, sondern nur in den FATFS-Funktionen ;-))
Oh Shit, und das geht jetzt. Verzeichnis unter SDIO ist in Ordnung. 
Schon ein bißchen peinlich, und ich hätte es auch nicht gedacht, weil 
ich den Schritt m.E. schonmal vorwärts und rückwärts gemacht hatte.

Komisch aber dennoch, daß es bei bei den SPI-Treibern ja ebenfalls noch 
DWORDS anstatt QWORDS bei den Sektoren waren, und diese funktioniert 
hatten. Kapiere ich nicht, kann aber gut sein, daß es da bei den 
internen Umrechungen in den beiden Treibern Unterschiede gibt.

Anyhow, gut, daß ich's mal hier aufgeschrieben hatte g und euch beiden 
danke für die Hilfestellung.
Hätte ich selbst nicht gedacht, daß es so einfach sein könnte (und war 
wirklich überzeugt, daß es was ganz Schlimmes ist, wo man sich tief in 
die FAT, FATFS, DMA und SDIO-Eingeweide vorwurschteln muß).
Jetzt muß ich nur noch mal kucken, ob es beim STM32F103 tatsächlich 
schon funktionierte und ich diesen speziellen Punkt mit den 
Verzeichnissen nach der letzten Änderung gar nicht mehr geprüft hatte. 
Der müßte ja eigentlich doch auch funktionieren.