Forum: Mikrocontroller und Digitale Elektronik Canbus sendet nicht AT90CAN128 / STK600


von I. E. (anfaenger69)


Angehängte Dateien:

Lesenswert?

Ich habe einen AT90CAN128 auf ein STK600 gesteckt, mit 8MHz getaktet und 
mittlerweile 3 verschiedene Projekte ausprobiert, bei dem überall das 
gleiche Phänomen vorkommt.

Projekte:
Beitrag "CAN-Bibliothek für den at90CAN128 und das AVRStudio"
Beitrag "AT90CAN128 CAN senden mit WinAVR"
Beitrag ""Hello World" für CAN mit AT90CAN in C"

Alle habe ich mit AVR Studio 4.18 und WINAVR-20090318 kompiliert.

Wenn der AT90CAN128 das senden beginnen sollte, entsteht ein Signal wie 
im Anhang can.gif zu sehen. Dieser wiederholt sich immer wieder und das 
CANREC Register zählt bei jedem Takt Receive Errors hoch. Das CANTEC 
Register meldet sich ab und zu mit einem TRANSMIT ERROR wie auf dem Bild 
can2.gif zu sehen.

Um mal den Fehler auf der Hardware auszugrenzen habe ich folgende Tests 
durchgeführt:

- zweiten AT90CAN128 ausprobiert - gleiches Bild.
- Den Canbus Anschluss vom STK600 komplett abgesteckt und die Pins TXCAN 
und RXCAN am AT90CAN128 miteinander verbunden, damit der Controller 
wirklich merkt, dass er das gleiche Signal empfängt, als er auch heraus 
schickt - somit kann es schon mal nicht an dem angeschlossenen Canbus 
und seinen Geräten darauf liegen.
- Trotzdem auch mal den ADAPCAN01 an PORTD angesteckt - mit und ohne 
Canbus das gleiche Bild.
- Alle Frequenzen von 1MHz bis 16MHz durchprobiert...

Was könnte ich noch testen?

von H.Joachim S. (crazyhorse)


Lesenswert?

Hast du noch einen anderen CAN-Knoten dran? Nach Senden einer Botschaft 
wird ein ACK einer Gegenstation erwartet. Ansonsten geht der 
CAN-Controller davon aus, dass ihn niemand versteht. Versuchts noch ein 
paarmal und legt sich dann schlafen, um den Bus nicht weiter zu 
belästigen.

von Otto (Gast)


Lesenswert?

Hast Du auch einen weiteren Teilnehmer an den CAN angeschlossen ?

Otto

von I. E. (anfaenger69)


Lesenswert?

Ich habe ja auch mal testweise ganz ohen Canbus ausprobiert. Der 
Controller müsste doch zumindest sein SOF und 11-bit Identifier, DLC, 
den Inhalt und den CRC senden, bevor er auf ein ACK eines Empfängers 
wartet, aber selbst das wird nicht gesendet. Du siehst auf can.gif, dass 
er nur ein ca 300µs langes LOW singal von sich gibt und danach keine 
Identifier Adresse folgt...

Auch nach dem Einschalten / Reset sieht das erste Signal so aus...

Ich sehe es ja ein, dass er ein Arbitratiostest macht, aber dann sollte 
er doch alles als OK befinden, wenn TXCAN und RXCAN miteinander 
verbunden sind, oder nicht?

von I. E. (anfaenger69)


Lesenswert?

Ja, ich habe auch mal einen IXXAT USB-To-Can Controller daran 
angeschlossen gehabt. Er erkennt diese Sendeversuche vom AT90CAN128 
sofort als RX-Error.

von Otto (Gast)


Lesenswert?

> er doch alles als OK befinden, wenn TXCAN und RXCAN
> miteinander verbunden sind, oder nicht?

Nein - das ist doch kein ACK

von I. E. (anfaenger69)


Lesenswert?

Das soll ja auch klein ACK werden, sondern ich gaukele ihm mit der 
Brücke einen Bus vor, auf dem keine Arbitionsfehler entstehen. Aber dann 
müsste er doch zumindest bis zum erwarteten ACK alles heraus senden...

von I. E. (anfaenger69)


Angehängte Dateien:

Lesenswert?

Hier nochmal Einschaltverhalten auf can3.gif
70ms nach dem Reset beginnt er mit der ersten Sendung.
Auf can4.gif ist nochmal deutlich zu erkennen, dass er nicht einmal 
beginnt den 11-Bit Identifier zu senden. Bei diesen Signalen wird auch 
niemals ein ACK von irgendjemanden auf dem Bus kommen... Aber warum!?! 
Verzweifel kurz vor 2010 :c)

von Otto (Gast)


Lesenswert?

Hänge einen weiteren Teilnehmer dran, sonst wird das nichts.
Stelle beide Teilnehmer auf die selbe Baudrate und denke an die 
Terminierung.

von I. E. (anfaenger69)


Angehängte Dateien:

Lesenswert?

Mit einem IXXAT USB-To-CAN auf der anderen Seite sieht es genau so aus. 
Hier  nochmal ein Bild (can5.gif) vom TXCAN und RXCAN vom AT90CAN128, 
wenn der IXXAT noch mit auf dem Bus ist. Kein Unterschied.

Dann habe ich mal den TXCAN vom Controller abgehängt und den IXXAT 
senden lassen. Dieser wäre ja jetzt auch alleine auf dem Bus. Da erkennt 
man sofort, dass eine ID und Daten gesendet werden, bis er beim 
fehlenden ACK abbricht. Der AT90CAN128 sollte sich genauso verhalten, 
wenn er alleine auf dem Bus ist - zumindest bei der ersten Sendung 
gleich nach dem Reset...

von H.Joachim S. (crazyhorse)


Lesenswert?

Tjo, dann ist was mit der Software :-)
Ich hab den AT90CAN128 damals auch in die Ecke geschmissen, da ich es 
eilig hatte. MCP2515, der geht problemlos.
Wollte mich nochmal dransetzen, bis jetzt noch nicht gemacht.

von Otto (Gast)


Lesenswert?

Weshalb hängst Du ein CAN-USB-Interface dran - das antwortet doch auch 
nicht von alleine - ohne "echten Teilnehmer" wird das nichts !

von I. E. (anfaenger69)


Lesenswert?

Hab den Fehler gefunden. Ich habe am Port D6 vom STK600 zwar noch die RX 
Signale gesehen, aber am TQFP Sockel am Prozessor direkt kamen sie nicht 
mehr an. Da war eine Unterbrechung zwischen der STK600 Routing Karte und 
der Sockel Karte. Nach abbauen und wieder montieren kamen die RXCAN 
Signale dann endlich zum Prozessor.

Mit dieser Unterbrechung hatter er natürlich Arbitionsfehler und brach 
die Sendung sofort ab, bevor die ID Gesendet wird.


Aber nochmals: Warum denken alle, dass mann einen Teilnehmer auf dem CAN 
Bus haben muss? Bis zum erwarteten ACK muss der Prozessor auf jeden Fall 
seine ID (und mehr) loswerden. Wenn er diese nicht sendet, kann es nicht 
am Teilnehmer liegen...

Jetzt kann Sylvester kommen :c)

von wikky (Gast)


Lesenswert?

HEY IGOR,

meinste es wäre möglich, dass du deinen code mal postest???
ich kämpfe (paar jährchen später) an deinem schon gelösten problem 
rum....................
wäre super, so kanntse mir bestimmt auf die sprünge helfen!!

GRÜßE

von Andreas T. (andreas_t)


Lesenswert?

Hallo Wikky,

folgende Erfahrungen habe ich gemacht, warum man Probleme mit einer CAN 
Kommunikation am STK600 hat:

BITRATE stimmt nicht zwischen Sender und Empfänger (Häufigste Ursache)

Kannst du überprüfen indem du dich mit einem Oszi z.B. auf den CANL Pin 
vom STK hängst. Zweiten Busteilnehmer am SUBD Port abstecken und CAN 
Baustein Message senden lassen. Dabei die Frequenz am Oszi messen. Dann 
das gleiche Prozedere nochmal nur CAN RXD und CAN TXD vom uC abstecken 
und anderen Busteilnehmer am SUBD Port anstecken - wieder die Frequenz 
messen. Wenn die Frequenzen nicht übereinstimmen, dann BITRATE entweder 
am uC oder am anderen Teilnehmer solange anpassen bis es passt, dann 
sprechen sie auch miteinander.

SLOPE CTRL Jumper nicht gesetzt (zweithäufigste Ursache)

Es muss unbedingt ein Jumper bei SLOPE CTRL gesetzt werden, damit der 
AT6660 nicht im StandBy bleibt, denn falls das der Fall ist wird keine 
Kommunikation stattfinden

TERM Jumper nicht gesetzt oder falsch terminiert(soll auch vorkommen)

Der TERM Jumper dient am STK dazu den Bus zu terminieren. Am Anfang und 
am Ende des Busses solltest du eine 120 Ohm Terminierung haben. Einfach 
Jumper setzen und passt. Übrigens irgendwelche Widerstände parallel oder 
in Serie zum TERM Jumper zu löten bringt nur Probleme (wird hier im 
Forum aber auch manchmal vorgeschlagen) und sollte nur dann gemacht 
werden, wenn man eine andere Terminierung gewählt hat, was normalerweise 
nicht der Fall ist.

So und ab hier beginnen die etwas selteneren Fehler:

Betriebsspannung STK falsch eingestellt oder zu niedrig

Manchmal und mit gewissen CAN zu USB oder CAN zu RS232 Konvertern gibt 
es das Problem, dass die Betriebsspannung des STKs über 5V sein sollte, 
da ansonsten die Pegel des CAN Buses nicht mehr zu den von den 
Konvertern erwarteten Pegeln passen. Einfach mal voll aufdrehen! 
Übrigens die Pegel kann man per Multimeter schön auf CANH und CANL 
abgreifen und die sollten bei 2.5V liegen, wenn nichts gesendet oder 
empfangen wird. Im Betrieb können sich die Pegel dann natürlich 
verschieben, sonst würde ja auch nichts übertragen.

Busteilnehmer lauscht nur aber identifiziert sich nicht

Eigentlich sollte bei einer Kommunikation zwischen zwei CAN Teilnehmern 
immer eine Quittierung einer Meldung mit ACK stattfinden. Manche 
Teilnehmer (Konverter zum Mitlauschen) machen das nicht automatisch, man 
muss sie dazu zwingen. Erst dann können Nachrichten ordungsgemäß 
empfangen werden.

von Stefan (Gast)


Lesenswert?

Hi,

auch ich nutze ein STK600 mit einem AT90CAN128. Ich habe die CAN-Lib vom 
Roboterclub-Aachen angepasst und die Bibliothek erstellt. Nun möchte ich 
testweise ein paar Datenrahmen ausgeben, aber es kommt nichts am 
PCAN-USB-Adapter an. Auch am Oszi kommen keine Flanken zustande.

Umgekehrt kann ich Datenpakete am Oszi sehen, wenn ich über den 
PCAN-Adapter etwas sende und die MCU vom ATA6660 trenne.

Die Tipps mit dem Slope-Control und dem Abschlusswiderstand habe ich 
berücksichtigt (Jumper auf Term + SlopeCtrl gesteckt). Auch die 
Versorgungsspannung auf dem STK habe ich auf 5V hochgeregelt, um die 
USB-Pegel zu erreichen. Im Leerlauf gibt mir der ATA6660 auch eine 
Spannung von ca 2,5V auf CANH und CANL in Bezug auf GND aus.

Über Drahtbrücken habe ich PD5 mit TXCAN und PD6 mit RXCAN auf dem STK 
verbunden.

Hier noch der Code der Hauptfunktion, die ohne Meckern compiliert wurde:
1
#include <avr/io.h>
2
#include <stdint.h>
3
#include <avr/interrupt.h>
4
#include <avr/pgmspace.h>
5
6
#include "scr/config.h"
7
#include "scr/can.h"
8
9
// -----------------------------------------------------------------------------
10
// Main loop for receiving and sending messages.
11
12
int main(void)
13
{
14
  // initialisieren des CAN-Controllers
15
  can_init(BITRATE_125_KBPS);
16
  
17
  // erzeuge eine Testnachricht
18
  can_t msg;
19
  
20
  msg.id = 0x10;
21
  msg.flags.rtr = 0;
22
  msg.flags.extended = 1;
23
  
24
  msg.length = 4;
25
  msg.data[0] = 0xde;
26
  msg.data[1] = 0xad;
27
  msg.data[2] = 0xbe;
28
  msg.data[3] = 0xef;
29
  
30
  // Nachricht verschicken
31
  can_send_message(&msg);
32
  
33
  while (1) {
34
        
35
  }
36
}

Auch wenn die Register für die TQs (CANBT1 bis CANBT3) noch nicht ganz 
passen, sollte zumindest das Oszi ein paar Flanken erkennen lassen, was 
es aber nicht macht. Hat noch ein Leser einen Lösungsansatz?

VG und schonmal Danke an die Ratgeber!
Stefan

von Alex h. (dudeda)


Lesenswert?

Mein herangehensweise wäre:


#define  SUPPORT_MCP2515      0
#define  SUPPORT_AT90CAN      1
#define  SUPPORT_SJA1000      0

in der config.h gesetzt ?

Zeigt das Ossi  an das was auf PD5 rausgeht?  Benutzte das stk600 auch 
mit nem AT90CAN128. Man sollte da Pegeländerungen sehen auch wenn man 
den gar nicht zum Transciever verbunden hat.

Der Jumper SlopeCtrl sollte passen. Term habe ich persöhnlich nicht 
gesteckt. Was passiert falls er nicht gesteckt ist? (Ich nenutze auch 
125 kBaud)

Grüße
Alex

von Stefan (Gast)


Lesenswert?

in der config.h habe ich alles soweit für den at90can angepasst...

wenn ich das oszi direkt an PD5 und PD6 anschließe erhalte ich alle 
0,5µs ein Flimmern von +/-100mV auf dem Oszi, ähnlich einem Diagramm vom 
Herzschlag.

von Stefan (Gast)


Lesenswert?

Als Nachtrag zu meinem Beitrag:

Da ich an meinen DSUB9-Stecker einen PCAN-Tester dran habe, darf der 
TERM-Jumper nicht gesetzt sein. Er schluckt nämlich die Impulse. 
Weiterhin spielt die Konfiguration der CANBT-Register scheinbar sehr 
wohl eine Rolle. Stelle ich die Frequenz für die MCU auf die 
Bibliotheks-seitig eingestellten 16MHz und nehme noch das CKDIV8-Fuse 
heraus, läuft es bei mir nun auch.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.