MMC-Antworten nicht byte-aligned?

Gast #309152
Lesenswert?

Hallo!

Sowohl mit meinem eigenen Programm, als auch mit Ulrich Radigs Code
(mit einigen NOPs mehr, beide Software-SPI) kann ich meine MMC-Karte
initialisieren. Bei der Abfrage vom CSD bekomme ich aber reproduzierbar
die Antwort FF00FFFC01C0... Eigentlich müsste ja das Start-Byte FE
erscheinen. Allerdings ist FC ja nur um ein Bit verrutscht!

Dem wollte ich auf den Grund gehen und hab mir ein Programm
geschrieben, mit dem ich die MMC-Befehle von Hand eintasten kann.
(Bevor jemand fragt: Natürlich entprellt.) Nach CMD0 erhalte ich sieben
Einsen, dann sieben Nullen, dann wieder Einsen. Das heißt, eine Eins (zu
Beginn) fehlt! Die schnelle Initalisierung mit dem Programm (s.o.)
funktioniert aber!

Nach tagelangem Tüfteln (Die Init-Sequenz kann ich inzwischen aus dem
FF eintasten!) weiß ich nicht mehr weiter. Die Antworten der MMC-Karte
müssten doch byte-aligned sein, oder?

Als letzte Antwort bleibt mir nur noch die Vermutung, dass irgendeine
Störung auf den Datenleitungen immer an genau der gleichen Stelle einen
Clock-Impuls erzeugt. Ich benutze den "simplen" Schaltplan von Ulrich
Radig. Die Kabellängen sind ungefähr: mega-Board - 15 cm Flachbandkabel
- Steckbrett - 10 cm Kabel zum MMC-Sockel.

Ich würde mich sehr freuen, wenn mir jemand auf die Sprünge helfen
könnte! Danke schonmal.
Gast #309154
Lesenswert?

> Vmtl. wird bei dir irgendwo ein bit verschluckt.

Könnte das an meiner Hardware liegen?

> Oder passt vielleicht deine Clock Polarität nicht?

Doch, die passt schon, denke ich. Wenn sie nicht passen würde, würde
ich die Karte mit dem Programm ja überhaupt nicht initialisiert
kriegen. Beim manuellen Eintasten prüfe ich auch an allen möglichen
Stellen: vor der ersten, nach der ersten, nach der zweiten Flanke. Wie
ich es drehe und wende: Die Anzahl der Einsen stimmt einfach nicht.
Zwar an unterschiedlichen Stellen, aber immer reproduzierbar.
Sicherheitshalber hab ich aber auch schon verschiedene
Clock-Einstellungen ausprobiert.
Gast #309155
Lesenswert?

Es ist zum Mäusemelken! Seit Tagen immer wieder das gleiche!

Egal mit welchem Code, egal ob mit Software oder Hardware-SPI! Meine
Karten antworten nicht so, wie sie laut Spec sollten.

Initialisierung funktioniert. Als Antwort auf die Frage nach dem CSD
kommt immer FF00FFFC01C0001E... (Dabei müsste ja **00**FE... kommen)
Das seit Tagen. Immer gleich, immer reproduzierbar, egal wie ich die
Karte anspreche. Dass da so systematisch Bits verloren gehen, kann ich
einfach nicht glauben!

verzweifel
Gast #309156
Lesenswert?

Wie schon jemand sagte, du liesst entweder auf der falschen Flanke ein
oder es stimmt irgendwas anderes nicht mit deinem Takt. Es stellt sich
z.B die Frage wieviel Pause du nach dem aktivieren der Karte mit CS
laesst bis du die rannimmst.

Olaf
Gast #309157
Lesenswert?

Ein Kolege von mir hatte auch so ein ähnliches Problem. Ich weiß jetzt
nicht genau was die Ursache war, aber evtl.
Leitungskapazitäten->kürzere Leitungen verwenden oder mal mit einem
Pull-Up Widerstand in der Datenleitung versuchen.
Gast #309158
Lesenswert?

Danke für Deine Antwort.

Das habe ich schon so oft überprüft! Natürlich kann man an der falschen
Flanke lesen, aber dann müsste ja auch das Initialisieren mit CMD0 und
CMD1 nicht richtig funktionieren. (CMD0, Antwort: FF01; CMD1, Antwort:
FF01 (nach 1 oder 2 weiteren Versuchen) FF00)

Der Code sollte auch einigermaßen erprobt sein. So habe ich unter
anderem Ulrich Radigs Hardware-SPI-Code fast unverändert übernommen.
(Nur die Erhöhung des Taktes auskommentiert.) Dort - wie überall - Init
funktioniert. CMD9 liefert FF00FFFC01C0...

Bei Ulrich Radigs Software-SPI-Code musste ich ein paar nop()s
einbauen, bis das Init lief. Ich habe die Wartezeiten sogar auf halbe
Sekunden ausgedehnt. Immer wieder FF00FFFC01C0.

Nachdem CS auf 0 gegangen ist, kann ich warten solange ich will - auch
mehrere Dummy-Bytes senden. Init klappt. Die Antwort auf CMD9 ist immer
FF00FFFC01C0...
Gast #309159
Lesenswert?

Ich hab's!

Nach wochenlangem Rumprobieren hab ich endlich die Lösung gefunden.
MMCs (das hatte ich heute im Internet gelesen) sind sehr wählerisch,
was die Flankensteilheit des Clock-Signals angeht.

Bei einer unsauberen Flanke verstehen zwar alle Befehle und antworten
auch mit der richtigen Anzahl an Bytes, allerdings sind die Antworten
nicht immer richtig. Das Dumme ist, die Antworten sind unabhängig von
der Taktfrequenz und - das ist das besonders ärgerliche -
reproduzierbar. Ich habe hier tausende Male immer wieder die gleiche
Antwort von meiner MMC erhalten.

Für's Archiv nochmal die Symptome: Im SPI-Modus funktioniert das
Initialisieren wunderbar. Bei Befehlen mit Daten-Antwort kommen aber
verfälschte Daten an. Dies merkte ich insbesondere am Fehlen des
Startbytes 0xFE.
Auch im MMC-Modus klappte das Initialisieren. Aber schon die letzte
Antwort (auf CMD3) lieferte den falschen Commando-Code (bei mir 2)
zurück.

In beiden Fällen benutzte ich einen Spannungsteiler zum Pegel-Wandeln
und einen ATmega16. Wie gesagt funktionierte die Karte dabei nur
teilweise. Nachdem ich Clock nun direkt (also mit 5V) an die Karte
gelegt habe, sind alle Antworten protokoll-getreu wie erwartet. Laut
MMC-Spec muss die CLK-Flankensteilheit <10ns sein.

Viele Grüße
#1538780
Lesenswert?

hi,

ich hab genau das selbe Problem ...

Ich habe mir für teuer geld bei display3000 ein SD-Karten Modul gekauft
http://www.display3000.com/downloads/P001_Manual_d.pdf

ich hoffe doch nicht das die lösung ist
[quote]
Nachdem ich Clock nun direkt (also mit 5V) an die Karte
gelegt habe, sind alle Antworten protokoll-getreu wie erwartet. Laut
MMC-Spec muss die CLK-Flankensteilheit <10ns sein.
[/quote]


kann es sonst noch einen grund geben das anstatt 0xfe 0xfc kommt ?

danke,Stefan

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren