Guten Tag,
Ich bin Umsteiger von anderen Prozessoren hin zu ARM7 von Philips,
geaugenommen den LPC2378. Hierbei geht es im wesendlichen um die Can
Busverbindung. Entwicklungsboards und andere Prozessoren erzeugen den
gleichen Fehler.
Bevor jetzt einige schon aufhören zu lesen, alles klappt bis auf dieses
Problem einwandfrei. Ich muss aber etwas mehr ausholen.
Ich arbeite mit 11 Bit Identifier und daher mit entsprechenden IDs. Der
Bus läuft mit 500000 Baud. Ich kann völlig problemlos kommunizieren bei
wenig Stess auf dem Bus, alles ist korrekt mit 120 Ohm abgeschlossen und
meine Umgebung ist im wesendlichen innerhalb von 6m angeschlossen.
Jetzt die erschwerenden Umstände. Ich bin nicht alleine am Bus sondern
gut 10 Teilnehmer schicken lustig Daten hin und her. Die Sendeabstände
liegen meistens zwischen 100ms und 1s, teilweise aber auch weit unter
10ms. Dafür ist die Datenlänge aber nicht so happig, etwa 1 bis 20
Nachrichten am Stück, dann mit längerer Pause.
Ich besitze mehrere PCAN Module (Can Monitore Hard & Software) die
einwandfrei funktionieren. (Ohne meine LPC)
Jetzt das Problem, nur wenn ich schicke erscheinen plözlich
unwahrscheinliche Daten auf dem Bus, (ca. 1 von 10) in der Regel unter
ID 100. Zunächst habe ich vermutet ich schicke vielleicht irgendein
Wirrwar, aber dem ist nicht so. Es scheint so zu sein das mein LPC2378
die Nachrichten anderer verstümmelt, indem verbotener Weise gesendet
wird während ein anderer noch arbeitet. Meine Nachrichten können sowohl
sehr schnell als auch langsam abgeschickt werden, das macht keinen
Unterschied. Meine Meldungen sind völlig harmlos und werden alle 800ms
geschickt. Länge ca 6 Nachrichten.
Meine Vermutung ist, das der Can Stack auf Hardwarebene nicht richtig
arbeitet, für mein verständnis muß solange gewartet werden bis der Bus
frei ist.
Aufgrund der Hektik auf dem Bus ist bei mir der ACCeptance Filter
aktiviert, der bei mir 3 IDs herausfischt, also nichts besonderes. Wie
gesagt liegt es auch nicht am Empfang, den kann ich auch abschalten, nur
senden verursacht bei stressigen Bus, diese Fehler. Leider ist auch kein
Muster zu erkennen, verdächtig ist nur das die meisten (aber nicht alle)
verstümmelten Nachrichten unter ID100 sind.
Währe nett wenn mir einer vieleicht änliche Fehler oder gar Lösungen
sagen kann. Die ERRATA und viel Suche bin ich durch. Das Problem ist
etwas zu suchen was man nicht weiß.
Bei vielen ist dieser Fehler vieleicht noch gar nicht aufgetreten, bei
mir kommen teilweise doch recht gefährliche Sachen dabei heraus, da die
Nachtrichten nicht 0000 sind.
Da nur mein Modul diese Fehler verusacht gehe ich davon aus das alles
andere korrekt ist.
BERNHARD schrieb:
> Jetzt die erschwerenden Umstände. Ich bin nicht alleine am Bus sondern> gut 10 Teilnehmer schicken lustig Daten hin und her.
Das ist nicht erschwerend, sondern CAN-Bus Alltag.
Der CAN-Bus arbeitet bis 100% Traffic einwandfrei.
Der CAN-Bus erlaubt es explizit, daß mehrere Teilnehmer gleichzeitig
senden. Das Paket wird dabei nicht zerstört, sondern einer gewinnt.
Ein Problem ist, wenn 2 Teilnehmer den gleichen Identifier senden, dann
wird keine Kollision erkannt und die Daten werden korrumpiert.
Dieser Fall muß also vermieden werden.
Z.B. dadurch, daß der Identifier die Sender- und die Empfängeradresse
beinhaltet.
Ich kenne jetzt den LPC2378 nicht, vielleicht hat der ja einen Bug.
Oder es liegt ein Fehler in Deiner Software vor.
Peter
Das ist nicht erschwerend, sondern CAN-Bus Alltag.
Genau das wollte ich auch damit sagen, daher verstehst du ja jetzt mein
Anliegen.
Daher ja auch die Frage was das sein kann, schließlich hat ja wie du
sagst die Software damit gar nichts zu tun.
Kollisionsvermeidung ist Sache von Can selber. Vieleicht kennt ja einen
die Eigenheiten des 2378. Ist ja auch nicht mehr so neu.
Habe langsam das Gefühl, das der Prozessor Bugs hat. Wahrscheinlich
haben die bei NCP nie einen Belastungstest gemacht.
Würde mich echt mal interessieren wer damit mit Dauerbelastung
herumexperimentiert. Habe jetzt drei Testschaltungen, von jeglichen
Ballast befreit und nichts läuft wirklich zufriedenstellen.
>Habe langsam das Gefühl, das der Prozessor Bugs hat.
Jeder ist mal an der Reihe, jetzt eben Du :-)
Ohne die genauen Abläufe zu kennen: es hört sich für mich so an, als
würden Interrupts ggf. an unpassenden Stellen auftreten. Das sind meist
Gründe für sporadische Fehlfunktionen.
Wenn Du Interrupts verwendest, vielleicht mal auf Polling reduzieren?
Die meisten CAN-Kontroller haben einen Loop-Back-Modus.
Der ermöglicht das der Kontroller seine eigenen Frames bestätigt.
Wenn dieser Modus noch eingeschaltet ist, kann es sein das er nicht auf
den Bus lauscht um festzustellen ob er frei ist oder ob sein Frame die
nidrigste ID hat.
@BERNHARD
Wie Peter schon gesagt hat, falls ein Identifier doppelt sein kann, also
von mehr als einem Sender verwendet wird, funktioniert die
Hardwarepriorisierung im CAN so, dass im Prinzip immer die Nullen
gewinnen (wie oft im richtigen Leben ;-) Die eigentliche Nachricht wird
also verundet / verstuemmelt.
Ansonsten gibt es fuer den LPC2378 ein Errata Sheet, ist aber fuer den
CAN jetzt fast sauber. Es gibt noch ein Problem, hoert sich aber nicht
unbedingt nach deinem an.
Im uebrigen hat der Prozessor meines Wissens keinen Bug. Ein CAN Problem
hat mit den Prozessor ungefaehr so viel zu tun wie das Autoradio mit dem
Motor, beide sind im selben Fahrzeug aber keiner wuerde vom Motorschaden
sprechen, wenn der Sendersuchlauf nicht mehr funktioniert.
Robert
http://www.lpc2000.com
Da ich doch tatsächlich das gleiche Problem hatte mit einen 2364, sollte
man die eigene Blindheit beim Fehlerlesen nicht vergessen.
Durch einen guten Tip habe ich gesehen das die DLC Länge falsch gesetzt
war, obwohl ich dann aber z.B. 8 Datenbytes schicke.
Das Ergebnis war ähnlich wie bei dir, bei hohem traffic wurden plötzlich
die Daten verfälscht ohne Fehlermeldung.
Schau mal genau was du das in die Register schmeißt ohne Umwege über
Variable.
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
