mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MMC-Antworten nicht byte-aligned?


Autor: mh. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Mark Schau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Karte antwortet sicher mit 8-bit.

Vmtl. wird bei dir irgendwo ein bit verschluckt. Oder passt vielleicht
deine Clock Polarität nicht?

Autor: mh. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: mh. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: MartinS (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: mh. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: mh. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, dass du die Lösung des Problems mitgeteilt hast. Ein Grund mehr
vernünftige Level-Shifter zu benutzen wenn man welche braucht.

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Macht das der Karte nichts, wenn man 5V auf den Clock jagt?

Autor: mh. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also meine Karte hat die 5V problemlos überlebt. Dauerhaft werde ich das
aber auch nicht machen. Ist ja schließlich schon ein ganzes Stück
außerhalb der Spec.

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, gut zu wissen...


Gruß Daniel

Autor: Stefan Gehdinixan (der-qwertz)
Datum:

Bewertung
0 lesenswert
nicht 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

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.