Forum: Mikrocontroller und Digitale Elektronik CAN Diagnose: Wie detektiere ich einen Wiederholungs-Tx ?


von Oli (Gast)


Lesenswert?

Hi zusammen,

ich möchte ein CAN Netzwerk Diagnosesytem entwerfen, dass mir folgende 
Funktion bietet:
Angesteckt an eine CAN Leitung sollen benutzerdefinierte Nachrichten 
gesendet werden können. Dabei wird mittels Sende-LED und Empfangs-LED 
der Traffic überprüft.
Für den Fall, dass einmal eine auszusendende Nachricht auf dem Bus kein 
ACK bekommt, wird diese ja vom CAN-Controller wiederholt gesendet (wie 
oft überhaupt?). Diesen Wiederholungs-Sendevorgang soll unbedingt durch 
die Sende-LED angezeigt werden. Das kann man dann durch dauerhaftes 
Leuchten gut erkennen.
Ich benutze die Chips von Microchip: mcp2515 (CC) und mcp2551 (Trcv)

Wie muss ich meine LED nun schalten, dass es so wie beschrieben abläuft? 
Ich denke die einzige Möglichkeit ist es, die zwischen die beiden ICs zu 
hängen. Also an die Leitungen TXCAN und RXCAN.

Ich habe schon überlegt, die LED an den Interrupt Pin eines Sendepuffers 
zu hängen, jedoch würde da nur eine erfolgreich gesendete Nachricht ein 
Aufleuchten verursachen.

Bin ich da schon mal auf dem richtigen Holzweg?
Oli

von Michael W. (mictronics) Benutzerseite


Lesenswert?

Zu deinen ICs kann ich nix sagen, aber zu CAN mit SJA1000.

Den kann man programmieren das er entweder ständig Wiederholt bis ein 
ACK kommt, oder im One-Shot Modus. Das heist es wird nur einmal gesendet 
und dann das Ergebniss ermittelt (ACK oder NACK).

Die LED solltest du vom uC ansteuern lassen und zwar mit zusätzlichem 
Delay.

Auf meiner Homepage (mictronics.de) gibts ein offenes CAN Bus Interface, 
da kannst du mal in den Code schaun wie ich das gelöst habe.

von Martin L. (melvin_the_moose)


Lesenswert?

> Für den Fall, dass einmal eine auszusendende Nachricht auf dem Bus kein
> ACK bekommt, wird diese ja vom CAN-Controller wiederholt gesendet (wie
> oft überhaupt?).
Im Normalfall (also One-Shot-Modus nicht aktiviert...) 255 mal, danach 
geht der Knoten in den "Bus Off" - Zustand.

> Wie muss ich meine LED nun schalten, dass es so wie beschrieben abläuft?
> Ich denke die einzige Möglichkeit ist es, die zwischen die beiden ICs zu
> hängen. Also an die Leitungen TXCAN und RXCAN.
Ohne jetzt die Datenblätter zu kennen: Diese beiden beiden 
Signalleitungen dürften kaum in der Lage sein, LEDs zu treiben. Und 
selbst wenn: Bei 100kBaud dauert ein 8-Byte-Frame ~1ms. Sichtbar wäre 
höchstens eine gefühlte Buslast, aber nicht ob, und wie oft ein 
Tx-Versuch wiederholt wird...

> Ich habe schon überlegt, die LED an den Interrupt Pin eines Sendepuffers
> zu hängen, jedoch würde da nur eine erfolgreich gesendete Nachricht ein
> Aufleuchten verursachen.
Wie oben: auch dieses Signal kann nicht direkt eine LED treiben, und 
wenn doch (bzw. über Treiber realisiert): keine Aussage über wiederholte 
Sendeversuche...

Die LED sollte vom uC angesteuert werden. Soweit ich gesehen habe, gibt 
es für eine verlorene Arbitrierung das "TXBnCTRL.MLOA"-Bit, für sonstige 
Fehler die "TXBnCTRL.TXERR" und "CANINTF.MERRF" - Bits, die vom uC 
ausgewertet werden können.

von Oli (Gast)


Lesenswert?

>> Für den Fall, dass einmal eine auszusendende Nachricht auf dem Bus kein
>> ACK bekommt, wird diese ja vom CAN-Controller wiederholt gesendet (wie
>> oft überhaupt?).
>Im Normalfall (also One-Shot-Modus nicht aktiviert...) 255 mal, danach
>geht der Knoten in den "Bus Off" - Zustand.

Bist du sicher? Das würde bedeuten, dass eine niedrig priore Nachricht, 
welche 255 mal überschrieben würde, den ECU lahmlegt.
Und dieses Szenario ist m.M. sehr häufig.

von Martin L. (melvin_the_moose)


Lesenswert?

> Bist du sicher? Das würde bedeuten, dass eine niedrig priore Nachricht,
> welche 255 mal überschrieben würde, den ECU lahmlegt.

Nein, ich bin nicht sicher. So ist das, wenn man aus seinem Halbwissen 
zitiert...
Ich habe noch einmal in die Bosch-CAN-Spec. geschaut. Es gibt u.a. einen 
Transmit Error Counter (TEC). Wenn der TEC < 128 ist, ist der Knoten 
"Error Active", ist 128 <= TEC < 255, ist der Knoten "Error Passive" 
(und darf kein "ACTIVE ERROR FLAG" mehr setzten, aber noch Botschaften 
senden...). Ist der TEC >=255, ist der Knoten im Zustand "Bus Off" und 
darf nicht mehr den Bus beeinflussen.
Mein Irrtum war, daß ich angenommen hatte, daß eine verlorene 
Arbitrierung zur Erhöhung des TEC führt. Das kann ich aber so nicht in 
der CAN-Spec. finden. Wenn ich mich also nicht wieder irre, versucht der 
CAN-Controller so oft die niedrigpriore Botschaft zu senden, bis er die 
Arbitrierung gewinnt, oder andere Fehler auftreten.
Weiterer Irrtum meinerseits: der TEC wird je nach Fehler um 8 erhöht, 
was schneller als von mir angegeben zu "Bus Off" führen kann...
Dieses "Low-Level"-Verhalten wird aber von den 
CAN-Protokoll-Controllern, die ich kenne (v.a. Freescale MSCAN) 
weitgehend autark (ohne SW-Eingriff) geregelt. D.h., dort bekommt die SW 
eine verlorene Arbitrierung in den Konfiguratuionen, mit denen ich 
arbeite, nicht mit.

> Und dieses Szenario ist m.M. sehr häufig.
Das hängt ganz von der Busauslastung ab und deutet auf einen 
überlasteten CAN-Bus hin.

von Martin L. (melvin_the_moose)


Lesenswert?

Ach ja, es ging ja ursprünglich um "kein ACK gesehen" und nicht um 
"Arbitrierung verloren". Für ein fehlendes ACK-Bit gilt: wenn der 
Controller bereits "Error Passive" ist, wird der TEC nicht weiter 
erhöht.
Diesen Fall kann der CAN-Controller aber gewöhnlich an die SW 
signalisieren. Wenn aber kein ACK-Bit gesetzt wird, heißt das 
normalerweise, daß es keine anderen Knoten gibt oder die anderen Knoten 
noch nicht kommunikationsbereit sind. In einem "stabilen Zustand", den 
es meist im Netzwerk gibt, kommt es normalerweise nicht vor, daß das 
ACK-Bit nicht gesetzt wird.

Gruß

Martin

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.