Prozessor: STM32H7A3
Board: Nucleo-STM32H7A3ZI-Q
IDE: STM32CubeIDE + STM32CubeMX
Ich habe mit CubeMX ein Projekt zur 4Bit-Ansteuerung einer SD-Karte mit
FATFS erzeugt.
Das SD-Karte-Mounten gibt die Fehlermeldung zurück, dass es kein
gültiges FAT-Volumen findet.
Die Low-Level-Routinen funktionieren (zu Anfangs hat es sich beschwert
dass die auch nicht gehen, das konnte ich aber durch das hinzufügen des
MDMA korrigieren).
Alle Leitungen zappeln und die clk-Leitung hat einen konstanten 8
MHz-Takt (ich habe 2^3 als Teiler eingestellt).
Alle Leitungen haben 10k PullUps und zusätzlich habe ich die internen
Widerstände aktiviert. Die Taktflanken sehen sauber aus.
Im Puffer finde ich strings wie „MSDOS5.0“, was definitiv keine
zufällige Zeichenkette ist, sondern von der SD-Karte gelesen wird.
Wenn das Mounten kein FAT-Volumen finden kann, dann die nächste Idee:
Erzeugen wir halt eins.
f_mkfs ( SDPath, FM_FAT32, 0, work, sizeof work);
wird mit “einem Fehler” beendet. Wenn man reindebuggt findet man, dass
die Volumengröße falsch berechnet wird.
Wenn man sich in der ff.c einen BreakPoint in Zeile 5564 stellt und dort
anhält, dann kann man sehen, dass er zu wenige „n_clst“ berechnet.
Wenn man das rückwärts verfolgt, so findet man, dass er den Volume-Size
falsch ausließt.
In Zeile 5356 liest er den MBR und lädt ihn in den Puffer „buff“. Das
klappt auch und man kann dort sehen was im ersten Sektor steht. In
Screen-Shot sieht man, dass dort auch was mit „MSDOS5.0“ steht, der
Hardware-Zugriff auf die Karte klappt also.
Ich habe dann der Karte die Partition gelöscht und jetzt steht da
anderes Kauderwelsch.
Ich denke es ist eine winzige Kleinigkeit die fehlt, aber ich komme
nicht weiter.
Wenn das nicht zum Funktionieren zu kriegen ist muss sich alles
verwerfen und fange nochmal mit der Atmel-Toolchain und einem
Atmel-Prozessor an :-(
Hat schon mal jemand mit dem SDMMC zu kämpfen gehabt?
Viele Grüße!
Marko
Hast du mal eine andere Karte probiert?
Für solche Fälle habe ich mir alte Karten mit 128 MB und 2 GB
aufbewahrt, von denen ich weiß, dass sie zuverlässig funktionieren.
Karten ab 4 GB aufwärts unterstützen oft nicht mehr alle alten
Übertragungsmodi. 32 GB ist die nächste kritische Grenze.
Marko R. schrieb:> In Zeile 5356 liest er den MBR und lädt ihn in den Puffer „buff“. Das> klappt auch und man kann dort sehen was im ersten Sektor steht. In> Screen-Shot sieht man, dass dort auch was mit „MSDOS5.0“ steht, der> Hardware-Zugriff auf die Karte klappt also.
Und das heißt: das ist kein MBR, sondern ein Bootsektor.
Entweder hast du tatsächlich den ersten Sektor des Mediums gelesen, dann
war die Karte als "Superfloppy" organisiert, besaß also überhaupt keine
Partitionstabelle. Bei einer Superfloppy befindet sich an dieser Stelle
kein MBR, sondern der Bootsektor des einzigen Volume auf dem Medium.
Oder das, was du gelesen hast, war nicht der erste Sektor des Mediums,
sondern der erste Sektor einer Partition, also deren Bootsektor.
> Ich habe dann der Karte die Partition gelöscht und jetzt steht da> anderes Kauderwelsch.
Du hast da in Wirklichkeit keine Partition gelöscht (denn es gab ja an
dieser Stelle so oder so gar keine Partitionstabelle), sondern 16 Bytes
des Bootsektors überschrieben. Da es dort recht gedrängt zugeht, ist die
Wahrscheinlichkeit hoch, dass wichtige Daten dabei zerstört wurden, es
also kein Chance mehr gibt, überhaupt noch auf das Filesystem
zuzugreifen, jedenfalls nicht ohne vorherige Reparatur der
Datenstruktur. Dazu wirst du dir wohl anschauen müssen, wie die Struktur
eines Bootsektors aufgebaut ist...
SD Karten sollte man immer mit dem Formatter von SDcard.org formatieren.
Der optimiert die FAT auf die Eigenheiten der SD besser.
Das Formatier-Tool im FatFS könnte verbuggt sein. Schau aber auch mal
nach ob die nicht einfach nur 'ne steinalte FatFS Version mit CubeMX
ausliefern. IIRC kannten alte Versionen einen der valid DOS FAT32
Parition Codes nicht. Neueres FatFS kennt auch ExFAT für >32GB Karten.
Marko R. schrieb:> Das SD-Karte-Mounten gibt die Fehlermeldung zurück, dass es kein> gültiges FAT-Volumen findet.
Den Code sollte man lesen (bzw. im Debugger nachvollziehen) und
nachschauen was im Sektorpuffer von Sektor 0 oder dem Partitions Anfang
so drin steht.
Marko R. schrieb:> SDMMC_HostExample.zip (19,8 MB, 0 Downloads)
Na herzlichen Glückwunsch.
19,9 MB um den Speicherplatz einer SD-Karte auszulesen. :-(
Das mag sich wohl keiner antun.
Forist schrieb:> Na herzlichen Glückwunsch.> 19,9 MB um den Speicherplatz einer SD-Karte auszulesen. :-(
Wenn man es nicht schafft ein Projekt zu cleanen dann schaut
das nun mal so aus .....
So sind sie halt, die Doktores .... ohne Bodenhaftung, schweben
irgendwo zwischen Himmel und Erde.
Ein "clean" Projekt braucht gezippt etwas mehr als ein MByte.
Jim M. schrieb:> nach ob die nicht einfach nur 'ne steinalte FatFS Version mit CubeMX> ausliefern.
Ich habe mal die Versionen der Dateien und Datum gelistet. So furchtbar
alt sieht das gar nicht aus. Aktuell ist die R0.14 vom letzten Jahr. Ich
schau mal ob ich das einfach reinkopieren kann.
ff.c
FatFs - Generic FAT file system module R0.12c
Copyright (C) 2017, ChaN, all right reserved.
diskio.c
Low level disk I/O module skeleton for FatFs (C)ChaN, 2017
Portions COPYRIGHT 2017 STMicroelectronics
Portions Copyright (C) 2017, ChaN, all right reserved
ff_gen_drv.h
Low level disk interface modlue include file (C)ChaN, 2014
syscall.c
Sample code of OS dependent controls for FatFs
(C)ChaN, 2014
Portions COPYRIGHT 2017 STMicroelectronics
Portions Copyright (C) 2014, ChaN, all right reserved
OK, in die Versionen reingeschaut scheint es, als ob ich einfach nur
Pech mit der von MX gelieferten Version R0.12:
R0.12a (July 10, 2016)
Added support for creating exFAT volume with some changes of f_mkfs().
Added a file open method FA_OPEN_APPEND. An f_lseek() following
f_open() is no longer needed.
f_forward() is available regardless of _FS_TINY.
Fixed f_mkfs() creates wrong volume. (appeared at R0.12)
Fixed wrong memory read in create_name(). (appeared at R0.12)
Fixed compilation fails at some configurations, _USE_FASTSEEK and
_USE_FORWARD.
Die Zeile
Fixed f_mkfs() creates wrong volume. (appeared at R0.12)
könnte meine Probleme erklären.
Teste ich morgen aus (habe die Hardware gerade nicht hier)
Vielen Dank für den Hinweis bezüglich der Version, das könnte der
Schlüssel sein.
Marko
Marko R. schrieb:> OK, in die Versionen reingeschaut scheint es, als ob ich einfach nur> Pech mit der von MX gelieferten Version R0.12:
Die wird absichtlich ausgeliefert, denn die Patente für ExFAT sind noch
nicht abgelaufen. Und das wurde ab 12a in Chan FatFS integriert. Aktuell
ist übrigens die R0.14 Version, und oben drauf gibt es noch Patches.
Von ST hab es auch mal Bespiele, die Probleme mit Karten >= 16GB hatten,
das die size intern nur als 32Bit Wert verarbeitet wurde (ab 16GB wurden
aber 64 Bit für die Variable grbraucht.
Mein Doktorand Lukas hat die Lösung gefunden:
Es war ein Timing-Problem, ausgelöst davon, dass die
Compiler-Optimierung auf "Non" stand. Wenn man die auf -Og setzt, dann
tut es generell schon mal, aber noch nicht 100% zuverlässig.
Aus dem Szenario hat er geschlossen dass es wohl Timing Probleme gib.
Deshalb hat er die hardware flow control des SDMMC1 aktiviert. Das
erlaubt clock streching und verhindert einen buffer over/underrun auf
Seiten der SD-Karte und des Controllers:
hsd1.Init.HardwareFlowControl = SDMMC_HARDWARE_FLOW_CONTROL_ENABLE;
Und was soll ich sagen: Womit ich mich tagelang rumgeplagt habe, hat er
in nur 1 Nacht gefunden :-)
Jetzt muss ich nur noch raus finden wo die 2GB-Grenze herkommt.
Mit der lamen 2 GB gehts, eine schnelle V30 Karte mit 32 GB lässt sich
immer noch nicht mounten.
Viele Grüße!
Marko
Bei den F4 gibts das auch, aber da ist die HW FlowControl fehlerhaft und
muss deaktiviert werden. Dann läuft man in das gleiche Problem beim
Pollen, aber es gibt ja einen DMA dafür der das effizienter und
unabhängig von der Compileroptimierung macht.
g.png
(75 KB)
