Grüße! Ich arbeite hier auf einem EKS-LM3S6965 Board von TI. Auf dem Board sitzt ein Cortex M3. Außerdem verfügt das Teil über einen Slot für µSD Karten und ein OLED Display. Display und SD Karte hängen beide am SPI Bus. Die SD Karte funktioniert super, wenn das Display außer Betrieb ist. Ich habe fatfs am Laufen und eine kleine Kommandozeile über den UART. Ein Beispielprogramm, das bei dem Board mit bei war. Nun habe ich ein Projekt mit FreeRTOS. Ein Task beschreibt das Display, ein Task macht die Kommandozeile aus dem Beispielcode von TI. Und da fängts an, merkwürdig zu werden. Die Karte reagiert nicht mehr richtig und liefern nur noch Müll bzw. ein konstantes High auf der Sendeleitung. Der Zugang zum SPI Bus ist mit einer Semaphore gelöst, die Chip Selects überschneiden sich nicht, das habe ich mit einem Logic State Analyzer geprüft. Nach ein paar Tests bin ich zu folgendem Ergebnis gekommen: Wenn ich, ohne dass der CS der Karte aktiv ist, ein paar Bytes auf den Bus schicke, verhält die Karte sich danach, wie oben beschrieben. Eigentlich dürfte das nicht sein, schließlich hat es die Karte nix anzugehen, was auf dem Bus passiert, wenn sie nicht aktiv ist. Andererseits reagiert sie aber auch nicht auf Kommandos, wenn der CS inaktiv ist. Hatte jemand schonmal ein ähnliches Problem oder kennt vielleicht sogar eine Lösung?
Ähnliche Probleme habe ich schon öfters gelesen. SD Karten zicken offensichtlich oft run, wenn sie an einem SPI Bus hängen. Steuere die Karte besser über eine separate Verbindung an, wo sonst nichts anderes dran hängt.
Habe ähnliche Probleme auch schon gehabt und konnte nicht auf zusätzliche PIN's ausweichen. Lösung: Vor jedem Zugriff CMD1 (Init) und nach jedem Zugriff CMD0 (Reset). Kostet zwar etwas (im Verhältnis zum eihentlichen Datentransfer) Zeit, aber dann hat es zuverlässig funktioniert. mfG vom ingo
>Ähnliche Probleme habe ich schon öfters gelesen. SD Karten zicken >offensichtlich oft run, wenn sie an einem SPI Bus hängen. Kann ich nicht bestätigen. SD-Karte, VS1001 und DOGM128 laufen bei mir rund um die Uhr an einem SPI.
@Ingo >Vor jedem Zugriff CMD1 (Init) und >nach jedem Zugriff CMD0 (Reset). Auch das muss ich nicht machen.
Stefan schrieb: > Ähnliche Probleme habe ich schon öfters gelesen. SD Karten zicken > offensichtlich oft run, wenn sie an einem SPI Bus hängen. Putzig. Wo hast du das gelesen?
> Wenn ich, ohne dass der CS der Karte aktiv ist, ein paar Bytes auf den > Bus schicke [...] Hast Du beachtet das die SD Karte ein dummy Byte haben will, nachdem CS auf high geht? Außerdem muss die Karte zuerst initialisiert werden - sonst ist sie im SD Modus, und da hat CS IIRC andere Polarität.
Ich gehe auch von einer Buskollision aus oder dass irgendwas verschluckt wird.
Der Code den ich da verwende ist Beispielcode von TI. Sofern keine anderes Gerät am Bus hängt, funktioniert ja alles. Also gehe ich davon aus, dass die Ansteuerung erstmal grundsätzlich korrekt ist. Kollisionen auf dem Bus finden nicht statt. Das habe ich mit einem LSA bereits geprüft. @Ingo Wendler: Danke für den Tipp! Das werde ich mal probieren.
Herr_Kaiser schrieb: > Kollisionen auf dem Bus finden nicht statt. Mit Kollisionen sind auch die Zustände gemeint, die das Timing eines Busteilnehmers verletzen, also nicht unbedingt fehlerhafte Bits. Es stellt sich doch die Frage, warum es bei anderen funktioniert und bei Dir nicht. Denkbar sind allerdings auch Layoutprobleme...
Normalerweise hat die SD Karte ein /CS (chip-select) Eingang, über den kann man sie Ein- oder Ausschalten (im Sinne von "sie hat Strom, reagiert aber auf nichts"). Versuch mal sie darüber abzuschalten, bevor du dem Display was sendest (und danach eben wieder an). Außerdem würde ich Spaßeshalber mal eine andere SD reinschieben und schauen ob die tut. Teilweise unterscheiden sich die SDs im Verhalten (warum habe ich auch noch nicht wirklich rausgefunden...).
Ich hatte FatFS auf einer µSD Karte parallel im Betrieb zu einem weiteren SPi IC betrieben. Es gab Probleme mit der µSD Karte. Ein Pull-Up an der MISO (eher hier) oder MOSI hat das Problem gelöst. Anscheinend hat sich die Leitung was eingefangen. Wenn der andere IC nicht eingelötet war, gab es diese Probleme nicht. Vielleicht war es auch nur ein ungünstiges Layout ich weiß es nicht. Aber prinzipiell sollte µSD und weitere SPI Slaves an einem BUS keine Probleme bringen.
Arbeiten denn beide Busteilnehmer im gleichen SPI Mode? Nicht, dass das Display diesen umschaltet und die SD Karte nurnoch Salat sieht.
♪Geist schrieb: > Ein > Pull-Up an der MISO (eher hier) oder MOSI hat das Problem gelöst. Ein Pullup an MISO ist bei SPI Pflicht, da die Leitung, wenn alle Busteilnehmer abgewählt sind, jeden beliebigen Pegel annehmen kann und der Master so das Frameende der Daten oder das Busy nicht erkennen kann, gerade bei SD-Karten.
Freddy schrieb: > Normalerweise hat die SD Karte ein /CS (chip-select) Eingang, über den > kann man sie Ein- oder Ausschalten (im Sinne von "sie hat Strom, > reagiert aber auf nichts"). Versuch mal sie darüber abzuschalten, bevor > du dem Display was sendest (und danach eben wieder an). Das hatte ich in meinem Eingangspost schon beschrieben. Wenn Daten auf dem Bus gesendet werden und der Chip Select der Karte nicht aktiv ist, baut sie danach Murks. Wird nichts auf dem Bus gesendet, verhält sie sich korrekt. Der Chip Select wird korrekt bedient. Martin Wende schrieb: > Arbeiten denn beide Busteilnehmer im gleichen SPI Mode? > Nicht, dass das Display diesen umschaltet und die SD Karte nurnoch Salat > sieht. Nein, die arbeiten tatsächlich in unterschiedlichen Modi. Der SPI Modus wird umgeschaltet, bevor der jeweilige Teilnehmer zum Zuge kommt. Mit einigen Kommandos konnte man der Karte auch während das Display betrieben wurde noch korrekte Antworten entlocken. Zumindest als eine ältere Version von Fatfs benutzt wurde. Layoutprobleme schließe ich aus, da es sich um ein Evaluationsboard von Texas Instruments handelt. Ich gehe stark davon aus, dass sich die Karte einfach inkorrekt verhält.
Herr_Kaiser schrieb: > Ich gehe stark davon aus, dass sich die Karte einfach inkorrekt verhält. Kommt auf die Betrachtungsweise an. In einem Rechner oder einer DigiCam wird sie tadellos funktionieren. Vielleicht kratzt sie ja am Rand der Spezifikation oder aber die Ansteuerung gefällt ihr einfach nicht, da diese die Spezifikation verletzt. Such´s Dir aus.
Knut Ballhause schrieb: > oder aber die Ansteuerung gefällt ihr einfach nicht, da > diese die Spezifikation verletzt. Such´s Dir aus. Die Ansteuerung funktioniert ja, wenn kein anderes Gerät auf dem Bus aktiv ist. Dann lässt sich die Karte prima auslesen. Wie schon im Eingangsposting beschrieben: War Datenverkehr auf der Sendeleitung des Prozessors, ohne dass der Chip Select der Karte aktiv war, baut sie danach Mist. Muss man hier eigentlich jedem Zweiten nochmal das erklären, was man zu Anfang schon geschrieben hatte?
Habe das Ganze jetzt mit einer anderen SD Karte probiert. Die Karte, die ich bisher verwendet habe, war von der Firma Hama - ja, das lässt nichts Gutes ahnen. Eine Karte der Firma SanDisk funktionierte ganz vortrefflich. Das Problem ist also wohl tatsächlich die Karte und weder die Schittstelle noch deren Ansteuerung auf meinem Board.
Herr_Kaiser schrieb: > Die Ansteuerung funktioniert ja, wenn kein anderes Gerät auf dem Bus > aktiv ist. Herr_Kaiser schrieb: > War Datenverkehr auf der Sendeleitung des Prozessors, ohne dass der Chip > Select der Karte aktiv war, baut sie danach Mist. Es sollte trotzdem funktionieren, wenn man der Karte entsprechend den Bauch pinselt. Das muss auch ohne extra PowerDown, Reset oder sonstige Tricks gehen. Ich habe bald selbst das Vergnügen, an einem Port mit DataFlash und SRAM eine Mikro-SD-Karte zu betreiben, dann kann ich ja nochmal berichten. Herr_Kaiser schrieb: > Muss man hier eigentlich jedem Zweiten nochmal das erklären, was man zu > Anfang schon geschrieben hatte? Nein. Ich hatte Dich schon verstanden. Ich meine nur, dass wenn man alle Notwendigkeiten einhält, dass dann die Technik funktionieren muss. Ansonsten wäre die Karte nicht durch die industriellen Tests gekommen, so sie denn welche absolviert hat. Entschuldige wenn das für Dich wie Klugscheißen klingt, aber ich konnte alle technischen Probleme, die ich bisher hatte, immer auf den Prozessor zwischen meinen Ohren zurückführen, wenn die Hardware nicht wirklich verbugt war. Deshalb bin ich hier so hartnäckig mit meinem Rat.
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.