Hallo, ich hier einen ATmega32 mit einem MCP2551 (CAN-Treiber) an einen CAN-Bus gehängt und nutze den UART des Mikrocontrollers um den MCP2551 anszusteuern. Leider spinnt der AVR total rum (resettet sich von selbst, erzeugt BAD-Interrupts). Das Problem ließ sich auf EMV-Störungen eingrenzen und letzlich auch beheben. Es ist die Flanke der Rx-Leitung die den Controller anscheindend aus dem Tritt bringt. Der RXD-Pin des MC2551 ist (bzw. war) bei meinem Aufbau direkt mit dem RXD-Pin des ATmega32 verbunden. Nachdem ich einen RC-Tiefpass eingebaut habe trat das Problem nicht mehr auf. Dennoch möchte ich gerne eure Meinung dazu hören. Hier ein paar Fakten: -Der Controller läuft mit 16MHz -Ich habe sowohl Vcc als auch die Reset-Leitung mit dem Oszi analysiert beide sind stabil. -Das RX-Signal hat eine Fall-Time von 6,3ns und eine Rise-Time von 12,6ns (sagt die Messfunktion von meinem Oszi). Gemessen mit der 10:1 Einstellung des Tastkopfs. Bei der 1:1 Einstellung kommt man auf 47ns und 63ns. Also beeinflusst der Tastkopf erheblich (vermutlich auch noch im 10:1 Modus). -Wenn ich einen Tiefpass mit 940Ohm (2 x 470) und 100pF nehme, tritt das Problem nicht mehr auf. Ich habe dann eine Fall-Time von 255ns und eine Rise-Time von 263ns. -Wenn ich einen Tiefpass mit 470 und 100pF nehme (Fall-Time 139ns / Rise-Time 150ns), tritt das Problem noch auf (wenn auch seltener). -Der Aufbau ist auf einem Steckbrett (es gibt einige lange Drähte) und daher nicht EMV-Optimal. Jedoch ist der AVR mit einem Elko und einem 100nF KerKo gepuffert. Soweit sogut. Obwohl die ganze Konstruktion wie gesagt ein wenig lommelig ist, wundere ich mich doch ein wenig über den Fehler. Denn den RX-Pin des Transceivers mit dem des AVRs direkt zu verbinden liegt doch schon irgendwe nahe. Auch finde ich die Flanken (Gerade bei dem 470-Ohm-R/C-Glied oder der Messung mit 1:1-Tastkopf) garnicht so extrem. Da sind die Flanken, die der Controller selbst beim Pin-Toggeln erzeugt, steiler. Oder auch die eines normalen TTL-Bausteins. Was sagt ihr dazu? Total normal, oder doch etwas überempfindlich? Und wenn normal - gestört wegen dem Aufbau oder darf man AVRs solche Flanken generell nicht zumuten? Gruß, Spannungsabfall
Hi, wie immer: - Schaltplan - Foto des Aufbaus. Gruß Andreas
Hi >Jedoch ist der AVR mit einem Elko und einem 100nF KerKo gepuffert. Wo genau? Außerdem hat ein ATMega32 zwei Versorgungsanschlüsse ((A)VCC-GND). Da wären schon mal zwei Abblockkondensatoren (100n) direkt an den Pins fällig. Bis jetzt ist mir noch kein AVR untergekommen der Probleme mit steilen Flanken hat. Ich bin mir relativ sicher, das die Ursache in deinem Aufbau liegt und du nur die Symptome und nicht die Ursache bekämpfst. MfG Spess
Philipp M. schrieb: > Also beeinflusst der Tastkopf erheblich (vermutlich auch noch > im 10:1 Modus). Berechne mal den Eingangswiderstand des Oszi bei 16MHz Signalfrequenz!
Philipp M. schrieb: > an einen CAN-Bus gehängt Wie sieht der aus? Topologie? Länge? Teilnehmer? > Was sagt ihr dazu? Evtl. eine Masseveschleppung? > Total normal, oder doch etwas überempfindlich? Irgendwo hast du einen Bug in der Schaltung, der dir später nochmal Probleme machen wird... Andreas B. schrieb: > wie immer: > - Schaltplan > - Foto des Aufbaus. Ich schließe mich an... Philipp M. schrieb: > ich hier einen ATmega32 mit einem MCP2551 (CAN-Treiber) an einen CAN-Bus > gehängt und nutze den UART des Mikrocontrollers um den MCP2551 > anszusteuern. Wie nochmal? Der UART kann CAN?
Kannst Du die Versorgungsspannung ausschließen? Probier mal einen eigenen 100nF an jedem VCC-Pin (möglichst nahe) und einen gemeinsamen 10uF für alle VCC-Pins. Auch wichtig: vom 100nF darfst Du nur noch zum VCC-Pin, aber nicht mehr weiter oder abzweigen. Auch am MCP einen 100nF möglichst nahe an VCC usw. "Groundbouncing" ist auch nicht ganz selten, aber ich weiß nicht, wie man das auf dem Steckbrett optimal lösen kann.
Man darf ruhig mal ins Datenblatt schauen, wenn man einen IC verbaut. MCP2551, Seite 10 wird z.B. ein 30pF an RXD gezeigt.
So hier mal Bilder vom Aufbau. Habe ihn noch ein wenig aufgräumt und noch einen 100nF auf die andere Seite des AVRs gesteckt, aber der Fehler besteht noch. Auf den Fotos/dem Schaltplan ist kein 100nF direkt am MCP2551. Ich habe das aber auch getestet und es macht keinen Unterschied. Zur Topologie. An der anderen Seite der CAN-Leitung hängt auch ein AVR (At90USB) mit einem MCP2551. Der ist übrigens auch direkt angeschlossen, und da geht es (auch wenn das Kabel etwas länger ist). Masseverschleppung: Die Massen sind recht direkt verbunden. Ich habe zwar etwas Rauschen auf dem Ground wenn ich zwsichen den beiden Messe, jedoch habe ich das auch bei dem funktionierenden Aufbau mit RC-Glied. UART-oder-CAN? Ich benutze vom CAN nur den Physical Layer. Also die Differnztreiber. Das Protokoll ist UART. Habe mich gegen RS485/RS422 für CAN entschieden weil das Buskollision explizit zulässt (CSMA/CR). Ich weiß das die Abschlusswiderstände vom CAN im Moment noch fehlen. Aber das Signal kommt ja gut an. Ja, das mit dem 30pF ist mir tatsächlich entgangen. Hab mal testweise einen 33pF hingesteckt. Das hat aber nichts bewirkt. Und das würde mir auch nicht die Frage beantworten, warum der AVR von einer steilen Signalflanke so aus dem Tritt gebracht wird.
Philipp M. schrieb: > , warum der AVR von einer steilen > Signalflanke so aus dem Tritt gebracht wird. Nunja, wie steil ist denn die Flanke? Geht sie über VCC hinaus?
Philipp M. schrieb: > Hier ein paar Fakten: > -Der Controller läuft mit 16MHz > -Ich habe sowohl Vcc als auch die Reset-Leitung mit dem Oszi analysiert > beide sind stabil. Ich glaube, dass Du CKOPT nicht gesetzt hast.
Kan asta schrieb: > Man darf ruhig mal ins Datenblatt schauen, wenn man einen IC verbaut. > MCP2551, Seite 10 wird z.B. ein 30pF an RXD gezeigt. Das ist aber nur die TESTschaltung für die elektrischen Eigenschaften. Das soll so nicht in die eigene Schaltung übernommen werden. Die Pins der 100n Kondensatoren solltest Du kürzen. Ich hab für solche Steckbrettaufbauten extra welche mit ganz kurzen Pins die quasi nicht vom Brett abstehen... Führe auch mal eine GND Leitung direkt so nah wie möglich neben der betroffenen Signalleitung entlang und verbinde es möglichst nah an den GND Pin daneben.
Kan asta schrieb: > Nunja, wie steil ist denn die Flanke? Geht sie über VCC hinaus? Die Spannung am RX-Pin des MCP2551 bleibt immer unter VCC. Bei der Fallenden flanke sinkt sie kurzzeitig (10ns) auf -0,3V. Sieht für mich aber nicht ungewöhnlich aus. Normaler Undershoot halt.
Grendel schrieb: > Die Pins der 100n Kondensatoren solltest Du kürzen. ... > > > Führe auch mal eine GND Leitung direkt so nah wie möglich neben der > betroffenen Signalleitung entlang und verbinde es möglichst nah an den > GND Pin daneben. Kondensatoren gekürzt (sehr kurz), GND-Leitung gelegt. Der Fehler bleibt. Ach ja, JTAG hab ich auch deaktiviert. Ich hatte die Vermutung, dass die offnen Pins vllt. irgendwelche falschen Signale senden (kenn mich aber auch nicht aus mit JTAG).
M. N. schrieb: > Ich glaube, dass Du CKOPT nicht gesetzt hast. DANKE! Das war es anscheined wirklich. Da wäre ich nie drauf gekommen. Faszinierend. Da werd ich mich gleich dran machen un mich ausgiebigst über CKOPT und andere Takteinstellungen der AVRs schlau machen. Mich wundert das sich das so auswirkt, aber vermutlich wundert mch das nach der Recherche nicht mehr. Die Ursache für das Missgeschick war, dass ich von einem Mega88 zu dem Mega32 gewechselt bin und der 88er hat kein CKOPT. @Mods: Kann ich den ersten Beitrag dieses Threads und den Titel bearbeiten? Also um [SOLVED] in den Titel einzufügen und die Lösung mit dem CLKOPT direkt unten an den ersten Beitrag dran zu hängen, damit es zukünftige Leser leichter haben?
An Alle die es noch interessiert. Ich habe mal den Takt bei beiden Einstellungen (mit und ohne CKOPT) direkt am Quarz gemessen. Ohne CKOPT ist die Amplitude um ca. Faktor 10 kleiner (man beachte die andere Auflösung des Kanal 1 im zweiten Bild) und man sieht deutlich, wie er durch die Flanke am RX Pin (Kanal 2) massiv gestört wird. Also CKOPT immer setzten, wenn man nicht mit niedrigen Frequenzen arbeitet, mit wenigen Störungen zu rechnen hat und wirklich auf niedrigen Stromverbrauch angewiesen ist.
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.