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.
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.
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.
♪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.
