SD-Karte am uC

Ich versuche gerade eine SD-Karte am MSP430 in Gang zu kriegen und verwende da den Code aus der TI-Applicationote. Der macht das jetzt nur per bitbanging (Portpins werden per Software getoggelt) und ich kann das beliebig langsam machen und die Datenbits genau an den richtigen Stellen lesen und schreiben. Trotzdem hab ich den Effekt, dass die SD Karte den Initprozess nur dann macht, wenn da mein Oszi-Tastkopf 1:10 am CLK oder D0 hängt. Selbst wenn ich den auf D1 hänge klappt es (obwohl ich das Signal gar nicht nutze). Recht interessantes Verhalten ;-). Es kann eigentlich kein Timingproblem sein, denn wenn ich die Routinen per Hand durchsteppe (und der CLK so 1Hz ist) klappt es genauso oder auch nicht, je nachdem ob der Tastkopf dran hängt oder nicht. Auf Das IDLE-Kommando krieg ich dann die Response 0x03 und nicht 0x01 (wie sonst). D.h. Befehle nimmt die Karte an, nur inititalisieren lassen möchte sie sich nicht. (Problem könnte sein, dass auf dem SPI auch noch nen LCD mit dran hängt, aber das wird da noch gar nicht angefasst).

Bin für ein paar Denkanstösse dankbar...

M.

Reply to
Matthias Weingart
Loading thread data ...

Vielleicht hat es gar nichts mit den Timings der Signalleitungen zu tun. Ich hatte schon aehnliche Probleme mit PCMCIA-Karten die den Reset nicht korrekt ausgefuehrt haben. Die wollten eine bestimmte Rise-Time auf der Versorgung sehen um korrekt zu funktionieren. Gibt es da bei SD vielleicht auch solche Vorgaben?

Micha

Reply to
Michael Baeuerle

Ich kenne mich mit SD-Karten nicht aus, aber das hoert sich irgendwie doch nach Timing an (Data zu Clock). Kannst Du mal probehalber 10-20pF als Kondensator dranhaengen, ob derselbe Effekt eintritt?

Ist die Versorgung an der Stelle sauber?

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

Am Wed, 4 Mar 2009 14:03:11 +0000 (UTC) schrieb Matthias Weingart:

formatting link

Stefan

Reply to
Stefan Junge

Joerg :

Mit 33pF geht es ohne die Probe. Übrigens egal ob auf Vcc oder Gnd.

Sollte eigentlich, wenn ich den MSP abklemme und da nen uAlfat draufklemme geht das super. Identische Vcc (kommt innerhalb von wenigen us hoch), identische Pullups, fast identische Leitungslängen (so 5cm, aber das laeuft z.Z. nur auf 150kHz). Allerdings hat die SD dann ihre Leitungen für sich alleine. Ich werde das wohl mal auf einzelne Portpins umverdrahten müssen. Die SD braucht beim Startup ganz definierte Bedingungen an Ihren Pins.

Die Kommunikation mit dem SD-Controller scheint ja auch zu laufen, sonst würde er ja möglicherweise gar keine Antwort geben, er gibt was zurück, nur anstelle 0x01 (=idle) kommt 0x03 (idle+EraseReset, was auch immer das ist??).

M.

Reply to
Matthias Weingart

Matthias Weingart schrieb:

Probier mal Pull-Ups auf den SD-Leitungen. Ich hab 47k auf meinen SD-Kartenhalterplatinchen auf allen Signalleitungen, so herrschen definierte Zustände für die Karte beim Power-Up. Möglicherweise reicht schon einer auf der /CS-Leitung.

Jörg.

Reply to
Jörg Schneide

Wie lang sind denn die Leitungen zwischen CPU und SD-Karte?

Micha

Reply to
Michael Baeuerle

Gut abgeblockte VCC ist HF-maessig identisch mit GND. Aber seltsam ist das ganze. Koennten nicht doch ganz kurze Glitches, Unterbrechungen oder so auf den Signalen sitzen, die durch einige zig pF ausgebuegelt werden und die man auf dem Scope nicht sehen kann?

Falls das auch nur entfernt wahrscheinlich klingt lohnt sich der Aufbau eines Teilers. Z.B. 2K SMT Widerstand an die Datenleitung, andere Seite an 50ohm SMT auf GND, dann mit einem Koax von da zum Scope. Kompensiert ist das jetzt nicht, aber Spikes und so sollten sichtbar werden, wenn sie da sind.

Ich kenne SD-Karten nicht gut, aber m.W. muessen die Datenleitungen tri-state sein bis die Versorgung angelegt ist. Wenn Du einen Slot mit voreilenden Versorgungskontakten hast, probiere mal im Betrieb die Karte zu ziehen und wieder reinzustecken, ob der Fehler danach bleibt.

Gehoert habe ich von Embedded Leuten, dass sie oft Schwieigkeiten hatten die Karte in den SPI-Modus zu bekommen. Sonst liefen sie nur "manchmal". Den Grund weiss ich leider nicht mehr.

--
Gruesse, Joerg

http://www.analogconsultants.com/
 Click to see the full signature
Reply to
Joerg

|> identische Pullups, fast identische Leitungslängen (so 5cm, aber das laeuft |> z.Z. nur auf 150kHz). Allerdings hat die SD dann ihre Leitungen für sich

Die Frequenz ist irrelevant. Was zählt, ist wie "schön" die Flanke steigt. Und da sind gerade serielle Interfaces, die eine hohe Baudrate aushalten sollten (zB. SD, JTAG, ...) manchmal sehr penibel. Wenn die Leitungen ungünstig liegen, kann es durch eine Reflexion oder Einkopplung zB. gerade in der Mitte der Flanke zu einem Schlenkerer kommen und schon gibts zwei erkannte Taktpulse statt einem.

Manchmal wirkt ein Serienwiderstand von zB. 100R in der Taktleitung Wunder...

Ach ja, du machst die Wechsel an den Datenleitungen auch mit der Flanke, bei der die Daten nicht übernommen werden?

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

snipped-for-privacy@in.tum.de (Georg Acher):

Denk schon, hab auch mal die Flanken getauscht, dann kam dann 0x07 zurück anstelle 0x03. ;-( Ich vermute eher unsaubere Bedingungen beim Einschalten, da da ja noch andres Zeugs auf dem Bus ist. So ne SD braucht wohl zwingend ihren eigenen Bus. Und beim Start (und weiter bin ich noch gar nicht) ist das wohl alles Opendrain, der kriegt High nur durch die Pullups. (Übrigens die

100R hab ich auch schon drin gehabt).

Btw. weiss eigentlich jemand, ob die SDHC auch noch SPI können? Wesentlicher Unterschied ist wohl die Adressierung, nicht mehr per Adresse, sondern als Block (SDHC-Adresse = 512*block).

M.

Reply to
Matthias Weingart

Matthias Weingart schrieb: ...

Hier funktioniert eine SD-Karte, die sich den BUS mit einem anderen Device teilt. Jedenfalls insofern, als daß ich die SD-Karte immer komplett initialisieren muß, sobald das andere Device mal angesprochen wurde.

Ich habe schon verschiedenes versucht (CLK abschalten, wenn CS high wird usw.). Die Initialisierung dauert ca. 600ms, was mir bei diesem Datenlogger echte Probleme bereitet hat. (Jetzt nutze ich einen großen Puffer und schreibe den auf die Karte, sobald das Meßfahrzeug eine Weile stillsteht.)

Falk

--
An Enfield Diesel seems to do an even better job than a Harley at
converting fuel into noise without much unwanted speed!
Reply to
Falk Willberg

Falk Willberg schrieb:

Seltsam, funktioniert hier ohne Probleme mit einem FRAM am gleichen SPI-Bus. Gelegentlich gibts Errors beim Schreiben, die gabs aber auch schon bevor das FRAM dazukam, oft an charakteristischen Adressen, ich vermute internen Bankswitch oder Housekeeping des Kartencontrollers. Liegt aber auch daran das nicht gewartet werden kann bis die Karte dann mal mit dem Schreiben fertig zu werden gedenkt. Die Zeiten dürfen laut Standard wohl bis zu 2s lang sein, der Messzyklus aber meist nicht. Also lieber einen Log mit sporadischer Lücke.

Probier mal eine der (sauteuren) Industrial-Karten von Glyn, die scheinen etwas unproblematischer zu sein als so einige Consumerteile.

600ms zum Init kommt mir viel zu lang vor, da ist vermutlich anderes dabei als reiner Karteninit und versetzen in SPI-Mode.

Jörg.

Reply to
Jörg Schneide

Nein braucht sie nicht. Ich habe meherre Sachen auf einem Bus laufen. Allerdings schicke ich beim oeffnen immer mindestens 80Bit rueber um erstmal das Register zu leeren.

Ich glaube allerdings auch das du ein Problem mit den Flanken hast. Entweder generell der falsche Mode, ein Problem mit der Anstiegszeit, oder aber mit der Gleichzeitigkeit.

Lies dir bitte mal das hier durch:

formatting link

Besonders den Satz:

For SDC, the 'SPI mode 0' is defined for its SPI mode. But for MMC, it is not the SPI timing, both latch and shift actions are defined with rising edge of SCLK, but it seems work in SPI mode 0 at SPI mode.

Ich hatte mit dem eingebauten SPI des 68332 auch Probleme mit _manchen_ Karten. Die waren erst verschwunden als ich die Schnittstelle von Hand programmiert habe weil es da irgendwo eine kleine Inkompatibilitaet mit dem Timing gab. Wenn dein Prozessor oder die Karte zwei Dinge gleichzeitig machen will und dein Clock wird mal mehr oder weniger verzoegert dann gibt das Probleme. Und die Karten muessen ja ein schnelles Businterface haben, also werden sie aehnlich agressive Flanken haben wie ein CPLD. Also Terminieren wenn deine Karte nicht sehr kurz am Prozessor haengt.

Generell muss ich sagen es steckt ein ganz schoener Aufwand drin bis man seinen Code und seine Hardware soweit hat das es wirklich mit jeder Karte funktioniert.

Pullups von 47k sind in irgendeinem Datenblatt auch gefordert. Sehr wichtig ist auch ein 100nF Kondensator unmittelbar an der Karte.

Olaf

Reply to
Olaf Kaluza

Olaf Kaluza :

Interessante Sache. Also der bitbang-Code macht es hier so:

- CLK auf L

- Datenbit rausschieben

- Datenbit einlesen

- CLK auf H

Das Bit, das ich einlese, wird also von der SD Karte rausgeschoben, sobald ich CLK auf H lege. Das passt doch sehr gut.

Übrigens, seit ich das Ding auf separate Portpins umgelötet hab, funktioniert das prächtig. Lag wohl wirklich an dem Kuddelmuddel da beim Einschalten. Ausserderm zerwürgt es mir nicht die Displayausgaben, falls da mal jemand ne tote SD-Karte reinwürgt.

Mhh, ja scheint so. Besonders der Init. M.

Reply to
Matthias Weingart

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.