Ich versuche eine Micro-SD karte an einem STM32 per SDIO anzusprechen. Zunächst mit einem selbst geschusterten Versuchsaufbau aus SD- auf Micro-SD-Adapter an einem STM32F401 Eval-Board von ST. Mittlerweile habe ich ein STM32F4VE mit einem STM32F407VET6 und einem Micro-SD-Slot drauf. Ich habe das Projekt mit CubeMX generiert und in CubeIDE per gcc compiliert. Immer noch ohne Erfolg. Schon der erste Aufruf (f_mount) der SD-Funktionen geht schief. Rückgabewert ist FR_NOT_READY (3) The physical drive cannot work. Die Kommunikation bricht kurz nach dem Hochsetzen des Taktes ab. Ich habe daraufhin den hohen Takt auf 8 MHz gesetzt. Das ändert jedoch nicht wirklich was.
Angehängte Dateien:
-
StmLogger.png
13 KB
Flunder schrieb: > StmLogger.ioc Wenn ich dein IOC-File ernst nehmen darf dann solltest du die gelben Warnschilder deiner Peripherie-Konfiguration ernst nehmen und alle durchschauen welche Konflikte dich behindern. Auf den ersten schnellen Blick gibt es da welche.
Angehängte Dateien:
-
Screenshot1.png
50 KB -
Screenshot2.png
92 KB -
Screenshot3.png
63 KB
Saleae Aufnahmen...
> Schon der erste Aufruf (f_mount) der SD-Funktionen geht schief.
Und was ist mit der Funktion welche deine SD-Karte intialisiert?
Vanye
Gelbe Ausrufezeichen habe ich da eigentlich immer. Wenn ich versuche denen nachzugehen, kommen dann so Dinge heraus wie "mit dieser Konfiguration können sie nicht mehr alle PWM-Ausgänge eines bestimmten Timers nutzen". Egal, ich will ja noch nicht mal den Timer nutzen. Deshalb habe ich das aufgegeben.
Vanye R. schrieb: > Und was ist mit der Funktion welche deine SD-Karte intialisiert? Ups, ich dachte, das wäre f_mount(). Wie ist deren Name ?
Das gelbe Warnzeichen neben SDIO warnt z.B. davor, dass man keine MMC Karten über einen 8 Leitungen breiten Bus mehr anbinden kann.
Flunder schrieb: > Deshalb habe ich das aufgegeben. Beratungsresistenz ist eine Zier, doch weiter kommt man ohne ihr.
Ich habe dafür eine Mbed Komponente gebaut. Es war wichtig DMA zu verwenden weil der Daten FIFO sonst nicht schnell genug geschrieben/gelesen wurde.
Wastl schrieb: > Beratungsresistenz ist eine Zier, doch weiter kommt man ohne ihr. Ganz ruhig bleiben. Wie Du in meiner Antwort über Deinem Beitrag siehst, habe ich doch mal geschaut. Das ich das gelbe Ausrufezeichen nicht versuche zu beseitigen, liegt daran, dass ich mittlerweile sehr lange nach einer MMC suchen müsste und erst recht keinen MMC-Slot zum Einlöten besitze. CubeMX wirft viele dieser gelben Warnungen. Wenn man sich die Schulungsvideos von ST anschaut, sieht man, dass die sogar die pinken Warnzeichen unbeachtet lassen. Es ist halt nun mal so, dass man mit einer endlichen Anzahl Pins nicht alles auf einmal hinbekommt.
Guck dir doch mal die Library von Uwe B. an: https://mikrocontroller.bplaced.net/wordpress/?page_id=144 Projekt 13. Benutzt FatFS von Elm-Chan. Ich habe das mit gutem Erfolg auch in mein Projekt mit STM32F429 eingebunden.
:
Bearbeitet durch User
Alternativ dazu: https://github.com/ukw100/STECCY Hier wird ein STM32F407VET6 Board verwendet, also dasselbe wie beim TO. * src/sdcard: SD-Karten-Support * src/fatfs Port von fatfs * src/fs-stdio Anbindung an stdio-Bibliothek - falls gewünscht.
:
Bearbeitet durch Moderator
Matthias S. schrieb: > Guck dir doch mal die Library von Uwe B. an: > https://mikrocontroller.bplaced.net/wordpress/?page_id=144 > > Projekt 13. Benutzt FatFS von Elm-Chan. > > Ich habe das mit gutem Erfolg auch in mein Projekt mit STM32F429 > eingebunden. Nachdem ich das Beispiel von der alten Ide auf die Cube Ide umgesetzt hatte, lief es auf Anhieb. Jetzt bin ich am grübeln, ob der generierte Code von Cube MX einfach Mist ist oder ob ich was konfiguriert habe, das so nicht funktionieren kann. Dafür gibt es allerdings keine Warnungen. Und ja, es gibt auch sinnvolle Warnungen in Cube MX. Mir fällt da z.B. der Clock Konfigurator ein. Wenn da ein Feld pink hinterlegt ist, muss man wirklich noch ein wenig an den Faktoren schrauben, damit die PLL einrastet und jeder auch nur so schnell getaktet wird, wie er kann. Sowas habe ich im FAT Fs allerdings nicht gesehen. Jetzt überlege ich, wie ich weiter mache. Ein Vergleich der Ausgaben des SDIO-Analyzers im Logic Analyzer beider Programme gegeneinander sagt mir wenig, da ich die Kommandos und ihre Argumente, die da über die Schnittstelle huschen, nicht kenne. Ein Update des Elm Chan Codes von 0.9b auf das aktuelle 0.15 ist auch nicht so einfach. Da hat sich doch einiges getan in den Jahren. Auf der anderen Seite, weiß ich nicht, ob ich jetzt den funktionierenden Code in die Ausgabe von Cube MX einpflanze und von wem ich die SDIO Ansteuerung nehme. Die Vorgehensweise hätte den Vorteil, dass ich weitere Änderungen in Cube MX hinklicken könnte. Oder lieber versuchen, den Code von Cube MX für sonstige Peripherie in das Beispiel zu übernehmen ?
Flunder schrieb: > Nachdem ich das Beispiel von der alten Ide auf die Cube Ide umgesetzt > hatte, lief es auf Anhieb. > > Jetzt bin ich am grübeln, ob der generierte Code von Cube MX einfach > Mist ist oder ob ich was konfiguriert habe, das so nicht funktionieren > kann. Dafür gibt es allerdings keine Warnungen. Du hast zwei Quellcodes und den selben Controller / das selbe Board zu Verfügung? Dann guckt man einfach nach Unterschieden zwischen den Quellcodes.
Flunder schrieb: > Nachdem ich das Beispiel von der alten Ide auf die Cube Ide umgesetzt > hatte, lief es auf Anhieb. Ja, das ist der Haken, das Uwe damals alles mit Coocox gemacht hatte. Ich habe das aber ohne grosse Probleme auch in Atollic mit SPL einpflanzen können - bisher habe ich mich um Cube MX immer rumdrücken können. Ich finde es vorteilhaft, wenn da niemand im Hintergrund an meinem Code rumwurschtelt, aber das möge jeder so machen, wie er möchte.
:
Bearbeitet durch User
Matthias S. schrieb: > bisher habe ich mich um Cube MX immer rumdrücken > können. Ich finde es vorteilhaft, wenn da niemand im Hintergrund an > meinem Code rumwurschtelt Da hast du offensichtlich noch eine kleine Bildungslücke. Wenn man es richtig macht "wurschtelt" da niemand im Hintergrund am eigenen Code herum. Man kann locker ein ganzes (existierendes) Projekt neu generieren ohne dass der Codegenerator am eigenen Code was verändert. Hilfreich dabei ist sich für jedes Peripherie- Element ein Paar von *.c/*.h Dateien generieren zu lassen. So behält man besser den Überblick. Matthias S. schrieb: > Ich habe das aber ohne grosse Probleme auch in Atollic mit SPL > einpflanzen können Man muss nur einmal den Sprung schaffen von SPL auf LL Code umzusteigen. Programmieren mit LL ist für mich die ideale Kombination mit CubeMX das Grundprogram zu generieren und darauf aufbauend die LL als Basis fürs eigene Programmieren ohne HAL zu verwenden.
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.