Ich reengineere gerade ein Handheld Messgerät mit STM32F429 und möchte nun den SD Slot (MicroSD) zum laufen bringen. Dabei zeigt sich, das die Jungs den Detect Kontakt nicht angeschlossen haben und auch Dat3/CD über einen externen Pullup sozusagen lahmgelegt haben. Ansonsten ist der Slot sauber mit den passenden AF Pins des STM32 im 4-Bit Modus verbunden. Wie kann man dann eine eingelegte Karte erkennen? Gibt es ein unverfängliches Kommando, das man an die Karte schicken kann und mir nicht den MC blockiert? Zieht eine SD Karte mögl. einen Pin auf low beim Einlegen? Nachfädeln würde ich den Detect Pin nur dann, wenn es unbedingt nötig wäre, bisher läuft die Software ohne jegliche Hardware Änderung auf der Kiste.
Hallo, ich habe damit Jahre lang Probleme gehabt. :) Habe den Microchip SD Karten Stack verwendet und die Methode aus dem genommen. Prinzipiell versuchen die die Karte anzusprechen, und wenn etwas sinnvolles kommt dann ist es ok. Wenn nicht dann wird initialisiert. Danach muss man nur ab und zu gucken ob die Karte immer noch da ist. Was ich dabei gelernt habe ist: - SD Karte muss als erstes am SPI bus initialisiert werden. Solange der nicht in SPI mode ist kann es zu Problemen kommen wenn da ein anderer Teilnehmer am Bus schon kommuniziert. Wie in meinem Fall ein MP3 decoder... - Daher am besten den SD Karte einen eigenen SPI bus geben. Wenn das nicht geht dann im SW dafür sorgen dass die Karte erstmals detektiert wird, dann initialisiert und nur dann andere Teilnehmer ansprechen. - Microchip hat damals vieles synchron implementiert. Das muss man leider asynchron machen, denn die Karte braucht ab und zu mal länger. Prinzipiell tut der Code von Microchip, ich habe nur kleinere Anpassungen für mich selbst gemacht (AES reingemacht um Karte zu verschlüsseln). - Am besten die SD Karte ein und ausschaltbar machen, denn der Microchip stack hat ein Zweig wo als Kommentar steht, ab hier geht es nur mit power on off weiter. Ich würde raten alle Leitungen zu trennen außer GND, sonst könnte die Karte über die Datenleitungen quer versorgt werden. Zum Glück bin ich noch nie in diesem Zweig gelandet. Aber jede Karte ist hallt bisschen anders...
Vielen Dank für deine Antwort. Benutzt Microchip dann die Karte weiterhin im SPI Modus oder schalten sie um auf SDIO? Es wäre sicher möglich, auf die Pins per Bitbanging SPI zu machen (der STM32 hat keinen passenden SPI Hardware Modus auf den benutzten Pins)? Die Karte dann aber komplett nur noch per SPI zu betreiben, würde ich allerdings gerne vermeiden, weil das Bitbanging dann sehr lästig wird und SDIO 4-bit ja schon verdrahtet ist. TippsUndTricks schrieb: > Am besten die SD Karte ein und ausschaltbar machen Das ist hier praktisch unmöglich, weil das nur mit schweren Eingriffen in die Hardware gehen würde.
:
Bearbeitet durch User
Ach so. Du bist ja mit SDIO unterwegs. Da habe ich leider wenig Erfahrung damit, weil als ich SDIO auf Bitbang weise probiert habe, war es leider nicht schneller. Na ja wegen Bitbang.... Aber in bestimmte weise wird es ja deswegen einfacher. Du hast ja dedizierte PINs und HW richtung SD Karte. Ich vermute mal auf den SDIO hast du nur die einen einzige SD Karte und nix anderes. Also alles was richtung SD Karte auf SPI umstellen geht kann man vergessen. Kannst ja weiterhin in SDIO modus bleiben. Damit würde eine Detektierung grob so aussehen (ohne Gewähr, nur basierend auf meine SPI Erfahrungen würde ich es so angehen): - Erstmal gucken ob du schon eine Karte detektiert und inizialisiert hast, wenn ja dann nur CMD13 senden und auf den Antwort gucken ob es stimmt. Wenn ja dann ist die Karte weiterhin noch da, wenn nicht dann ist die Karte wohl ausgesteckt. Könnte auch eine andere Karte sein der sehr schnell aus und wieder eingesteckt wurde. - Wenn keine Karte da ist, dann versuchen zu initialisieren. Wenn es klappt, sprich die Antworten sind ok dann ist die Karte da. Kurz zusammenfasst, Detektierung geht hier auch über Kommandos schicken und gucken ob da etwas sinnvolles zurückkommt.
Matthias S. schrieb: > Wie kann man dann eine eingelegte Karte erkennen? Antesten, ob sie auf die Initialisierungs-Sequenz antwortet.
Ich werde mich da später nochmal ransetzen, wenns pressiert. Wenn ich die Initialisierung der SDIO Hardware mit dem MSC Paket mache, hängt der MC jedenfalls in einer Endlosschleife. Da allerdings der USB Host schon gut mit Speichersticks läuft, ist der Druck nicht ganz so gross, SD sofort einzubauen, zumal der Kartenslot so tief im Gerät liegt, das man sich beim Ziehen der Karte die Fingernägel abbricht. Vielen Dank für die Tipps!
Matthias S. schrieb: > Benutzt Microchip dann die Karte weiterhin im SPI Modus oder schalten > sie um auf SDIO? SD Karten starten im 1 Bit SDIO Modus. TippsUndTricks hat ja geschrieben, dass man die SD Karte zuerst in den SD Modus packen muss bevor man andere Geräte am selben SPI Bus anspricht. Also WENN man si im SPI Modus betreiben will mit anderen SPI Geräten. In den SPI Modus packen geht durch das Senden von CMD0 und dabei CS Low halten. Im SDIO Slot sind nämlich fast alle Pins mit einem Pullup versehen. Aber das ist bei dir ja nicht der Fall. Aber genau diesen CMD0 kannste auch nutzen zum Karten detektieren. Wenn da auch wiederholt keine Antwort kommt, dann ist da keine Karte. Da der STM32 eine eigene SDIO HW mit Statemachine hat kannste das auch asynchron abfrühstücken. Also zB sekündlich gucken ob mal wer eine Karte reingesteckt hat.
Matthias S. schrieb: > Gibt es ein unverfängliches Kommando, das man an die Karte schicken kann > und mir nicht den MC blockiert? Wie schon geschrieben: Initialisierung durchführen. Der Stack von st ist übrigens bestenfalls als Proof of concept zu verstehen. Das Ding hängt sich bei jedem Fehler auf. Da hab ich einige Zeit mit verbracht und die ganzen Endlosschleifen mit timeouts versehen. Vermutlich wäre es schneller gegangen das einfach neu zu implementieren was ich tatsächlich gebraucht habe.
Auch Karl, ein anderer schrieb: > Der Stack von st ist > übrigens bestenfalls als Proof of concept zu verstehen. So ziemlich der ganze HAL ist ein abschreckendes proof of concept ;)
Auch Karl, ein anderer schrieb: > Da hab ich einige Zeit mit verbracht und die > ganzen Endlosschleifen mit timeouts versehen. da habe ich auch mal bemängelt das Timeout 0 nicht infinite ist sondern sofort einen timeout meldet ohne etwas auszuführen. Das sollte aber so sein by Design.
Auch Karl, ein anderer schrieb: > Das Ding hängt > sich bei jedem Fehler auf. Da hab ich einige Zeit mit verbracht und die > ganzen Endlosschleifen mit timeouts versehen. Bei Microchip sieht das ähnlich aus :) Wobei wohl bemerkt, ich habe den Stack noch vor der Harmony Zeit als Basis genommen. Wollte das mit dem Harmony mir nicht antun. AUTOSAR mit sein Tooling reicht schon. Harmony ist bisschen ähnlich mit dem Clicken und generieren und tut net.... Tcha, leider muss man die Stacks immer bisschen aufbessern. Sonst gibt es da Probleme und es wird einfach nicht Kunden-tauglich werden. Ich frage mich wie kann es sein, dass so viele Arduino Projekte angeblich ohne Probleme laufen. Und SD Karten immer so einfach zu bedienen sind. Und ich habe da immer Probleme. SDIO ist doch kostenpflichtig, oder? Also die Specification war irgendwie zeitweise geheim. Hat sich das geändert? Ich weiss dass es irgendwie doch geleaked war, und es gab auch verschiedene implementierungen. Darf man aber prinzipiell SDIO in ein Kommerzielles Produkt einbauen und verkaufen?
TippsUndTricks schrieb: > Und SD Karten immer so einfach zu bedienen sind. > Und ich habe da immer Probleme. Ich habe mit den Dingern sogar in kommerziellen fertigen Geräten andauernd Probleme - außer in Smartphones.
Mw E. schrieb: > So ziemlich der ganze HAL ist ein abschreckendes proof of concept ;) Ja nee, mit HAL wird hier nichts gemacht. Ich bin evtl. etwas altmodisch, aber mit SPL bin ich gut bekannt und nutze diese. Ich werde mich mal damit beschäftigen, wenn die anderen, wichtigeren Sachen gut funktionieren, denn einen Anschluss für Speicher habe ich ja schon auf der USB-A Buchse. Es scheint jedenfalls nicht ganz trivial zu sein, eine SD Karte von SPI wieder zurück auf SD 4-bit zu bringen, ohne die Karte abzuschalten, was hier ja nicht vorgesehen ist. TippsUndTricks schrieb: > SDIO ist doch kostenpflichtig, oder? Also die Specification war > irgendwie zeitweise geheim. Hat sich das geändert? Ich weiss dass es > irgendwie doch geleaked war, und es gab auch verschiedene > implementierungen. Darf man aber prinzipiell SDIO in ein Kommerzielles > Produkt einbauen und verkaufen? Lt. Elm Chan gilt die ganze Gebührennummer nur dann, wenn das offizielle Logo drauf sein soll. Einige Hersteller umgehen das mit Formulierungen 'SD-kompatibel' und so. Das hier wird aber eh kein kommerzielles Produkt, es sind eben einige dieser Geräte hier aufgeschlagen.
:
Bearbeitet durch User
Matthias S. schrieb: > Mw E. schrieb: >> So ziemlich der ganze HAL ist ein abschreckendes proof of concept ;) > > Ja nee, mit HAL wird hier nichts gemacht. Ich bin evtl. etwas > altmodisch, aber mit SPL bin ich gut bekannt und nutze diese. Das war ne Antwort zu "Auch Karl". Aber jetz weis ich womit du das proggen willst. Matthias S. schrieb: > Es scheint jedenfalls nicht ganz trivial zu sein, eine SD Karte von SPI > wieder zurück auf SD 4-bit zu bringen, ohne die Karte abzuschalten, was > hier ja nicht vorgesehen ist. Wie kommst du denn immernoch darauf? Eine SD Karte startet im 1Bit SDIO Modus. Um diese in den SPI Modus zu bringen brauchts ein Kommando. Um diese in den 4Bit Modus zu bringen auch und um diese mit mehr als 400kHz anheizen zu dürfen brauchts auch nochmal ein Kommando ;) Zudem verrät dir die Karte in einem Register wie schnell sie maximal getaktet werden will. Die SDIO Periph ist auch nicht so schwer. Kommando ins Register schreiben, Argument dazu, abdrücken. Dann per IRQ oder poll warten bis die Karte antwortet oder ein Timeout kommt. Dann die Antwort aus einem Register lesen.
Matthias S. schrieb: > Es scheint jedenfalls nicht ganz trivial zu sein, eine SD Karte von SPI > wieder zurück auf SD 4-bit zu bringen, ohne die Karte abzuschalten, was > hier ja nicht vorgesehen ist. Wozu auch? Wenn die Karte tatsächlich entfernt (und wieder appliziert) wurde, schaltet sie ja von alleine zurück. Alles, was dann noch "zurückgeschaltet" werden muss, ist "dein" (sehr wahrscheinlich aber nur zusammenkopierter) Softwarestack, von ganz unten bis auf Filesystem-Ebene. Alles, was sonst noch zu tun bleibt: der Anwendung einen sinnvollen Umgang mit zwischenzeitlich verloren gegangenen Filehandles beizubiegen. Was da sinnvoll ist, hängt sehr stark von der Anwendung ab, deswegen kann es auch kein allgemein gültiges Konzept dafür geben.
c-hater schrieb: > (sehr > wahrscheinlich aber nur zusammenkopierter) Softwarestack Nette Unterstellung, aber das ist man ja von dir nicht anders gewohnt. Wenn du die Programmbeispiele von ST nicht benutzen willst, ist das deine Sache, ich verstehe jedenfalls, was ich da 'zusammenkopiere' bzw., als nützliche Programmzeilen übernehme. Und ja, ich benutze FatFS von ChaN, weil ich das Rad wirklich nicht nochmal erfinden muss. c-hater schrieb: > Wozu auch? Wenn die Karte tatsächlich entfernt (und wieder appliziert) > wurde, schaltet sie ja von alleine zurück. Ah, wieder nur die Hälfte kapiert (oder die ersten Posts nicht gelesen). Für dich also nochmal zum Mitschreiben: Die Karte ist per 4-Bit SDIO am MC. Ein Hardware SPI liegt nicht auf den benutzten Pins - es bleibt also nur Bitbanging. Damit kann ich die Existenz einer Karte feststellen, schön und gut. Aber es ist für mich Unsinn, das ganze Handling der Karte per Bitbanging zu machen, denn das Gerät hat noch andere Sachen zu tun, als Bits zur SD zu schieben. Also muss die Karte im 4-Bit Modus betrieben werden, damit es sinnig bleibt und die Hardware richtig genutzt wird.
:
Bearbeitet durch User
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.