Weiterhin Probleme mit CAN auf LPC11C22

[Uwe (Gast)]

Ich habe dieses Board 2x aufgebaut:
Beitrag "Re: LPC11C22 Board Feedback"

Schaltplan:
http://www.mikrocontroller.net/attachment/249445/lpc11c22_schaltung.PNG

Die CAN Terminierung habe ich basierend auf diesen Thread aufgebaut:
Beitrag "CAN Terminator"

Zum testen des CAN habe ich das ccan_rom example des nxp_lpcexpresso 
genommen und die Board Files entsprechend meines Boards angepasst und 
auf beide Board programmiert.

Auszüge aus relevanten Stellen:

#define TEST_CCAN_BAUD_RATE 500000

/* Send a simple one time CAN message */
  msg_obj.msgobj  = 0;
  msg_obj.mode_id = 0x345;
  msg_obj.mask    = 0x0;
  msg_obj.dlc     = 4;
  msg_obj.data[0] = 'T';  // 0x54
  msg_obj.data[1] = 'E';  // 0x45
  msg_obj.data[2] = 'S';  // 0x53
  msg_obj.data[3] = 'T';  // 0x54
  LPC_CCAN_API->can_transmit(&msg_obj);

  /* Configure message object 1 to receive all 11-bit messages 0x400-0x4FF */
  msg_obj.msgobj = 1;
  msg_obj.mode_id = 0x400;
  msg_obj.mask = 0x700;
  LPC_CCAN_API->config_rxmsgobj(&msg_obj);

void CAN_rx(uint8_t msg_obj_num) {
  /* Determine which CAN message has been received */
  msg_obj.msgobj = msg_obj_num;
  /* Now load up the msg_obj structure with the CAN message */
  LPC_CCAN_API->can_receive(&msg_obj);
  Chip_UART_SendRB(LPC_USART,&txring, ready, sizeof(ready) - 1);
  if (msg_obj_num == 1) {
    /* Simply transmit CAN frame (echo) with with ID +0x100 via buffer 2 */
    msg_obj.msgobj = 2;
    msg_obj.mode_id += 0x100;
    LPC_CCAN_API->can_transmit(&msg_obj);



    Chip_UART_SendRB(LPC_USART,&txring, msg_obj.data, sizeof(msg_obj.data) - 1);


  }
}

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

[Uwe (Gast)]

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 (Gast)]

Keiner eine Idee?

[Eric B. (beric)]

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...

[temp (Gast)]

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.

[Steffen R. (steffen_rose)]

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?

[Martin (Gast)]

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?

[Lothar (Gast)]

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

[Uwe (Gast)]

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.

[Frank K. (fchk)]

Besorge Dir einen definitiv funktionierenden CAN-Knoten und teste gegen 
diesen. Das erleichtert die Fehlersuche erheblich.

fchk

[temp (Gast)]

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.

[Uwe (Gast)]

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.

[temp (Gast)]

Na so wird das mit deinem Code aber nichts, der initialisiert die 
CAN-Einheit in der Schleife zu Tode:

while (1)
  {
  // hier beginnt die Initialisierung in einer Schleife?   


  baudrateCalculate(TEST_CCAN_BAUD_RATE, CanApiClkInitTable);

  LPC_CCAN_API->init_can(&CanApiClkInitTable[0], TRUE);
  /* Configure the CAN callback functions */
  LPC_CCAN_API->config_calb(&callbacks);
  /* Enable the CAN Interrupt */
  NVIC_EnableIRQ(CAN_IRQn);

  /* Send a simple one time CAN message */
  msg_obj.msgobj  = 0;
  msg_obj.mode_id = 0x345;
  msg_obj.mask    = 0x0;
  msg_obj.dlc     = 4;
  msg_obj.data[0] = 'T';  // 0x54
  msg_obj.data[1] = 'E';  // 0x45
  msg_obj.data[2] = 'S';  // 0x53
  msg_obj.data[3] = 'T';  // 0x54
  LPC_CCAN_API->can_transmit(&msg_obj);

  // so jetzt ist die Message im Buffer aber noch lange nicht versendet
  // bis zur nächsten Initialisierung dauert es nur ein paar µs. Da ist
  // deine Msg noch lange nicht versendet
  // wenn du nicht den erfolg im tx-Handler prüfen willst,
  // solltest du wenigstens ein delay einbauen 
  // 

  /* Configure message object 1 to receive all 11-bit messages 0x400-0x4FF */
  // wie oben schon mal erwähnt. Du baust ein Filer ein das nur 0x400-0x4ff
  // durchlässt und sendest 0x345... probiers mal mit 0x400

  // das Empfangsfilter initialisiert man auch nicht in einer Schleife
  msg_obj.msgobj = 1;
  msg_obj.mode_id = 0x400;
  msg_obj.mask = 0x700;
  LPC_CCAN_API->config_rxmsgobj(&msg_obj);
  }

  // und hier kommst du sowieso nie an
  while (1) {
    __WFI();  /* Go to Sleep */
  }
}

[temp (Gast)]

also zum Testen ungefähr so:

void main()
{
  ....... 

  baudrateCalculate(TEST_CCAN_BAUD_RATE, CanApiClkInitTable);

  LPC_CCAN_API->init_can(&CanApiClkInitTable[0], TRUE);
  /* Configure the CAN callback functions */
  LPC_CCAN_API->config_calb(&callbacks);

  // das Empfangsfilter initialisiert man auch nicht in einer Schleife
  msg_obj.msgobj = 1;
  msg_obj.mode_id = 0x400;
  msg_obj.mask = 0x700;
  LPC_CCAN_API->config_rxmsgobj(&msg_obj);

  /* Enable the CAN Interrupt */
  NVIC_EnableIRQ(CAN_IRQn);

  // aufpassen dass nur 1 Board sendet!
  if (Board1)
    {
    while (1)
      ;
    } 

  // und das bei dem anderen 
  while (1)
    {
    /* Send a simple one time CAN message */
    msg_obj.msgobj  = 0;
    msg_obj.mode_id = 0x400;
    msg_obj.mask    = 0x0;
    msg_obj.dlc     = 4;
    msg_obj.data[0] = 'T';  // 0x54
    msg_obj.data[1] = 'E';  // 0x45
    msg_obj.data[2] = 'S';  // 0x53
    msg_obj.data[3] = 'T';  // 0x54
    LPC_CCAN_API->can_transmit(&msg_obj);

    delay_ms(10);
    }
}

[Lothar (Gast)]

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

[temp (Gast)]

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.

[Uwe (Gast)]

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.

[Frank K. (fchk)]

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

[Lutz (Gast)]

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!