Hallo zusammen,
mein CAN Controller treibt mich in den Wahnsinn... Ich krieg das Ding
einfach nicht zum senden. Ich hab den code schon dutzendfach durchsucht
und seh den Fehler einfach nicht. Ich hoffe, dass ihr hier eine Idee
habt, sonst weiß ich nicht mehr weiter.
Der Code ist im Anhang. Die Main Funktion ist ganz unten, in der
Versuche ich dauerhaft eine Nachricht zu senden.
Mittels Oszilloskop schaue ich an den TX und RX Leitungen des MCP2515,
ob die Nachricht zum Transceiver gesendet wird. Beide Leitungen geben
permanent 5 V aus -.-
Beschaltet ist der MCP2515 nach Datenblatt. SPI Kommunikation
funktioniert. 16 MHz Quarz mit zwei 22pF Kondensatoren als externe
Taktquelle am CAN Controller. TXCAN/RXCAN gehen zum CAN Transceiver.
Ich hoffe auf eure Hilfe.
Viele Grüße
Sascha
Wenn eine CAN Node allein am Bus ist, dann fühlt sie sich einsam und
schmollt.
Mindestens eine weitere Node ist notwendig um das ACK Bit zu setzen.
Sonst zählt die Node solange den Errorcounter hoch, bis das Limit
erreicht ist, und rührt sich danach nicht mehr.
Schau dir die Statusregister und Errorcounter an.
@Heinz
Leider tut der Beispiel Code nicht. Sowohl Schaltung, als auch
Beispielcode stammen weitestgehend von kreatives-chaos.com
@Heinz & A.K.
Das Problem ist, dass der CAN Controller garkeine Signale an den
Transceiver weiter leitet. LEtztendlich ist der CAN Controller nur ein
Pegelwandler und somit sollte ich - unabhängig der Anzahl der
Busteilnehmer - doch eigentlich wenigstens das Signal vom CAN Controller
zum Transceiver sehen, oder ???
Ich find einfach keinen Fehler -.-
Sascha schrieb:> @Heinz & A.K.> Das Problem ist, dass der CAN Controller garkeine Signale an den> Transceiver weiter leitet.
Sobald er mal im Modus "error passive" oder "bus off" ist, kommt da auch
nix mehr.
> LEtztendlich ist der CAN Controller nur ein Pegelwandler
Nein. Der Transceiver ist nur ein Pegelwandler.
> und somit sollte ich - unabhängig der Anzahl der Busteilnehmer - doch> eigentlich wenigstens das Signal vom CAN Controller> zum Transceiver> sehen, oder ???
Nein.
Sascha schrieb:> Ich find einfach keinen Fehler -.-
Du brauchst zwingend ein "Gegenüber". Ausserdem muß der Bus
impedanzmäßig korrekt abgeschlossen sein. Damals habe ich am PC ein
Interface mit einem CAN-Transceiver, beide mit mit SJA1000, verbinden
müssen, um überhaupt Traffik erzeugen zu können. Bau also einen zweiten
Busteilnehmer. Ich habe mich damals mit dem Elektor Projekt befasst,
eines der wenigen, die auf Anhieb funktiniert haben.
Zum testen betreibe ich den CAN Controller im Loopbackmodus. Da ist doch
das ACK egal und er müsste die Nachrichten zum Transceiver weiterleiten.
Oder hatte ich das falsch verstanden ?
2 Sachen fallen mir direkt auf:
void mcp2515_init(void)
{
// SPI Interface initialisieren
spi_init();
// MCP2515 per Software Reset zuruecksetzten,
// danach ist der MCP2515 im Configuration Mode
PORT_CS &= ~(1<<P_CS);
spi_putc( SPI_RESET );
_delay_ms(1);
PORT_CS |= (1<<P_CS);
// etwas warten bis sich der MCP2515 zurueckgesetzt hat
_delay_ms(10);
//|---------- Device in den Konfigurations Modus versetzten ---------|
//|-------------------- CLKOUT Pin deaktivieren ---------------------|
mcp2515_bit_modify( CANCTRL, 0xE0, (1<<REQOP2) );
//das fehlt
//|------------------- Einstellen des Bit Timings -------------------|
// CAN Baudrate 125 kBaud
// BRP = 7
mcp2515_write_register( CNF1, (1<<BRP0)|(1<<BRP1)|(1<<BRP2) );
// Prop Seg und Phase Seg1 einstellen
mcp2515_write_register( CNF2, (1<<BTLMODE)|(1<<PHSEG11) );
// Wake-up Filter deaktivieren, Phase Seg2 einstellen
mcp2515_write_register( CNF3, (1<<PHSEG21) );
// Aktivieren der Rx Buffer Interrupts (wenn voll)
mcp2515_write_register( CANINTE, (1<<RX1IE)|(1<<RX0IE) );
und hier gibst du munter die den recieve-Interrupt frei, aber ich sehe
in deinem Programm nichts, was den Interrupt auswertet und dem MCP sagt,
ok, ich habs zur Kenntnis genommen.
Das ist das blöde am Kopieren von Software, man macht sich zuwenig
Gedanken.
// Einstellen der Filter
Hi Joachim, danke für deine Antwort.
Wieso muss der Clkout PIN denn deaktiviert sein?
Der Interrupt Pin geht auf den µC und soll dann die empfangene CAN
Nachricht abholen. Ist das so nicht richtig ?
Der Übersicht halber habe ich das Programm auf die Basics gekürzt. Hab
halt das Problem, dass ich an den TX/RX Pins vom Can Controller zum
Transceiver partout keine Signaländerungen erkennen kann. Beide geben
konstant 5 V raus
Tja, das sieht halbwegs i.O. aus.
Es fehlt einerseits der Abschlusswiderstand und der Gegenteilnehmer
(wurde dir schon gesagt)
Mir stellt sich noch die Frage: Programmierst du den Mega32 in der
Zielschaltung oder extern?
Falls ersteres: dann ist der Schaltplan nicht vollständig
Falls zweiteres: Hat der wirklich einen Takt (fuses?)
Sascha schrieb:> Zum testen betreibe ich den CAN Controller im Loopbackmodus. Da ist doch> das ACK egal und er müsste die Nachrichten zum Transceiver weiterleiten.
Im Loopback-Modus wird gar nichts gesendet - niemals! Da simuliert der
Controller das Senden und Empfangen der Botschaften komplett. Das steht
auch ziemlich unmissverständlich im Datenblatt:
10.4 Loopback Mode
Loopback mode will allow internal transmission of
messages from the transmit buffers to the receive
buffers without actually transmitting messages on the
CAN bus.
Es lag tatsächlich am fehlenden Teilnehmer... Bin immer davon
ausgegangen, dass zumindest bis zum Ack die Nachricht vom Can Controller
zum Transceiver übertragen werden müsste. Nun funktioniert alles!!!
Eine Frage noch zur ISP. Für die fertige Schaltung soll der ATMEGA in
der Zielschaltung Programmiert werden. Dazu habe ich nun zwei Ansätze
gesehen.
1. 1k Ohm Widerstände in die MISO/MOSI/SCK Leitungen setzen (siehe
Schaltbild)
2. Pullup Widerstand an CS.
Was macht denn mehr Sinn?