Guten Tag,
ich habe momentan ein Problem mit dem CAN Low Speed Transceiver TJA1055.
Als CAN Controller hab ich den MCP2515. Vorweg: Der Empfang von
Nachrichten bei 100kbit funktioniert und auch der ERR Pin am Transceiver
ist
auf HIGH und somit im Normal Operating Mode ohne Busfehler lt.
Datenblatt.
Wenn ich allerdings eine Nachricht senden möchte funktioniert das nicht
(TXERR, MLOA und TXREQ im MCP2515 Register sind auf 1)
1
TXERR = Ein Bus Fehler ist aufgetreten während des Senden
2
MLOA = Nachrichten Abitrierung verloren
3
TXREQ = Nachricht im Buffer ausstehend noch nicht versendet
Soweit ich jetzt herausgefunden habe liegt der Fehler bereits beim
Übertragen der Nachricht vom TXCAN Pin des Controllers zum TXD Pin vom
Transceiver. Im Anhang habe ich mit dem Logic Analyzer die Übertragung
mitverfolgt. Warum wird beim Versenden der Pegel auf TXD komplett auf
LOW
gezogen bis ein Fehler registriert wird und kein rezessiver Pegel?
Veruch schon seit Tagen das Problem zu lösen ohne Erfolg.
Hallo,
Kevin schrieb:> Warum wird beim Versenden der Pegel auf TXD komplett auf LOW> gezogen bis ein Fehler registriert wird und kein rezessiver Pegel?
Zwischen TXCAN des Controllers und TXD des Transceivers sollen doch
"Logikpegel" anliegen, <= 0.6V für "low" und >= (Vdd-0.7)V für "high".
Die differenziellen CAN-Bus-Spannungen macht dann erst der Transceiver
daraus. Oder verstehe ich die Frage falsch?
> Veruch schon seit Tagen das Problem zu lösen ohne Erfolg.
Ich gestehe Schwierigkeiten, den Screenshot "TXD.jpg" zu deuten - im
unteren Bereich sehe ich in rot/grün schon periodische Pulse, danach
würde ich sagen, irgendwer sendet da - aber oben ist nur ein längerer
und dann ein paar kurze "low"-Pulse zu erkennen. Ist "oben" der TXD-Pin
des Transceivers, wie in der Legende steht? Ist "unten" dann CANH/CANL
des Transceivers (sieht ein bißchen differenziell aus)? Liegt denn, wenn
Du ein Problem bei der Verbindung vermutest, an TXCAN (MCP2515) und TXD
(TJA1055) jeweils das gleiche an?
Was ich untersuchen würde:
1. Bekommt der MCP2515 per SPI die richtigen Daten geliefert?
2. Läßt er erkennen, daß er etwas sendet / meint, etwas gesendet zu
haben (leeren sich seine Sendepuffer)?
3. Liefert er im Empfangsfall (der ja funktionieren soll) die richtigen
Daten?
Wenn das paßt und der also richtig angesprochen wird, vielleicht mal mit
einem Oszilloskop (statt LA) TXCAN, TXD und CANL/CANH anschauen und
dabei versuchen, was zu übertragen...
Ich bin gespannt!
Thiemo N. schrieb:> Ich gestehe Schwierigkeiten, den Screenshot "TXD.jpg" zu deuten - im> unteren Bereich sehe ich in rot/grün schon periodische Pulse, danach> würde ich sagen, irgendwer sendet da - aber oben ist nur ein längerer> und dann ein paar kurze "low"-Pulse zu erkennen. Ist "oben" der TXD-Pin> des Transceivers, wie in der Legende steht? Ist "unten" dann CANH/CANL> des Transceivers (sieht ein bißchen differenziell aus)? Liegt denn, wenn
Oben bei TXD in der Legende ist der PIN TXCAN am MCP2515 Controller und
unten bei RXD der PIN RXCAN am MCP2515 Controller. Also beides sind
Daten
direkt am CAN Controller zum/vom Transceiver. Ganz unten im Bild ist ein
Überblick der kompletten Aufzeichnung. da kann man auch erkennen das auf
PIN RXD richtige Daten empfangen werden ( Sieht canh/canl Bus Signal
ähnlich, ist aber der RX PIN am Controller ). Die Empfangen Daten
scheinen auch soweit Plausibel.
TXD funktioniert nicht.
Der Controller reagiert beim Senden genau mit dem langen LOW Signal auf
TXD.
Thiemo N. schrieb:> Liegt denn, wenn> Du ein Problem bei der Verbindung vermutest, an TXCAN (MCP2515) und TXD> (TJA1055) jeweils das gleiche an?
In der Aufzeichnung messe ich direkt am Ausgang am Controller und sogar
da
ist das Signal schon Falsch. Ich kann das nochmal genauer prüfen. Aber
zumindest mit dem Ohmmeter hab ich eine Verbindung.
Thiemo N. schrieb:>> Warum wird beim Versenden der Pegel auf TXD komplett auf LOW>> gezogen bis ein Fehler registriert wird und kein rezessiver Pegel?>> Zwischen TXCAN des Controllers und TXD des Transceivers sollen doch> "Logikpegel" anliegen, <= 0.6V für "low" und >= (Vdd-0.7)V für "high".> Die differenziellen CAN-Bus-Spannungen macht dann erst der Transceiver> daraus. Oder verstehe ich die Frage falsch?
Ja, Denke auch Logikpegel zwischen Controller u. Transceiver. Der
Transceiver wandelt die Pegel von der einen Leitung auf CANH und CANL
auf.
Bei der Aufzeichnung des TXD Pins ab Sende Start einer Nachricht nur ein
Low Pegel zu sehen. Was aber nicht richtig ist, wenn man die HEX Bus
Daten darüber betrachtet ergibt sich aus dem langen low ein 0x000 als
identify wobei ich 0x661 sende möchte. Deswegen die Frage warum er nur
einen Low Pegel sendet, weil er sollte ja auch 1en also High Signale
senden. Ein TXD Gut Bild würde ähnlich dem Signal RXD aussehen (Wie auf
der Übersicht unten zu sehen).
Die anschließenden kurzen Low Signale in der Spalte TXD sind weitere
Sendeversuche vom Controller der Nachricht da ein Fehler aufgetreten ist
und ich ihn nicht ihn OneShot Modus betreibe, denke ich.
Thiemo N. schrieb:> 1. Bekommt der MCP2515 per SPI die richtigen Daten geliefert?
Hatte heute Vormittag die Register für die Transmit Buffer kontrolliert
und die waren alle i. O.. Also CAN Nachricht müsste richtig im Register
sein.
Thiemo N. schrieb:> 2. Läßt er erkennen, daß er etwas sendet / meint, etwas gesendet zu> haben (leeren sich seine Sendepuffer)?
Erkennen tu ich es, weil wie gesagt beim Sende Start der Nachricht
ändert sich beim Pin TXCAN am Controller das Signal ( Der lange falsche
Low Pegel in der Aufzeichung ). Das ist genau der begin wenn ich die
Nachricht sende.
Die Sendepuffer sind immer voll weil die Nachricht irgendwie nie
gesendet wird. Aber wahrscheinlich genau deswegen weil der Controller
falsche daten rausschickt.
Thiemo N. schrieb:> 3. Liefert er im Empfangsfall (der ja funktionieren soll) die richtigen> Daten?
Denke Schon. Die Empfangsdaten sind von div. KFZ Steuergeräten. Wobei
die Daten soweit alle korrekt aussehen.
Was mir noch aufgefallen ist: Wenn ich keine Nachricht sende aber eine
"fremde" Nachricht Empfange, sendet mein Controller ein richtiges ACK
Bit an den Absender! Es scheint so wie wenn der Tja1055 schlichtweg
meine zu sendenden Frames ignoriert/blockt. KA Warum
Hab jetzt probiert den Tja1055 ganz ausgebaut und TXCAN und RXCAN vom
MCP überbrückt. Die Nachricht wird versendet und auch richtig empfangen
( Also so ne Art loopback). Soweit müsste es dann schon alles richtig
sein.
Es Liegt Irgenwie am TJA1055. Vll sind meine RTl und RTh widerstände
nicht richtig?
kann es das falsche bittiming sein? Wahrscheinlich nicht weil er sonst
nichts empfangen würde?
Wenn das kein Monolog bleiben soll, dann könnte helfen, die Schaltung
rauszurücken. Die echte, kein Datenblattauszug. Bild, nicht Prosa.
Auch das Bit-Timing lässt sich besser beurteilen, wenn man es kennt.
Würd ich und hät ich auch. Kann ich aber nicht da ich keinen Schaltplan
für den Aufbau habe. Es gibt auch keinen Schaltplan den ich nachgelötet
habe und ich selber habe noch keinen gemacht bzw. keine Platine dafür.
Ist noch Lochraster und solange es nicht funktioniert werd ich
wahrscheinlich keine platine machen.
Ich weiß das es helfen könnte aber ich hab leider keinen.
'nabend,
Kevin schrieb:> Hab jetzt probiert den Tja1055 ganz ausgebaut und TXCAN und RXCAN vom> MCP überbrückt. Die Nachricht wird versendet und auch richtig empfangen> ( Also so ne Art loopback). Soweit müsste es dann schon alles richtig> sein.
Das ist doch ein guter Test und ein gutes Ergebnis.
> Ist noch Lochraster und solange es nicht funktioniert werd ich> wahrscheinlich keine platine machen.
"SO14", "body width 3.9mm", laut Datenblatt? Hut ab, wenn das fehlerfrei
geklappt hat.
> Es Liegt Irgenwie am TJA1055. Vll sind meine RTl und RTh widerstände> nicht richtig?
Tja, das Teil habe ich noch nicht verbaut... Aber sollten die nicht eh
nur im Fehlerfall wichtig sein? Nach dem Datenblatt haette ich ja
jeweils uebliche 120R genommen.
Wie A.K. schrieb - Fehler scheint in Hardware zu liegen, da waere es
gut, die Hardware zu kennen.
Also Danke an dich Thiemo für deine Unterstützung, hast mir
ansporn gegeben den Fehler zu finden :)
Hab den Fehler jetzt gefunden.
Thiemo N. schrieb:> Aber sollten die nicht eh> nur im Fehlerfall wichtig sein? Nach dem Datenblatt haette ich ja> jeweils uebliche 120R genommen.
Ja war auch der Meinung bzw. müsste schon richtig sein, dass nur im
Fehlerfall die Widerstände dazu geschaltet werden. Als Widerstand
hab ich 5kOhm genommen. 5kOhm weil: Hab ein Steuergerät aus einem KFZ
das auch im selben CAN Bus angeschlossen ist geöffnet und da waren 5kOhm
als RTH u RTL deswegen hab ich die auch bei mir verwendet ohne weiter
darüber
nachzudenken. Welcher Widerstand wirklich der richtige bei mir ist oder
welchen ich verwenden sollte weiß ich nicht 100%.
Thiemo N. schrieb:> Fehler scheint in Hardware zu liegen
JA. Hab echt nicht mehr gewusst warum das nicht Funktioniert. Hab mich
dann entschlossen den TJA1055 auszutauschen. Und was soll ich sagen, hat
sofort funktioniert genauso wie es sollte. Aber warum der alte kaputt
gegangen bzw noch NIE funktioniert hat ist kann ich echt nicht sagen.
Nja egal jedenfalls mit dem neuen
Transceiver funktionierts.
Thiemo N. schrieb:> "SO14", "body width 3.9mm", laut Datenblatt? Hut ab, wenn das fehlerfrei> geklappt hat.
Hab ein Bild mal davon angehängt. Schaut nicht gut aus aber ich hab auch
noch keine Platine dafür gemacht. Klappt soweit ganz gut zu löten. Hab
eine JBC seitdem ist alles leichter zu löten :)
Kevin schrieb:> Hab ein Bild mal davon angehängt. Schaut nicht gut aus aber ich hab auch> noch keine Platine dafür gemacht.
Ok, also wirklich: Hut ab! :-)
Denn mal viel Spaß mit erfolgreichem Senden...
Am Anfang und am Ende des Bus würde ich die genannten 120 Ohm verwenden.
Oft bekommen Teilnehmer dazwischen dann noch einen hochohmigeren
Widerstand wie du es beobachtest hast.
Benutzt du auch wie empfohlen Drosselspulen und evtl. ESD Dioden an den
Transceivern vielleicht hast du dir hier die Probleme eingefangen das
dein TJA1055 futsch ist.
Thread beobachten
Seitenaufteilung abschalten