Hallo zusammen, der folgende CAN Transceiver (https://www.ti.com/lit/ds/symlink/sn65hvda1040a-q1.pdf?HQS=dis-mous-null-mousermode-dsf-pf-null-wwe&ts=1655104774556&ref_url=https%253A%252F%252Feu.mouser.com%252F) arbeitet mit 5V. Ich verwende diesen mit einem 3.3V Mikrocontroller und bekomme ihn nicht zum laufen. Sobald ich Botschaften auf den Bus schicke (über meinen Rechner, verbunden mit der Leiterplatte) komme ich in den "Bus-Off"-Status. Ist ein mit 5V gespeister CAN Controller überhaupt in der Lage mit einem 3.3V uC zu kommunizieren? Wo könnte noch das Problem liegen? Abschlusswiderstände sind vorhanden, Code sollte (und hat schon) so funktionieren. Danke vorab für alle Tipps Gruß
Bob E. schrieb: > Ist ein mit 5V gespeister CAN Controller überhaupt in der Lage mit einem > 3.3V uC zu kommunizieren? Wenn er mit 3,3V in Richtung uC arbeitet, dann schon. > Wo könnte noch das Problem liegen? > Abschlusswiderstände sind vorhanden, Code sollte (und hat schon) so > funktionieren. Du hast den falschen Tranceiver, der arbeitet nur mit 5V für CAN UND uC! Versuch's mal mit MAX13050/MAX13052/MAX13053/MAX13054 oder ähnlich.
Bob E. schrieb: > Ist ein mit 5V gespeister CAN Controller überhaupt in der Lage mit einem > 3.3V uC zu kommunizieren? > Wo könnte noch das Problem liegen? > Abschlusswiderstände sind vorhanden, Code sollte (und hat schon) so > funktionieren. > > Danke vorab für alle Tipps > > Gruß Nutzt Du Pegelwandler von 3V3 auf 5V?
kenny schrieb: > Bob E. schrieb: >> Ist ein mit 5V gespeister CAN Controller überhaupt in der Lage mit einem >> 3.3V uC zu kommunizieren? >> Wo könnte noch das Problem liegen? >> Abschlusswiderstände sind vorhanden, Code sollte (und hat schon) so >> funktionieren. >> >> Danke vorab für alle Tipps >> >> Gruß > > Nutzt Du Pegelwandler von 3V3 auf 5V? Ja aber nicht im Zusammenhang mit dem CAN :) Wieso?
Bob E. schrieb: > Ist ein mit 5V gespeister CAN Controller überhaupt in der Lage mit einem > 3.3V uC zu kommunizieren? Controller oder Transceiver? Bei mir funktioniert das problemlos. Steht sogar auf der ersten Seite des Datenblattes: "Digital Inputs Compatible With 3.3-V and 5-V Microprocessors". Bob E. schrieb: > Sobald ich Botschaften auf den Bus schicke > (über meinen Rechner, verbunden mit der Leiterplatte) komme ich in den > "Bus-Off"-Status. Falsches Bit-Timing oder fehlendes ACK.
Bob E. schrieb: > Ich verwende diesen mit einem 3.3V Mikrocontroller und > bekomme ihn nicht zum laufen. Wie schützt Du eigentlich den unbekannten Controller vor dem 5V Ausgang des CAN-Transceivers? Edit: ein Stück Schaltplan könnte sich auch als nützlich erweisen.
:
Bearbeitet durch User
Rudolph R. schrieb: > Bob E. schrieb: >> Ich verwende diesen mit einem 3.3V Mikrocontroller und >> bekomme ihn nicht zum laufen. > > Wie schützt Du eigentlich den unbekannten Controller vor dem 5V Ausgang > des CAN-Transceivers? > > Edit: ein Stück Schaltplan könnte sich auch als nützlich erweisen. Den kann ich morgen hochladen. Aktuell gar nicht geschützt, habe die Vermutung auch gehabt dass der Controller die 5V vom Transceiver nicht aushält. Habe im Datenblatt vorher auf die Schnelle nichts gefunden.
Hast Du eine Gegenstelle, die die CAN Botschaften empfängt? Hast Du einen Abschlusswiderstand dran?
Abend, Datenblatt lesen (S.17): 9.1 Application Information 9.1.1 Using With 3.3-V Microcontrollers The input level threshold for the digital input pins of this device are 3.3-V compatible, however a few application considerations must be taken if using this device with 3.3-V microcontrollers. Both TXD and STB input pins have internal pullup sources to VCC. Some microcontroller vendors recommend using an open-drain configuration on their I/O pins in this case even though the pullup limits the current. As such care must be taken at the application level that TXD and STB have sufficient pullup to meet system timing requirements for CAN. The internal pullup on TXD especially may not be sufficient to overcome the parasitic capacitances and allow for adequate CAN timing; thus, an additional external pullup may be required. Care should also be taken with the RXD pin of the microcontroller as the RXD output of this device drives the full VCC range (5 V). If the microcontroller RXD input pin is not 5-V tolerant, this must be addressed at the application level. Other options include using a CAN transceiver from TI with I/O level adapting or a 3.3-V CAN transceiver. Gruß Möwe
Bob E. schrieb: > Aktuell gar nicht geschützt, habe die Vermutung auch gehabt dass der > Controller die 5V vom Transceiver nicht aushält. Habe im Datenblatt > vorher auf die Schnelle nichts gefunden. Wenn ich einen µC an CAN anbinden möchte und dafür einen entsprechenden Transceiver kaufe, ist doch das erste, was jeder Normaldenkende macht, einen PASSENDEN auszusuchen. Und ja, das impliziert, dass man auch Datenblätter lesen muss. Und eben nicht nicht nur "auf die Schnelle", sondern zumindest im Detail bezüglich der Anbindung des µC. Nur Vollidioten kaufen erst und checken dann...
@c-hater Bist ein brummliger alter Mann, oder? Vermutlich, denn wenn ich hier was von dir lesen, dann ist es nur Gemeckere.
nOXX schrieb: > Bist ein brummliger alter Mann, oder? Heute ist er doch total handzahm. Warte mal ab, bis er schlecht gelaunt ist. Dann fallen dir die Ohren ab, bzw. die Augen aus dem Kopf.
nOXX schrieb: > @c-hater > Bist ein brummliger alter Mann, oder? Kann schon sein, dass mich offensichtliche Idiotie etwas brummelig macht. Nein, bei nochmaligem Nachdenken: es macht mich ganz sicher ziemlich brummelig. Keine Anung, ob es damit zusammhängt, dass ich (relativ) alt bin. Soweit ich mich erinnern kann, hat mich offensichtliche Idiotie auch in jüngeren Jahren schon extrem genervt.
c-hater schrieb: > Wenn ich einen µC an CAN anbinden möchte und dafür einen entsprechenden > Transceiver kaufe, ist doch das erste, was jeder Normaldenkende macht, > einen PASSENDEN auszusuchen. Es hat keiner gesagt dass der Transceiver gerade eben speziell gekauft wurde. Heute ist es ja wie zu DDR Zeiten, am besten nimmt man das was man hat und macht es passend. Irgendwas aussuchen und schnell neu kaufen gab es schon viele Monde nicht mehr. Viel STM und NXP Controller können mit 5V leben, also um welchen geht es eigentlich?
Viele 3.3V Controller sind 5V-tolerant an den Eingängen. Evtl. ist deiner auch 3.3V-tolerant? In Richtung Transceiver besteht kein Problem, der ist mit >2V zufrieden. Die Ausnutzung der 5V-Toleranz ist vlt. nicht die feinste englische Art, aber durchaus möglich. Was macht denn der STB-Pin? Ist der auf GND gezogen? Oder RXD/TXD gekreuzt? Oder Filter nicht bzw. falsch gesetzt?
:
Bearbeitet durch User
Harald A. schrieb: > Viele 3.3V Controller sind 5V-tolerant an den Eingängen. Evtl. ist > deiner auch 3.3V-tolerant? In Richtung Transceiver besteht kein Problem, > der ist mit >2V zufrieden. Die Ausnutzung der 5V-Toleranz ist vlt. nicht > die feinste englische Art, aber durchaus möglich. Was macht denn der > STB-Pin? Ist der auf GND gezogen? Oder RXD/TXD gekreuzt? Oder Filter > nicht bzw. falsch gesetzt? Hallo Harald, danke für deine konstruktive Antwort. Der STB-Pin ist auf GND gezogen. RXD/TXD sind nicht gekreuzt/falsch herum verbunden. Was meinst du mit Filter? Auf der CANH und CANL Seite? Da habe ich Drossel, Abschlusswiderstand und TVS-Dioden verbaut. Hat so auch schon in der selben Konfiguration mit anderem uC (ESP32) funktioniert. Diesesmal verwende ich einen XMC4200Q48k256. Gruß Bob
Angehängte Dateien:
-
voltage_input.PNG
5,2 KB
Anbei ein Datenblattauszug (https://www.mouser.de/datasheet/2/196/Infineon-XMC4100_XMC4200_DS-DS-v01_04-EN-1075306.pdf S.31) Heißt es ich kann an keinem Pin über 4,3V anlegen? Entsprechend müssten mir die Eingänge kaputt gehen.. oder?
:
Bearbeitet durch User
Wenn die Baudrate nicht allzu hoch ist, reicht oft ein simpler Spannungsteiler (1kΩ + 2,2kΩ). 115200 Baud gehen damit auf jeden Fall.
Siehe Kapitel 3.1.2 "Pin Reliability in Overload" Es ist zulässig den Strom in einen Pin bei Überlast zu begrenzen: "Note: A series resistor at the pin to limit the current to the maximum permitted overload current is sufficient to handle failure situations like short to battery." Das ist zwar nicht toll und auf jeden Fall der falsche Transceiver für den Controller, aber mit einem 4k7 in Reihe zu RXD könnte das gepatcht sein.
Rudolph schrieb: > Siehe Kapitel 3.1.2 "Pin Reliability in Overload" > > Es ist zulässig den Strom in einen Pin bei Überlast zu begrenzen: > "Note: A series resistor at the pin to limit the current to the maximum > permitted overload > current is sufficient to handle failure situations like short to > battery." > > Das ist zwar nicht toll und auf jeden Fall der falsche Transceiver für > den Controller, aber mit einem 4k7 in Reihe zu RXD könnte das gepatcht > sein. Das werde ich mal probieren. Vielen Dank
Wobei das auch einen neuen Controller erfordern könnte, das ist jetzt nicht so unwahrscheinlich das der Transceiver den RXD Pin gegrillt hat.
Rudolph schrieb: > Das ist zwar nicht toll und auf jeden Fall der falsche Transceiver für > den Controller, aber mit einem 4k7 in Reihe zu RXD könnte das gepatcht > sein. Aufpassen, bzw die Application Note genau lesen. Für die meisten Controller gelten mehrere Limits für den injection current in die ESD-Diode. Ein Grenzwert, bis zu dem keine Schädigung des Bauteils eintritt (für den Fehlerfall Überspannung am Eingang) und ein Grenzwert, bis zu dem keine Funktionsbeeinträchtigung analoger Schaltungsteile (ADC, Lowspeed-Oszillator, PLL) auftritt. Für den Dauerbetrieb sollte man letzteren nicht überschreiten. Sonst verliert man ADC-Genauigkeit.
Mit Filter meinte ich den ID Filter im CAN Controller. Der CAN Controller liefert ein Acknowledge nur auf die IDs, die durch den Filter gehen. In den meisten Standardanwendungen wird dieser Filter einfach auf vollkommen offen gesetzt, so dass einfach jede Nachricht quittiert wird. Das muss bei Dir aber nicht so sein. Fehlt das Acknowledge für den Sender kommt es zur berühmten Dauersendung mit Bus-Off. Scope zur Hand oder Logic Analyzer? Dann mal am RX Pin schauen, ob die Nachricht vom Sender vernünftig eingeht. Falls nicht vorhanden, bitte LA für 10€ kaufen. Sind die CAN RX TX Pins in den „alternative mode“ geschaltet?
:
Bearbeitet durch User
Harald A. schrieb: > Der CAN Controller liefert ein Acknowledge nur auf die IDs, die durch den Filter gehen. Nö. Das ACK wird immer gesendet, außer der Controller ist Listen-only. Reference-Manual XMC4200 Seite 1169: "Any node that has received an error free frame acknowledges the correct reception of the frame by sending back a dominant bit, regardless of whether or not the node is configured to accept that specific message." Gilt meines Wissens für alle CAN-Controller.
Thomas F. schrieb: > Harald A. schrieb: >> Der CAN Controller liefert ein Acknowledge nur auf die IDs, die durch den Filter > gehen. > > Nö. Das ACK wird immer gesendet, außer der Controller ist Listen-only. > > Reference-Manual XMC4200 Seite 1169: > "Any node that has received an error free frame acknowledges > the correct reception of the frame by sending back a dominant bit, > regardless of whether or not the node is configured to accept that > specific message." > > Gilt meines Wissens für alle CAN-Controller. Interessant! Ich hatte definitiv schon mit Controllern zu tun, die nur Messages quittiert haben, die durch den Filter kamen. Das würde ja auch durchaus Sinn ergeben: Wenn alle Teilnehmer auf spezifische Adressen filtern kann der Sender sichergehen, dass die Nachricht den „richtigen“ Teilnehmer erreicht hat. Ich bin mir nicht mehr 100% sicher, aber aus der Erinnerung heraus war es ein LPC11C24, der entsprechend reagierte.
Thomas F. schrieb: > Gilt meines Wissens für alle CAN-Controller. So kenne ich das auch. Das ACK Bit informiert nicht darüber, ob der Frame eine Node gefunden hat, die sich dafür interessiert, sondern nur, ob der Frame von irgendwem als korrekt erkannt wurde. Andernfalls würde ein Frame, der keinen Adressaten findet, vom Sender permanent wiederholt.
:
Bearbeitet durch User
Das kann ich auch bestätigen, ich habe sogar ein Projekt das nichts anderes macht als ACK zu senden, dafür wird der CAN-Controller gerade mal so initialisiert auf die Bus-Parameter, keine Filter, keine Message-Boxen. Das ist nützlich wenn man ein Steuergerät testet und sonst nur das USB-Interface am Bus hat, hängt sich das Steuergerät auf ist so wenigstens der Bus an sich noch da und die Test-Umgebung hängt sich nicht gleich mit auf.
Na gut :-) Ich werde es bei nächster Gelegenheit, wenn ich mal wieder ein Projekt mit dem LPC11C24 auf dem Tisch habe, nochmals probieren. Bis dahin rücke ich dann erstmal von meiner These ab.
Harald A. schrieb: > Interessant! Ich hatte definitiv schon mit Controllern zu tun, die nur > Messages quittiert haben, die durch den Filter kamen. Das würde ja auch > durchaus Sinn ergeben: Wenn alle Teilnehmer auf spezifische Adressen > filtern kann der Sender sichergehen, dass die Nachricht den „richtigen“ > Teilnehmer erreicht hat. Ich bin mir nicht mehr 100% sicher, aber aus > der Erinnerung heraus war es ein LPC11C24, der entsprechend reagierte. Das ist kompletter Käse auch in Hinblick auf den LPC11C24/LPC11C14, von dem ich reichlich verbaut habe. Hier gibt es auch keinen Interpretationsspielraum weil etwas anderes den ganzen CAN-Bus kaputt machen würde. Wenn der Sender wissen will ob der "richtige" Teilnehmer die Nachricht empfangen hat muss dieser selbst aktiv werden und eine Quittierung in welcher Form auch immer senden. Was würde es nützen wenn der "richtige" Teilnehmer als einziger die Nachricht mit ACK bestätigt? Das heißt ja dann nur, daß die Hardware im Controller die Nachricht gesehen hat und noch lange nicht das Programm auf dem Controller.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.