mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MCP2515 - Registerdaten werden falsch gespeichert


Autor: Michael S. (affenbingo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mit dem ATMEGA48, dem MCP2515 und dem SN65HVD1050 einen 
CAN-Knoten aufgebaut. Diesen Knoten habe ich so konfiguriert, daß ich 
erst einmal nur am CAN-Bus lesend teilnehme. Mit einem CAN-Interface 
habe ich dann Nachrichten versendet.

Das Problem:
Die empfangenden Nachrichten hatten immer mindestens einen Bitfehler in 
der ID z.B. statt 0x635 wurde 0x63D gelesen.

Auf der Suche nach der Ursache ist mir beim durchsehen der Konfiguration 
des MCP2515 aufgefallen, daß die Konfigurationswerte nicht mit den 
gesendeten Werten übereinstimmten.

Um den Effekt darzustellen habe ich eine Schleife eingebaut, die 
Register des MCP2515 schreibt und dann wieder ausliest.
(-> Oszilloskop-Screenshots)

http://www.imagebam.com/image/0057e327876636
http://www.imagebam.com/image/a72fe127876637
http://www.imagebam.com/image/86081a27876638
http://www.imagebam.com/image/86081a27876638
http://www.imagebam.com/image/8b3a5127876639
http://www.imagebam.com/image/73ef2827876640
http://www.imagebam.com/image/56fd1d27876641
http://www.imagebam.com/image/229d9627876642
http://www.imagebam.com/image/91232327876643

Vor der while-Schleife hatte ich bereits den Filter für RXB0 gesetzt auf
RXF0SIDH: 0xC6 (Maske: 0xFF)
RXF0SIDH: 0xA0 (Maske: 0xFF)
um bei meinem ursprünglichen Vorhaben nur die StandardID 0x635 zu 
empfangen. Ausgelesen aus den Registern des Filters habe ich aber das 
hier:
http://www.imagebam.com/image/0e811d27876644
http://www.imagebam.com/image/f53fe227876645
Seltsamerweise entsprechen die Werte aus RXF0, denen die ich beim Lesen 
von RXB0 (siehe Anfangsproblem) bekomme.

Ich habe zuerst Vermutet es liegt am Reset des MCP2515, aber da ich 
jetzt alle Varianten mit Softreset, Hardreset (15k, 1nF), sowie Reset 
per ATMega-Port-Pin ausprobiert habe schließe ich das aus.Diese Test 
habe ich auf 3 verschiedenen MCP2515 durchgeführt, aber bei allen war es 
der selbe Effekt.

Also lange Rede kurzer Sinn. Aus irgendeinem Grund wird das zuletzt 
gesendete Nibbel verschluckt und vom MCP2515 als 0xF interpretiert. Hat 
jemand diesen Effekt auch schon bei sich beobachtet oder fällt jemandem 
etwas ein was ich übersehen haben könnte.

Ok, vielen Dank fürs Zuhören!

Mit freundlichem Gruß
Michael

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der MCP2515 funktioniert am AVR. Ist also kein prinzipielles Problem, 
sondern eines bei dir. SPI falsch konfiguriert? Code?

Autor: Michael S. (affenbingo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo A.K.,

das SPI-Interface funktioniert soweit ganz gut und die Timings des 
MCP2515 sind soweit auch eingehalten wie es die Spezifikation vorgibt 
(siehe Screenshots).
Den Code habe ich trotzdem angehängt zur Kontrolle. Der Code sieht vor 
beide SPI-Interfaces des ATMega48 zu benutzen, je nach Wunsch.

MfG

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und welcher der beiden SPIs wird verwendet?

Autor: Michael S. (affenbingo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry! Verwenden tue ich nur das Standard-SPI-Interface.

Autor: Michael S. (affenbingo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. hilft Euch noch der MCP2515-Intialisierungs-Code (siehe Anhang) 
und noch ein Screenshot vom Einschaltmoment.

http://www.imagebam.com/image/02529f27897369

MfG

Autor: Michael S. (affenbingo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe das Problem mit den Registerdaten lösen können.

Lösung:
In spi_read() das Dummybyte auf 0xFF setzen und ein 10k 
Pull-DOWN-Widerstand an SO.

Ich habe nochmal die Literatur gewälzt auf der mein Versuch basiert und 
da ich mich am Anfang am Tutorial vom kreativen-chaos orientiert habe 
(http://www.kreatives-chaos.com/artikel/ansteuerung...) ist 
mir in der Einleitung zum Register-Lesen das hier ins Auge gesprungen
Um ein Byte zu empfangen muss man also ein Dummy-Byte
BELIEBIGEN Inhalts auf den Bus legen und dabei die Daten
auf der Empfangsleitung auswerten.
Bei mir war das Dummybyte 0x00. Das hab ich geändert auf 0xFF und siehe 
da, die Registerdaten wurden teilweise richtig ausgegeben. Aber nur 
teilweise. Die Ausgaben des MCP2515 "zuckten" öfter mal auf fehlerhafte 
Bytes. Abhilfe hat hier ein Pull-Down-Widerstand gebracht.

Noch ein Hinweis:
Ich habe verschiedene Dummybytes ausprobiert, aber NUR 0xFF hat immer 
richtige Ergebnisse produziert, also stimmt die Aussage mit dem 
"beliebigen Inhalt" in dem oben genannten Tutorial für meinen Fall nicht 
so ganz. Trotzdem an dieser Stelle ein großes Danke an den Autoren des 
Tutorials, es war sehr hilfreich beim Einarbeiten in die Fähigkeiten des 
MCP2515.

Im Anhang der funktionierende SPI-Code für den ATMega48.

Mit freundlichem Gruß
Michael

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.