Grüße! Ich hab hier ein Projekt, bei dem ich Daten auf eine SD-Karte loggen soll/darf/muss. Bisher habe ich dafür 2 verschiedene Karten benutzt: eine 256MB Karte von Lexar sowie eine 1GB Karte von Kingston. Beide funktionieren über die 0815-SPI-Initialisierung (CMD0, ACMD41, Read OCR, CID, CSD) wunderbar, auch Daten lesen und schreiben funktioniert absolut problemlos (FAT32). Das Problem bei diesen beiden Karten ist jedoch, dass das Schreiben ewig braucht - obwohl die Karten theoretische ein paar MB pro Sekunde schreiben können sollten, schaffe ich über SPI gerade mal etwa ein Kilobyte pro Sekunde. Die SPI-Clock hat auf die Geschwindigkeit keine ersichtliche Auswirkung, das dauert bei 1MHz genauso lange wie bei 20MHz. Irgendeine Idee woran das liegen könnte? Nun habe ich mir eine SanDisk Ultra II mit 1GB zugelegt, allerdings kann ich diese Karte scheinbar nicht richtig initialisieren, die Karte kommt nach ACMD41 nie aus dem Idle-State. Wenn ich vor dem Versuch die Karte zu initialisieren ein CMD8 sende, bekomme ich 0x7F.FF.FF.FF.FF als Antwort zurück (die anderen Karten antworten mit 0x01.00.00.01.AA), und auf CMD58 bekomme ich 0x01.00.FF.80.00 zurück (wenn ich CMD8 nicht sende, bekomme ich da ebenfalls 0x7F.FF.FF.FF.FF zurück). Ich verstehe nicht warum die SanDisk nicht mit mir (also mit meinem Controller) sprechen will. Bin für alle Hinweise dankbar! Details am Rande: Betrieben wird die SD-Karte mit CPOL=1 und CPHA=1, die Initialisierung läuft mit 400kHz. SCLK und MISO haben einen Pull-Up auf 3.3V, der Controller ist ein BlackFin BF537 und programmiert wird das ganze mit (bitte nicht schlagen, ich hab's mir nicht aussuchen könnten) LabView Embedded (welches Visual DSP++ im Hintergrund verwendet). Bin für alle Hinweise (sehr) dankbar!
Nachtrag: 1.) Zum Thema Geschwindigkeit: es gibt auch keinen erkennbaren Unterschied zwischen Single-Block-Write und Multiple-Block-Write. Irgendwie muss man die Karten im SPI-Modus doch zu einer vernünftigen Schreibgeschwindigkeit bringen können, im SDIO-Modus funktionieren die ja auch sehr flott... 2.) Zum Thema SanDisk: Auf ACMD41 bekomme ich immer 0x3F zurück (d.h. da sind quasi alle Error-Flags gesetzt bis auf eine). Auf CMD58 (Read OCR) bekomme ich interessanterweise von der SanDisk eine vernünftige Antwort (sofern CMD8 zuvor gesendet wurde), da liefert er mir brav "Idle"=1, "Card power up status bit"=0 [this bit is set to LOW if the card has not finished the power up routine] sowie einen vernünftigen Spannungsbereich (3.6-2.7V). Es ist zwar klar das er sagt "the card has not finished the power up routine", aber warum lässt sich diese nicht durchführen (warum bekomme ich auf ACMD41 keine sinnvollen Antworten)?
Hallo Markus, ich habe ein ähnliches Problem: manche meiner Karten gehen und manche nicht. Ich habe eine MMC mit 32 MB, auf der geht alles einwandfrei. Dafür kann ich eine SD SanDisk 1GB wohl lesen, beim Schreiben schreibt sie aber fast alles mit 0xFF drauf, wird also richtig initialisert. Ein TransCend kann ich nichtmal lesen, die lese ich immer einen Code, der so nicht stimmt, das kann ich über WinHex sehen. Als Taktfrequenz habe ich zur Zeit noch 250kHz für SPI, was sich aber auf 20MHz steigern läßt, wie ich jetzt weiß. Für die Hardware habe ich die Schaltung von Ulrich Radig genommen. Alle Karten können über einen Card-Reader einwandfrei gelesen und beschrieben werden, sind also wohl nicht kaputt, oder? Weiß hier jemand einen Rat, warum es bei manchen Karten geht und (bei mir) mit manchen Karten gar nicht?
Ich würde sagen irgendwelche Pegel oder Timings stimmen nicht. Bei mir liefen bisher immer alle Karten.
Hallo, ich habe mich mit dem gleichen Thema sehr lange befasst und auch viele Karten getestet, so dass eine Software für PIC entstand mit der alle, bis auf eine alte 16MB Karte zusammenarbeiten. Ärgerte mich auch erst, dass eine geht und die anderé nicht. Als erstes: Die Hardware von Ulrich Radig funktioniert nicht richtig, die Flanken verschleifen. Man muss nur mit dem Finger an einen Pin kommen oder nur den tastkopf des Oszi dranhalten und schon stürzt die Karte ab. Nimm echte 3.3V Treiber (74LVP....) oder eine 3.3V CPU und dann geht das auch. In Ulrichs Programmen habe ich auch kleine Fehler entdeckt, bzw. sind nicht alle Fehler abgefangen. Lies die Spec wirklich buchstabengetreu durch und mache es genauso wie es da steht, jeder Fehler muss abgefangen werden. Falls der AVR Schmitt Trigger Eingänge an der SPI hat: Treiber vorschalten! Schmitt triger sind nicht kompatibel mit 3.3V Logik. Beachte, dass bei alten Karten der Schreibzyklus bis 50ms lang ist !! Löschzyklen sind ebenfalls locker bis 10s (!!!) lang. Da laufen ein paar Timeout über. Manche Karten kehren kurze Zeit nach jedem Zugriff in den Idle Mode zurück und müssen explizit wieder aufgeweckt werden durch den CMD0 Befehl. Die Karten müssen mit kleiner Taktrate aufgeweckt werden (< 1MHz), erst danach kann man hochdrehen. Manche Karten wachen erst auf, wenn ich ihnen ein paar Mal den Strom einschalte mit einem P-Kanal FET, der den 3.3V steuert. Keine Ahnung warum. Meine Software macht nur Einzelblockzugriffe, weil etwas anderes mit einer FAT auch wenig Sinn macht und vor jedem Lesen und Schreiben sendet Sie eine Wake Up Sequenz. Das verlangsamt die Sache aber machtr sie sicherer.
Hallo an alle, ich stelle hier meinen Code als Dateianhang mal zur Verfügung - auch ohne Fehler abzufangen - bislang. Damit kann ich Blocks lesen und schreiben, wie gesagt aber nur auf meiner MMC-Karte 32 MB groß. Den Tips von Christian werde ich jetzt mal nachgehen. Vielen Dank erst mal.
Hallo, anbei mal mein Code, aber auch nur für 128/256 MB Karten, da ich die Kartenparameter nicht auswerte bzw. bislang zu faul war die auszulesen. Ich müsste mal das ganze "universalisieren" :-) Aber da fehlt einfach die Zeit zudem der ARM7 ja jetzt dran ist. Ist für PIC mit CCS in einem Multi-Slave System für SPI aber sollte die wesentlichen Sachen verdeutlichen. PS: Ich arbeite mit 32MB Banken, weil 16 Bit für den CCS noch gut zu handeln sind und mein Projekt mehrere Banken braucht. Mit einer FAT haperts leider, gibt da nichts für PICs und eine von AVR umschreiben... nee, die Codes sind immer so schrecklich unkommentiert.
Grüße! Das Geschwindigkeitsproblem konnte ich inzwischen lokalisieren - das scheint ein Problem des "System Services and Device Drivers Framework" des BlackFin bzw. des VisualDSP++ Kernels zu sein, da gibt's 2 Funktionen die ich bei jedem Transfer mindestens einmal aufrufen muss (SPI Aktivieren, Warten bis der Lese-Buffer voll ist), wobei das Aktivieren schon mal 9ms braucht, und das muss ich aber vor jedem Transfer machen (da muss ich mich mal mit Analog kurzschließen ob die eine bessere Lösung haben). Warum ich die SanDisk nicht ansprechen kann ist mir jedoch weiterhin schleierhaft. @Christian: so schwierig kann die Portierung eines FAT-Treibers von AVR auf den PIC nicht sein, das einzige was sich da unterscheidet sind die SPI-Zugriffe, alles andere sollte man 1:1 übernehmen können. Ich hab's da ein bisschen schwieriger gehabt - oder kennt jemand wen der einen FAT-Treiber in LabVIEW [Embedded] ge"zeichnet" hat? Werde den Code aber an geeigneter Stelle veröffentlichen wenn er stabil genug ist (und ich das Performance-Problem in Griff bekommen habe), auch wenn ich vermute das das Interesse an einer derart speziellen Lösung gegen 0 gehen dürfte. Bin für SanDisk-Hinweise weiterhin dankbar!
Angehängte Dateien:
-
SD-an-PIC.jpg
270 KB
@Christian, habe die Schaltung jetzt mit Treibern aufgebaut und die Leitungen erheblich verkürzt. Im Prinzip ist aber alles wie vorher, obwohl ich diese Schaltung mit Treibern natürlich für sicherer halte. Die SanDisk kann nach wie vor lesen. Meine TransCend 1GB liest immer nur Nullen aus. Sie tut also so, als ob alles in Ordnung wäre, keine Fehlermeldungen oder so. Init erfolgreich, oder? Ist sie wieder im idle-mode? Wenn ja, hätte doch wohl eine Fehlermeldung in Form eines timout kommen müssen... Meine Schaltung SD-an-PIC in JPG füge ich mal bei, wen es interessiert. Hier sind aber nur die relevaten Leitungen angeschlossen. Als 5V nach 3,3V Pegelwandler habe ich einen 74LVX125 in SMD benutzt. Als 3,3V nach 5V Pegelwandler habe ich ein nicht benutztes Ein-Ausgangspaar des MAX232 verwendet. Man kann aber auch einen 74HCT125 nehmen.
Hmm, ich muss Benedikt zustimmen, bei mir liefen bisher auch alle Karten. Bennutze auch keinen Pegelwandler, irgendwas ist in eurem Code oder Timing faul. Versuchts vielleicht mal in Assembler . Gruss
Hallo Walter, Frage 1: Kannst Du mir mal die Eagle Lib zuschicken mit dem SD Kartenhalter? Die andere Sache: Mit dem Treiber kann man bis 20 Mhz fahren, statt nur 1 Mhz mit Widerständen. Sporadische Fehler werden vermieden, die hatte ich mit Widerständen immer. Das andere.... ich habe eine 16MB Karte, die will ums Verrecken nicht. Irgendwann gibt man auf, wenn 99% der anderen es ja tun. Spiel mal mit der Initsequenz herum, lasse sie öfter und länger laufen. Da man ja die Karte nicht debuggen kann hilft hier nur Trial & Error. Überprüfe auch mal, ob die 3,3V -> 5V wirklich funktionierern, der PIC verträgt keine 3.3v an seinen SPI Pins. Bei der Portierung von AVR Code habe ich aufgehöprt, der CCS Compiler ist total anders, hat viele Einschränkungen. Daher wohl auch so billig.
fubu1000 wrote: > Hmm, > ich muss Benedikt zustimmen, bei mir liefen bisher auch alle Karten. > Bennutze auch keinen Pegelwandler, irgendwas ist in eurem Code oder > Timing faul. Versuchts vielleicht mal in Assembler . Assembler muss nicht unbedingt sein. Ich hatte einmal eine HDD mit einem 8051 inkl FAT usw. angesteuert. Das würde ich mir heute nie wieder machen. Ich denke mal es gibt 2 Fehlerquellen: - Pegelwandler (benutze ich nie, sondern ich lasse den uC immer mit 3,3V laufen, daher kann ich dazu nicht viel sagen, außer dass dies wirklich eine schöne Fehlerquelle ist). - Software, insbesondere Wartezeiten und SPI Timing (auch im Zusammenhang mit dem Pegelwandler), und der SPI Geschwindigkeit bei der Initialisierung. Eigentlich ist der SPI Modus der SD Karten nämlich nicht kompatibel zu den 4 SPI Modes, die die meisten uC können, denn afaik sampled die Karte auf der gleichen Flanke, auf der auch die Daten ausgegeben werden. Dadurch ist schnell mal ein Bit um eine stelle verschoben. Bei der Initialisierung der SD Karte darf der Takt nur einige 100kHz betragen. Das berücksichtigt nicht jede Software. Weiterhin sind die Wartezeiten bei der Initialisierung oft falsch. Da musste ich bei einigen Softwarversionen ein wenig anpassen.
Hallo Christian, wo soll ich die LIB denn hinschicken?
Ich häng` sie jetzt einfach mal an. Sie ist von mir selber erstellt und läuft unter Eagle 4.03
> Eigentlich ist der SPI Modus der SD Karten nämlich nicht kompatibel zu > den 4 SPI Modes, die die meisten uC können, denn afaik sampled die Karte > auf der gleichen Flanke, auf der auch die Daten ausgegeben werden. Ich hoffe sehr jeder hier hat obigen Satz mindestens dreimal gelesen! Das ist naemlich ein grosses Problem das dafuer sorgen kann das manche Karte funktionieren und andere nicht. Und gelegentlich glaubt man vielleicht auch das es an Widerstaenden oder an der Kabellaenge, oder am Takt liegt weil die vielleicht die entscheidende ns an der Flanke hinbiegen damit es mit der einen Karte nun laeuft! Momentan verzichte ich auf Hardware-SPI bei MMC/SD. Bei Gelegenheit wollte ich nochmal ausprobieren wie es ist wenn ich in einer der Leitungen noch eine extra Gatterlaufzeit einfuege. Olaf
@Benedikt: Bei der Arbeit nutzen wir auch nur C++, da iss Assembler mal ne schöne Abwechslung. "Assembler muss nicht unbedingt sein. Ich hatte einmal eine HDD mit einem 8051 inkl FAT usw. angesteuert. Das würde ich mir heute nie wieder machen." Ich hab nen Mp3Player mit SD in Fat, Grafik LCD mit Zeit und ID3-Tag Anzeige alles in Assembler programmiert, das war nen Spass würde ich wieder machen.^^ Gruss
Hallo, entschuldigung, wenn ich mich hier so laienhaft einmische. Ich kann nirgendwo Hilfe bekommen und in diesem Forum scheinen Leute mit Ahnung zu sein: Meine Speicherkarte hat mit allen wertvollen Fotos drauf den Geist aufgegeben, es handelt sich um eine SanDisk 1 GB. Rettungssoftware bringt nichts, weil sie gar nicht erst als Laufwerk bzw. Datenträger erkannt wird. Auch der Trick über formatieren in der Kamera und dann wieder die Daten wiederherstellen geht nicht, auch die Kamera meldet einen Datenfehler. Wahrscheinlich entleerte sich beim Speichern einer Aufnahme der Akku der Kamera. Die Daten sind doch noch drauf, hat vielleicht irgendwer eine Idee, wie man sie restaurieren könnte? Vielen Dank erstmal und nochmal sorry für die Störung.. stricker@gesundheitsseiten.de
> Eigentlich ist der SPI Modus der SD Karten nämlich nicht kompatibel zu > den 4 SPI Modes, die die meisten uC können, denn afaik sampled die Karte > auf der gleichen Flanke, auf der auch die Daten ausgegeben werden. So? Interessant. In der mir vorliegenden Spezifikation von Sandisk übernimmt die SD-Karte ihre Daten mit der steigenden Flanke von CLK, und gibt ihre Daten mit der fallenden Flanke von CLK von sich. Ich habe bisher bei KEINER Karte Probleme gehabt. Man muss nur die Spezifikation GENAU einhalten - und das ist manchmal nicht einfach. Einige Karten haben z.B. vom Kommando zur Antwort eine Anzahl an bits, die nicht durch 8 teilbar ist. Da muss man sich dann auf das erste Bit der Antwort synchronisieren. Einige mögen auch nicht, wenn man zwischen Kommando und Daten das ChipSelect wegnimmt. Es gibt sehr wohl einen Unterschied zwischen Transfers mit einem Sektor und mit mehreren, besonders beim Schreiben. Man sollte mindestens 2 KByte am Stück transferieren, wo das möglich ist. Dann muß der Controller in der SD-Karte nicht mit physikalischen Teilblöcken arbeiten.
Hier ein Link zu meinem MMC/SD Projekt. Nach etlichen Rückfragen bei diversen Herstellern habe ich derzeit keine "unsupported card" - aber man weiß bei den Karten ja nie... http://www.embedded-os.de/index.html?pcfat_port.htm Dieses Projekt kann mit MMC-/MMCplus-/HD-MMC-/SD- und SDHC- Karten umgehen, bei Verwendung eines SPI-Interfaces. PS: Wer einfach nur Widerstände als Spannungsteiler verwendet (5V/3.3V), bekommt eine unangenehme Signalverscheifung, die bei höheren Übertragungs-Geschwindigkeiten zu Problemen führen kann.
wostri: SD Karte aufmachen, darin findest Du einen oder mehrere NAND flash chips. Die kannst Du z.B. mit einem USB-xD Kartenleser auslesen: http://www.uchobby.com/index.php/2007/05/05/read-embedded-flash-chips/
Hier gibt es ein paar interessante Oszilloskop-Bilder zu den Widerstands- und Transistorlösungen als Pegelwandler. Das könnte auch etliche der Probleme erklären. Link anklicken und nach unten scrollen: http://www.shop.display3000.com/pi8/pi14/pd102.html
> Hier gibt es ein paar interessante Oszilloskop-Bilder zu den
Ich fand ja vor allem den Preis und das schamhafte verschweigen
des eingesetzten Pegelwandlers interessant. :-)
Olaf
Volker Mehrdorn wrote: > Hier gibt es ein paar interessante Oszilloskop-Bilder zu den > Widerstands- und Transistorlösungen als Pegelwandler. Das könnte auch > etliche der Probleme erklären. > Link anklicken und nach unten scrollen: > http://www.shop.display3000.com/pi8/pi14/pd102.html F***, ich glaub ich werd da jetzt selber mal nachmessen... sieht ja fürchterlich aus...
1000 Dank für die Linktipps bezügl defekter SD Card. Es hat geklappt, die Bilder sind wieder da. Mit OnBelay von CompuApps wurde die Karte ausgelesen. Anschliessend Daten auf eine neue Karte schreiben lassen, muss dann in der Kamera formatiert werden. Daten wiederherstellen hat mit smart recovery von convar pcinspector geklappt. Prima! Luftsprünge mach! Freu freu! Vielen Dank an alle!
Die Bilder unter dem Link sehen mir aber arg gestellt aus. Ich habe bei meinen Widerstands-pegelwandlern immer 1,8k + 3,3k genommen und anschließend nur ein kleines Stück Leiterbahn bis zur SD Karte und ich kann mich nicht daran erinnern, dass es dermaßen aussah.
Angehängte Dateien:
-
SCRN0007.PNG
5,4 KB
Ich habe gerade mal an einem R-Pegelwandler mit 1k zu 2k2 nachgemessen. Etwas übertrieben sind die Bilder von Display 3000 ja schon. Oder es liegt an dem Rigol...
Angehängte Dateien:
-
lecroy-rigol.gif
33 KB
also ich habe mir bei Display3000 vorletzte Woche ein SD Kartenmodul gekauft und bin nun am langen Wochenende endlich dazu gekommen es auszuprobieren. Und man glaubt es kaum: alle meine Karten funktionieren mit diesem Modul (einige gingen vorher nicht und ich habe da wirklich alles mögliche probiert) ausserdem erlauben sie mir maximale Datenfrequenz, was ich vorher so auch nicht hinbekam. Die Doku ist auch sehr ausführlich und gut gemacht. Dann zu den Bildern - auf den ersten Blick sieht das schon seltsam aus aber mann muss natürlich schon die gleiche Skalierung wählen, sonst vergleicht man Äpfel und Birnen. Ich habe mal das Bild von Display3000 künstlich so gestaucht und mit Copy&Paste vervielfacht so das es der gleichen Skalierung wie beim LeCroy Bild entspricht: dann ist der Unterschied vernachlässigbar (oben LeCroy, unten Display3000 Originalbild) und eher Probe- und/oder Widerstandsabhängig. Oli
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.