Ich habe vor längerer Zeit SD/MMC + Fat16 routinen für einen AtMega programmiert (assembler quellcode unter
formatting link
). Da am Anfang die Kommunikation (SPI) mit der SD-Karte nicht funktionierte habe ich einfach diverse Kommandos an die Karte geschickt (die gute alte 0-255 Schleife) und geschaut, worauf und wie die Karte reagiert.
Danach war die Karte defekt. Sie wird zwar von meinem Palm noch als
128MB-Sandisk-Karte erkannt, aber lässt sich weder formatieren noch sonst irgendetwas damit anstellen. Auch das auslesen einzelner Sektoren funktioniert bei dieser Karte nicht mehr.
Die FAT/SD funktionen funktionieren zwar mittlerweile vorbildlich (siehe
formatting link
aber die Karte würde ich dennoch ungern einfach wegschmeissen.
Vermutlich habe ich irgendwie die Firmware der Karte oder ähnliches mit einem nicht dokumentierten Befehl zerschossen. Hat irgendjemand Erfahrung mit solchen Fällen?
Ich hab festgestellt das die Initalisierung für den SPI-Modus etwas kritisch ist, manche Karten brauchen halt doch etwas mehr Zeit als andere. Beachte das eine Kartenart (MMC oder SDC) die CS Leitung beim Initialisieren von SPI (80mal 0xFF DataIn oder eben entsprechende Clockpulse) disabled haben will (funktionieren tuts dann mit beiden). Das "Ergebnis" sollte auch abgeholt werden, kann man aber in die Tonne kloppen. Dann kannst du Cmd0 absetzen und kannst anfangen mehrmals und mit Wartezeit auf die korrekte Antwort zu pollen. Ähnlich läufts mit Cmd1. Wenn das funktioniert sollte auch SPI aktiv sein.
Auf die Idee die Karte einfach mal mit allen Kommandos zuzuballern bin ich allerdings nicht gekommen...
Auch nicht CID und CSD? Zumindest ersteres wird wohl von Deinem Palm noch gelesen werden können, sonst würde er nicht die Infos ausspucken können. Ich würde zunächst das mit Deinem µC versuchen und mit einer Funktionierenden vergleichen, so findest Du heraus ob dort evtl. Müll drinsteht. Besser wäre natürlich die komplette Doku des CSD, dann kann man auch sehen wie die Karte angesprochen werden will und ob das mit Deinem Interface und der Software übereinstimmt.
Ich würde mir auch mal den Kartenstatus mit Cmd13 auslesen, da gibts ein ominöses "Secured Mode" vielleicht ist das gesetzt. Es gibt auch noch ein lock/unlock, hab ich mich aber noch nicht mit beschäftigt, ist bei Infineon z.B. auch nicht verwendet.
Nein nur mit Readern die keine 256MB Karten lesen und beschreiben können, ich könnte mir aber Vorstellen das etwas mit dem SPI (auf der Karte oder µC-Interface oder Software) nicht stimmt und gleichzeitig in den ersten Sektoren der Karte Müll steht, hängt halt auch davon ab woher der Palm die Infos zum Formatieren nimmt. Braucht der eine intakte Partitionstabelle?
An welcher Stelle hakts denn eigentlich genau, wenn Du die Karte mit dem µC ansprichst?
Ich schau mir mal Deinen Code an, ich hoffe der ist auch für nicht ATMeganer lesbar.
Also, der Karteninit sieht ja ganz ok aus, ich würde vielleicht testweise ein paar nops oder anderweitige Wartezeiten zwischen Cmd und antwortholen einbauen. Und versuchen an die Status und sonstigen Register zu kommen, sind ne Menge infos drin, auch über evtl. Errors der letzten Operation.
Ja, das war weder schlau, noch erfolgreich. Ich hatte die SPI-mode initialisierung einfach nicht hinbekommen, hatte es schon Stunden probiert und wußte einfach nicht mehr weiter :-) Mittlerweile klappts aber!
Gute Frage. Die Karte lässt sich mit garnicht mehr in den SPI modus versetzen. Eine andere (gleiche) Karte schon.
Kleines Update dazu: Ich habe die Karte gerade in eine Digicam geschoben und die meldet: "Speicherkarte ist gesperrt". Fragt sich nur, wie ich die "entsperrt" bekomme, wenn ich sie nicht mehr in den SPI modus versetzen kann :-( Mit gesperrt ist scheinbar auch nicht der Schreibschutz-schieber gemeint, der ist in ungeschützer position.
Denke ich auch. Er zeigt sogar die Geräte-ID ("SD128_2005...") an.
Das mit dem lock/unlock klingt schon verdächtig nach meinem Problem :-)
Ich weiß es nicht. Ich hatte das auslesen einzelner Sektoren mit einem USBSDC Adapter und Diskeditor ausprobiert. Der Editor meldet aber nur ständig, dass er die Sektoren nicht lesen kann.
Ich hatte an den falschen Taktflanken gelesen und geschrieben.
Naja, mit den "gleichen" Karten ist das so eine Sache... Dann versuchs mal mit geändertem Timing, ich hatte sogar mal eine Karte die in irgendeine Art Latch-Up ging und dem Host den Strom klaute, eine Timingänderung beim Initialisieren brachte Abhilfe. Und die Karte hats auch überlebt. Ich kann mir das nur so erklären, das ich sie zu früh angesprochen hab, die Teile brauchen schonmal was Zeit um intern alles geregelt zu bekommen, wenn sie dabei in irgendeinen internen Flashbereich schreiben sollten, könnte diese Zeit sogar mit der Anzahl Powerup-zyklen länger werden, so wie das auch für das normale Schreiben ins Flash gilt.
Nochwas: Ohne Dein elktr. Interface genau zu kennen, schau Dir mal genau an ob der High-Pegel der Kartenausgangsleitung am µC überhaupt sicher ausreicht und ob die Clockflanken die an der Karte ankommen ausreichende Steilheit haben. Ersteres sollte kein Problem sein wenn Du eh deinen µC mit 3.3V betreibst.
Der wird eh nur mechanisch abgefragt, wenn Du also die Kontakte am Slot in Deiner Anwendung nicht abfragst kannst Du ohne Probleme schreiben.
Hast Du ein Datenblatt wo das näher Beschrieben ist? Würde mich auch interessieren.
Nimm mal WinHex, das kann phys. ab Sektor 0 lesen (und schreiben).
He, he, das hat mich auchmal etwas Zeit gekostet, auf die primitivsten Fehler kommt man manchmal etwas später.
Habs mir mal angesehen, prüf mal den min. High-Pegel des AT, und was da wirklich ankommt. Die Dioden als 3,irgendwas Volt sind auch nicht gerade das gelbe vom Ei, die Ausgangsspannung wird immer von der Stomaufnahme abhängig sein, je nach Dioden. Falls der AT irgendeinen Schmitttriggereingang hat würde ich zumindest den benutzen, ansonsten sollte da schon ein Pegelwandler rein. Spannungsteiler könnte für Clk zu lahm sein, ausserdem wollen die Karten (auch für SPI) eigentlich überall leichte Pull-Ups haben. Früher oder später bekommst Du mit dem Interface Probleme.
Also besser auch ein Pegelwandler in die andere Richtung.
sorry for english, its designed to be fast bootloader and configurator. can load any SRAM FPGA with initial bitstream and then continue to load FPGA-uCLinux as example. after config the MMC/SD card is accessible as file system. optionally can boot MCU systems with no ROM by loading external SRAM and then releasing CPU reset.
I managed to get minimal MMC version into 21 macrocells!! but then to my horror realizes the SD support is a bit more complicated and requires quite a bit more macrocells. SD requires 16 bit register for RCA and as the stream read is not supported some additional 10 macrocells are needed to filter out data stream in repeat block read so the SD version does not fit into 36 macrocells no way :(
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.