Das Board einzeln betrachtet kann ich am Oszi erkennen, das CANH und
CANL laufen, es wird also versucht die Message zu verschicken. Soll
heißen die Pegel sind da.
Wenn ich nun aber die beiden Boards miteinander verbinde (CANh>CANh;
CANl>CANl: GND>GND) sind keine Pegel mehr vorhanden und es findet
schlussfolgerich auch keine Datenkommunikation statt.
Woran könnte das liegen?
Vielleicht doch an den 2x 62 Ohm Abschlusswiederständen? Mir ist klar,
das es 2x 60Ohm sein sollten, aber ich hatte nur 62 Ohm Widerstände da.
Zudem hatte ich einige Boards mit 2x 62'er gesehen, wie z.B:
https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/resources/LPC-P11C24_revision_A_sch.pdf
Viele Grüße,
Uwe
Einen Unterschied zum Olimex Board gibt es bzgl. der Versorgung. Denn
die Jungs von Olimex haben VDD_CAN entgegen des Datenblattes mit 5V
versorgt und ich auf meinem Board mit 3V3.
So ist es auch auf Seite 54 Bild 28 festgelegt worden:
http://www.nxp.com/documents/data_sheet/LPC11CX2_CX4.pdf
Zudem steht im DB auf Seite 35 das VDD_CAN = VDD sein muss.
Daran dürfte es also nicht liegen?!
Uwe schrieb:> Keiner eine Idee?
Verschiedene. Aber ohne den Code, den ganzen Code und nichts weiteres
als den Code kann ich nicht sagen ob meine Ideen auch nur annähernd Sinn
machen.
Aber da wäre zB. die Überlegung ob vielleicht beide Controller versuchen
die gleiche Message-IDs zu benutzen...
Also an der Spannungsversorgung liegt es nicht. Das mache ich genauso.
Und ob nun 60 oder 62Ohm Abschlusswiderstand dran ist, ist auch egal.
Jedenfalls bei den kurzen Leitungen.
Wie und mit was misst du den? Hast du mal nachgesehen ob der
error-Callback Handler gerufen wird und den Bus abschaltet?
Wenn du ein Filter für 0x400-0x4FF einbaust und 0x345 sendest, ob dann
wohl der rx-Handler gerufen wird? Wenn beide Boards auf der gleichen Id
senden, ist es auch nicht gerade das was sich die CAN-Erfinder
ausgedacht haben. Für weitere Hilfe wäre der komplette Code interessant.
Für mich sieht es so aus, als ob der Transfer läuft und du die kurzen
Telegramme von vielleicht 200µs Länge nicht siehst.
Wenn beide Boards einzeln gehen:
Schalte beide Bords zusammen, wie von die beschrieben.
Ein Board läßt du im Reset, das andere sendet.
Bei korrekter Hardware müßte es sich nunmehr so verhalten, als würdest
Du ein Board einzeln messen.
Und:
Wie testet du beide Boards zusammen? senden beide das gleiche oder
empfängt eines?
CAN bus an beiden Kabelenden zwischen CAN-_Lo und CAN_Hi mit 120 Ohm
abschliessen. Wenns bei kurzen Kabeln (unter 5Meter) nur an einem Ende
abgeschlossen ist, läufts meistens auf dem Schreibtisch auch noch
problemlos.
Wenn also gar keine Signale mehr zu sehen sind, liegt eher ein anderer
Fehler vor.
Stimmt die Baudrate?
Wie stehen im Empfangs-Chip die Status-Flags? Transmit pending, Data
Overrun, Error/Warning Level, Bus Off?
Uwe schrieb:> die Jungs von Olimex haben VDD_CAN entgegen des Datenblattes mit 5V> versorgt und ich auf meinem Board mit 3V3
Genau daran liegt es, der LPC11C22 ist ein Dual-Package LPC11C12 und
5V-CAN-Transceiver und der braucht seine 5V
Lothar schrieb:> Genau daran liegt es, der LPC11C22 ist ein Dual-Package LPC11C12 und> 5V-CAN-Transceiver und der braucht seine 5V
Das Datenblatt sagt aber was anderes! Die Jungs von Olimex betreiben den
LPC11C24 ausserhalb des erlaubten.
Steffen Rose schrieb:> Schalte beide Bords zusammen, wie von die beschrieben.> Ein Board läßt du im Reset, das andere sendet.>> Bei korrekter Hardware müßte es sich nunmehr so verhalten, als würdest> Du ein Board einzeln messen.
Genau das konnte ich reproduzieren. Zudem lasse ich beide Boards für
Testzwecke in einer Endlosschleife Messages schicken. Wenn ich nun beide
Board über CAN verbinde, sehe ich nun auch saubere CAN Pegel mit dem
Oszi. Einen Hardwarefehler kann ich wohl ausschließen, oder?
temp schrieb:> Für mich sieht es so aus, als ob der Transfer läuft und du die kurzen> Telegramme von vielleicht 200µs Länge nicht siehst.
Das wird es wohl gewesen sein.
temp schrieb:> Hast du mal nachgesehen ob der> error-Callback Handler gerufen wird und den Bus abschaltet?
Einen Error Handler habe ich jetzt eingebaut, und der wird auch
aufgerufen. Anscheinend wird der Bus wohl abgeschaltet.
temp schrieb:> Wenn du ein Filter für 0x400-0x4FF einbaust und 0x345 sendest, ob dann> wohl der rx-Handler gerufen wird?
Der RX Handler wird nicht aufgerufen. Ich weiß nicht warum. Eigentlich
müsste er das.
Eric B. schrieb:> Verschiedene. Aber ohne den Code, den ganzen Code und nichts weiteres> als den Code kann ich nicht sagen ob meine Ideen auch nur annähernd Sinn> machen.> Aber da wäre zB. die Überlegung ob vielleicht beide Controller versuchen> die gleiche Message-IDs zu benutzen...
Den Code zum Testen der Boards habe ich beigefügt. Ich habe ein Beispiel
Code vom lpcexpresso etwas modifiziert und eine UART Ausgabe eingebaut.
Da nun ein Hardwarefehler wohlmöglich ausgeschloßen werden kann, bleibt
das Problem mit nicht ausführen des RX Handlers... Ich möchte gerne die
msg_id hochzählen und zurückschicken..Die beiden Boards sollten quasi
PingPong spielen.
Und, vielen Dank an alle für die sehr hilfreichen Hinweise. Hoffe ihr
könnt mir auch beim letzten Problem noch helfen.
Lothar schrieb:> Genau daran liegt es, der LPC11C22 ist ein Dual-Package LPC11C12 und> 5V-CAN-Transceiver und der braucht seine 5V
Lies erst mal das Datenblatt. VDD_CAN ist die Spannung des Transceivers
auf der RX,TX Seite. Also geht sowohl 3,3V als auch 5V da die Eingänge
des LPC 5V fest sind. 3,3V ist aber sicher die richtige Wahl.
Die 5V für die CAN-Bus liegen an VCC.
aus dem Datenblatt:
VDD_CAN - Supply voltage for I/O level of CAN transceiver.
VCC - Supply voltage for CAN transceiver.
GND - Ground for CAN transceiver.
Frank K. schrieb:> Besorge Dir einen definitiv funktionierenden CAN-Knoten und teste> gegen diesen. Das erleichtert die Fehlersuche erheblich.>> fchk
Ich denke, das ich ein Software Problem habe. Die Hardware scheint zu
funktionieren.
Uwe schrieb:> Das Datenblatt sagt aber was anderes! Die Jungs von Olimex betreiben den> LPC11C24 ausserhalb des erlaubten.
Laut Datenblatt kann VDD_CAN bis 5.5V (sollte aber mit 3.3V laufen
sofern die 3.3V Quelle ausreichend Strom liefern kann). Aber nochmal,
das ist ein vom LPC physisch getrennter Chip, die Stabilität ist besser
wenn einheitlich mit 5V versorgt wird (kannst Du nachmessen !)
VDD_CAN=VCC=5V
Lothar schrieb:> die Stabilität ist besser> wenn einheitlich mit 5V versorgt wird (kannst Du nachmessen !)> VDD_CAN=VCC=5V
Das musst du mal erklären, was du da unter Stabilität meinst. Und wo
bitte willst du das nachmessen? Die CAN-Pegel nach außen sind sind von
VCC abhänging. Die Versorgung des Cortex-Chips heißt VDD!
Aus dem Datenblatt:
VCC
====
supply voltage 4.5 - 5.5 V
ICC supply current Silent mode 0.1 1 2.5 mA
Normal mode
recessive 2.5 5 10 mA
dominant; CAN_TXD = LOW 20 50 70 mA
VDD_CAN
========
2.8 - 5.5 V
IDD supply current on pin VDD_CAN; Normal and Silent
modes
recessive: CAN_TXD = HIGH 10 80 250 µA
dominant: CAN_TXD = LOW 50 350 500 µA
VDD_CAN bestimmt nur den IO-Pegel im inneren des Chips, und max 500µA
sollten auf der 3,3V Seite immer drin sein.
Nachdem ich den Code jetzt angepasst habe, findet eine saubere
Datenkommunikation statt. Danke an alle für die nützlichen Hinweise.
Lothar schrieb:> Uwe schrieb:> Das Datenblatt sagt aber was anderes! Die Jungs von Olimex betreiben den> LPC11C24 ausserhalb des erlaubten.>> Laut Datenblatt kann VDD_CAN bis 5.5V (sollte aber mit 3.3V laufen> sofern die 3.3V Quelle ausreichend Strom liefern kann). Aber nochmal,> das ist ein vom LPC physisch getrennter Chip, die Stabilität ist besser> wenn einheitlich mit 5V versorgt wird (kannst Du nachmessen !)> VDD_CAN=VCC=5V
Im Datenblatt steht das vdd_can = vdd sein muss, und vdd verträgt keine
5v.
Uwe schrieb:> Frank K. schrieb:>> Besorge Dir einen definitiv funktionierenden CAN-Knoten und teste>> gegen diesen. Das erleichtert die Fehlersuche erheblich.>>>> fchk>> Ich denke, das ich ein Software Problem habe. Die Hardware scheint zu> funktionieren.
egal. Der andere CAN-Knoten hat ja seine eigene Software, und wenn Du
die als funktionierend voraussetzen kannst, hast Du schon viel gewonnen.
Ich habe für solche Projekte das hier bereitliegen:
http://www.peak-system.com/PCAN-USB.199.0.html
Uwe schrieb:> Im Datenblatt steht das vdd_can = vdd sein muss, und vdd verträgt keine> 5v.
So isses. Etwas paradox, aber das kommt durch tatsächlich 2 separate
Chips: MC und Transceiver.
Kurzum: Der Transceiver benötigt für den Bus 4.5 -5.5 V. VDD_CAN erlaubt
2.8 - 5.5 V. Und VDD_CAN muß gleich VDD des MC sein. Der MC darf aber
max. 3.6 V abbekommen.
Übrigens:
msg_obj.msgobj = 0;
ist falsch. Sie werden von 1 - 32 nummeriert. "Null" wird als 32
interpretiert. Bei diesem deinem Test ist das egal, aber wehe, du
benutzt mal mehr boxen oder gar explizit die 32 (natürlich beim
Empfangen). Dann wunderst du dich über unlogisches verhalten!