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
Angehängte Dateien:
-
g.png
75 KB
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.
Hier nochmal das gecleante Projekt, nur noch 1 MB groß. Danke für den Hinweis.
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
:
Bearbeitet durch User
Beitrag #6365451 wurde vom Autor gelöscht.
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.
Einer der vielen Gründe den CubeMX+HAL nicht zu nutzen!
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.
Im CubeMX habe ich angegeben dass er den DMA nutzen soll. Ich schau mir das nochmal an.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.