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?
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.
Hast Du auch einen weiteren Teilnehmer an den CAN angeschlossen ? Otto
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?
Ja, ich habe auch mal einen IXXAT USB-To-Can Controller daran angeschlossen gehabt. Er erkennt diese Sendeversuche vom AT90CAN128 sofort als RX-Error.
> er doch alles als OK befinden, wenn TXCAN und RXCAN > miteinander verbunden sind, oder nicht? Nein - das ist doch kein ACK
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...
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)
Hänge einen weiteren Teilnehmer dran, sonst wird das nichts. Stelle beide Teilnehmer auf die selbe Baudrate und denke an die Terminierung.
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...
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.
Weshalb hängst Du ein CAN-USB-Interface dran - das antwortet doch auch nicht von alleine - ohne "echten Teilnehmer" wird das nichts !
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)
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
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.
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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.