Hallo zusammen, ich habe mir den vereinfachten AVR-ISP-Programmer für PonyProg nach dieser Anleitung gebaut: http://s-huehn.de/elektronik/avr-prog/avr-seriell.gif. Dieser ist auch schon seit einigen Jahren erfolgreich im Einsatz. Damit programmiere ich über das SPI-Interface einen ATMega32. Über das SPI-Interface ist der ATMega32 auch gleichzeitig mit einem MCP2515 und MCP2551 an einen CAN-Bus angeschlossen, etwa wie hier: http://www.mikrocontroller.net/attachment/89702/can.png. (außer, dass bei mir die RESET-Leitungen des AVR und des MCP2515 über einen gemeinsamen Pullup auf High gezogen werden) Nun konnte ich damit den AVR, während er am CAN-Bus hing, einen Tag lang ohne Probleme mit PonyProg programmieren und auch CAN-Nachrichten verschicken. Am nächsten Tag wollte ich, ohne dass ich irgendwas an der Schaltung geändert hatte, den AVR noch einmal programmieren. Allerdings meldete PonyProg gleich beim ersten Versuch: "No device found". Als ich dann den MCP2515 anfasse, ist dieser sehr (!) heiß. Der MCP2515 ist kaputt gegangen (ich habe ihn in anderen Schaltungen getestet). Der ATMega32 war ebenfalls hin, da bin ich mir aber nicht sicher, ob das sofort der Fall war oder erst als Folge wegen dem kaputten MCP2515. Also habe ich beide Komponenten durch neue ersetzt. Als ich das ganze mit den neuen Komponenten wiederhole, passiert genau das gleiche wieder: am ersten Tag funktionierts, am zweiten Tag sind die Teile wieder kaputt :(. Jetzt habe ich mehrere Vermutungen: Entweder es hängt mit dem ISP-Programmer zusammen (liefert Überspannung etc.). Allerdings funktioniert der ja bei anderen Schaltungen ohne CAN dauerhaft einwandfrei. Oder es hängt damit zusammen, dass der MCP2515 und der ISP-Programmer gleichzeitig am SPI-Bus des AVR hängen und die sich dann bei der Kommunikation gegenseitig in die Quere kommen, wie z.B. hier: (Beitrag "Re: PonyProg zerstört ATMEGA32"). Dann müste ich den CS-Pin des MCP2515 mit nem Pulldown versehen, oder? Das erklärt für mich aber nicht, warum die Bauteile dann komplett zerstört werden. Der AVR könnte bei fehlerhafter Kommunikation verfused werden, aber er würde doch nicht kaputt gehen, oder? Und der MCP2515 dürfte dabei auch nicht heiß werden und kaputt gehen... Ich hoffe ihr könnt mir weiterhelfen, ich brüte nämlich schon seit einiger Zeit an diesem Problem und ich möchte nicht wahllos einfach was ändern, nur um dann festzustellen, dass wieder alles abraucht...
Es ist sicher nicht optimal, was du da zusammengebastelt hast (SPI direkt zusammen, gemeinsamen Reset, CS in der Luft beim Brennen) Ein paar kleine Widerstände helfen manchmal wahre Wunder :-) Dazu dann noch PonyProg - irgendwann müssen die Dinger dochmal aussterben... Denke dennoch, dass deine Probleme woanders her kommen. Meist Stromversorgung. Ein schwingender Regler kann wunderliche Sachen anrichten.
Erst mal vielen Dank für die Lösungsansätze :) Hmm, also die Stromversorgung ist über einen 7805 mit 100µF davor und 100nF danach gelöst. Sollte so doch eigentlich stabil sein. Wenn ich den SPI nicht direkt zusammen machen soll, müsste ich da irgendwo wieder zusätzliche Umschalter reinbauen, was ich eigentlich vermeiden wollte. Es heißt doch nicht umsonst "In System Programming". Ja, das mit dem Reset und CS werde ich beim nächsten mal ändern, wobei es mir als Ursache fraglich erscheint. Und warum soll PonyProg in der hinsicht schlechter sein? Ich mein dem SPI ist es doch egal was da hinten dran hängt. Und bei anderen Schaltungen gehts ja auch.
Jacy Jung schrieb: > Wenn ich den SPI nicht direkt zusammen machen soll, müsste ich da > irgendwo wieder zusätzliche Umschalter reinbauen, was ich eigentlich > vermeiden wollte. Es heißt doch nicht umsonst "In System Programming". Nun ja. Garantiert funktioniert ISP natürlich nur, wenn es seine Leitungen exklusiv für sich hat. Wenn man sie mit der Anwendung sharen möchte, ist man selbst dafür verantwortlich, dies so zu tun, daß sowohl die Erfordernisse der Anwendung als auch der ISP-Programmierung durch die konkrete Schaltung erfüllt werden. > Und warum soll PonyProg in der hinsicht schlechter sein? Ich mein dem > SPI ist es doch egal was da hinten dran hängt. Nein, natürlich nicht. Das Problem ist dabei natürlich nicht die Software PonyProg, die spult auch nur das ISP-Protokoll ab, wie du richtig erkannt hast. Das Problem ist vielmehr die auf's billichste reduzierte Hardware, die du als Programmieradapter verwendest. Die ist so designed, daß sie in aller Regel funktionieren wird, wenn sie die Leitungen zum Controller für sich alleine hat. Für mehr war sie nie gedacht und viel mehr kann sie tatsächlich auch nicht leisten. > Und bei anderen > Schaltungen gehts ja auch. Ach... Ob das mal daran liegen könnte, daß sie eben anders sind und dementsprechend andere Bedingungen für den Programmieradapter herrschen? Mein Gott, wie grenzenlos unwissend, ja förmlich blöd muß man sein, um das nicht zumindest als potentielles Problem erkennen zu können?
Mal wieder ponyprog. Wieviel Hardware damit wohl schon zerschossen wurde? Ich würde über den Kauf eines vernünftigen ISP-Flashers nachdenken. Und ohne Schaltplan können wir hier das Problem nicht einkreisen. Das Warmwerden von Bauteilen deutet meist auf einen Schaltungsfehler, z.B. Kurzschluss, hin.
Angehängte Dateien:
-
Schaltplan.png
76 KB
c-hater schrieb: > Nun ja. Garantiert funktioniert ISP natürlich nur, wenn es seine > Leitungen exklusiv für sich hat. Wenn man sie mit der Anwendung sharen > möchte, ist man selbst dafür verantwortlich, dies so zu tun, daß > sowohl die Erfordernisse der Anwendung als auch der ISP-Programmierung > durch die konkrete Schaltung erfüllt werden. Genau das möchte ich ja wissen, ob meine Schaltung mal ganz grundsätzlich die "Erfordernise" erfüllt. SPI ist doch extra deshalb ein Bussystem, damit man mehrere Objekte gleichzeitig an diesen hängen kann. c-hater schrieb: > > Ach... Ob das mal daran liegen könnte, daß sie eben anders sind und > dementsprechend andere Bedingungen für den Programmieradapter herrschen? > > Mein Gott, wie grenzenlos unwissend, ja förmlich blöd muß man sein, um > das nicht zumindest als potentielles Problem erkennen zu können? Ich habe es doch als generelles Problem überhaupt nicht ausgeschlossen, siehe erster Beitrag: > Oder es hängt damit zusammen, dass der MCP2515 und der ISP-Programmer > gleichzeitig am SPI-Bus des AVR hängen und die sich dann bei der > Kommunikation gegenseitig in die Quere kommen, wie z.B. hier: > (Beitrag "Re: PonyProg zerstört ATMEGA32"). Pete K. schrieb: > Und ohne Schaltplan können wir hier das Problem nicht einkreisen. Das > Warmwerden von Bauteilen deutet meist auf einen Schaltungsfehler, z.B. > Kurzschluss, hin. Ich hab ihn angehängt. Pete K. schrieb: > Mal wieder ponyprog. Wieviel Hardware damit wohl schon zerschossen > wurde? > > Ich würde über den Kauf eines vernünftigen ISP-Flashers nachdenken. Ich habe mit PonyProg bisher eigentlich noch keine schlechten Erfahrungen gemacht und es bisher für einen guten Programmer gehalten. Aber daran solls nicht scheitern, dann werde ich mir einen anderen Programmer zulegen.
Hat eigentlich der 2515 einen eingebauten Pullup auf dem CS-Pin? Wenn nein. Was denkst du wird passieren, wenn die CS Leitung nicht aktiv angesteuert wird, weil der µC am anderen Ende der Leitung gerade im Reset ist? Mit ein bischen Pech, ist der CS Low und der 2515 versucht die Macht auf dem Bus an sich zu reissen. Und dann hast du eben das Problem, dass 2 Ausgänge gegeneinander arbeiten. Der SO vom 2515 und die MOSI Leitung vom ISP. 2 Ausgänge gegeneinander, bei denen der eine die Leitung auf 5V ziehen will, der andere die Leitung auf Masse ziehen will, das kann nicht lange gut gehen. Irgendwer muss dann mal verlieren. Bussystem: ja Aber dieser Bus ist darauf ausgelegt, dass der Master mittels CS Leitung bescheid gibt, welcher Slave gemeint ist. Nur: wenn der Master ausser Gefecht gesetzt wird, weil er gerade von einem Prgorammer selber bearbeitet wird (und so zum Slave vom Programmer verkommt), dann ist das eben keine normale Busoperation mehr.
:
Bearbeitet durch User
Hast du zufällig den 7805 gewechselt, gibt einige die von der eingebürgerten PIN Belegung abweichen. Da sind soviele Sachen die mir auffallen haben vielleicht nichts mit dem aktuellem Problem zu tun aber trotzdem würde ich die Schaltung mal daraufhin verändern. Empfielt der Hersteller des 7805 keine 100nF zw. Eingangs- und Massepins im Datenblatt? Diode vom Reglerausgang zum Reglereingang? Blocks du deine Versorgungsspannung nicht per 100nF an jedem Bauteil ab, da können mords Impulsströme auftreten die deine Versorgungsspannung zum abheben bringen können 100nF zw. Resetpin und Masse? AVCC nicht angeschlossen evtl. mit 10µH Drossel was man aber auch für alle anderen VCC Pins vor dem Abblockkondensator verbauen kann um die VCC nochmals etwas zu filtern.
Karl Heinz schrieb: > Was denkst du wird passieren, wenn die CS Leitung nicht aktiv > angesteuert wird, weil der µC am anderen Ende der Leitung gerade im > Reset ist? Die Situation stellt sich hier lt. Schaltplan allerdings etwas anders dar. Die Reset-Leitungen von MCP und Controller sind verbunden. Nun wäre interessant, was das Datenblatt des MCP über sein Verhalten an den SPI-Pins im Reset-Zustand sagt. Es wäre zumindest denkbar, daß da nicht der Z-State garantiert ist. Auch interessant wäre, ab welchem Pegel an seinem Reset-Pin der MCP überhaupt in den Reset geht. Es ist zumindest denkbar, daß das Gebastel mit dem Transistor in diesem Programmer den Pegel nicht tief genug absenken kann. Aber natürlich hast du trotzdem Recht bezüglich der CS-Leitung. Denn wenn der Programmierer angesteckt ist, zieht er ja nicht dauerhaft die Reset-Leitung, sondern nur während eines Programmiervorgangs. Und im Gegensatz zu richtigen Programmern, die außerhalb dieser Zeit ihr ISP-Interface hochohmig schalten, macht das diese Billichkonstruktion ja nicht. Das könnte man mit einem zusätzlichen Transparent-Latch mit Tristate-Ausgängen aber leicht ändern. Ein Problem wäre allerdings dessen Stromversorgung aus dem Com-Port. Im konkreten Fall könnte man das Latch aber auch leicht mit auf die Platine des Zielsystems legen und aus dessen Versorgung mitversorgen.
Karl Heinz schrieb: > Hat eigentlich der 2515 einen eingebauten Pullup auf dem CS-Pin? > > Wenn nein. > Was denkst du wird passieren, wenn die CS Leitung nicht aktiv > angesteuert wird, weil der µC am anderen Ende der Leitung gerade im > Reset ist? > > Mit ein bischen Pech, ist der CS Low und der 2515 versucht die Macht auf > dem Bus an sich zu reissen. Und dann hast du eben das Problem, dass 2 > Ausgänge gegeneinander arbeiten. Der SO vom 2515 und die MOSI Leitung > vom ISP. 2 Ausgänge gegeneinander, bei denen der eine die Leitung auf 5V > ziehen will, der andere die Leitung auf Masse ziehen will, das kann > nicht lange gut gehen. Irgendwer muss dann mal verlieren. > > > Bussystem: ja > Aber dieser Bus ist darauf ausgelegt, dass der Master mittels CS Leitung > bescheid gibt, welcher Slave gemeint ist. > Nur: wenn der Master ausser Gefecht gesetzt wird, weil er gerade von > einem Prgorammer selber bearbeitet wird (und so zum Slave vom Programmer > verkommt), dann ist das eben keine normale Busoperation mehr. Der 2515 müsste aber durch den RESET während der Programmierung stillgelegt sein ("Active low device reset input") und zumindest nicht aktiv MISO auf 5V oder GND ziehen. Aber es hört sich sehr logisch an was du sagst, weil ein solcher GND<->5V Fehlstrom wäre eine plausible Erklärung für das Heißwerden. Thomas O. schrieb: > Hast du zufällig den 7805 gewechselt, gibt einige die von der > eingebürgerten PIN Belegung abweichen. Nein, den hab ich nicht gewechselt, der hat die Standardbelegung. Thomas O. schrieb: > Empfielt der Hersteller des 7805 keine 100nF zw. Eingangs- und Massepins > im Datenblatt? Stimmt, im Datenblatt steht 330nF, das muss ich ändern. Thomas O. schrieb: > Diode vom Reglerausgang zum Reglereingang? Ist im "Standard Application Circuit" des 7805 nicht eingezeichnet... aber kann ich einfügen Thomas O. schrieb: > Blocks du deine Versorgungsspannung nicht per 100nF an jedem Bauteil ab, > da können mords Impulsströme auftreten die deine Versorgungsspannung zum > abheben bringen können Reicht da bei sehr kurzen Leitungslängen (einige Zentimeter) nicht ein Kondensator? Ich glaube sonst kann ich gleich 300nF nehmen. Thomas O. schrieb: > AVCC nicht angeschlossen evtl. mit 10µH Drossel was man aber auch für > alle anderen VCC Pins vor dem Abblockkondensator verbauen kann um die > VCC nochmals etwas zu filtern. Oh ja, das mit AVCC hab ich hier versehentlich nicht eingezeichnet, ist aber mit VCC verbunden. Als externe Quelle von VCC dient ein Netzgerät mit stabilisierter 12V-Spannung, von extern sollte es also zu keinen Spannungsspitzen kommen. Das mit der Drossel habe ich bisher noch nicht bei einer AVR-Schaltung gesehen, kann ich aber ergänzen. c-hater schrieb: > Nun wäre interessant, was das Datenblatt des MCP über sein Verhalten an > den SPI-Pins im Reset-Zustand sagt. Es wäre zumindest denkbar, daß da > nicht der Z-State garantiert ist. Auch interessant wäre, ab welchem > Pegel an seinem Reset-Pin der MCP überhaupt in den Reset geht. Es ist > zumindest denkbar, daß das Gebastel mit dem Transistor in diesem > Programmer den Pegel nicht tief genug absenken kann. Im Datenblatt steht nichts zum Verhalten der Pins während RESET. Aber es steht dort, dass der RESET-Zustand ab 0,15*VDD erreicht wird, also ab 0,75V. Das kann sein, dass da der Pegel nicht reicht. Das sollte dann aber hoffentlich mit nem neuen USB-Programmer gelöst sein. c-hater schrieb: > Aber natürlich hast du trotzdem Recht bezüglich der CS-Leitung. Denn > wenn der Programmierer angesteckt ist, zieht er ja nicht dauerhaft die > Reset-Leitung, sondern nur während eines Programmiervorgangs. Und im > Gegensatz zu richtigen Programmern, die außerhalb dieser Zeit ihr > ISP-Interface hochohmig schalten, macht das diese Billichkonstruktion ja > nicht. > Das könnte man mit einem zusätzlichen Transparent-Latch mit > Tristate-Ausgängen aber leicht ändern. Ein Problem wäre allerdings > dessen Stromversorgung aus dem Com-Port. Im konkreten Fall könnte man > das Latch aber auch leicht mit auf die Platine des Zielsystems legen und > aus dessen Versorgung mitversorgen. Ich habe aber über den CAN-Bus gemerkt, dass der AVR direkt vor dem Kaputtgehen noch Befehle gesendet hat, also er ist schon während des Programmiervorgangs gestorben. Aber wie gesagt, hoffentlich durch neuen Programmer gelöst. Ich bedanke mich auf jeden Fall für die vielen hilfreichen Ideen. Jetzt weiß ich wenigstens wo ich ansetzen kann :D
:
Bearbeitet durch User
Meldest Du Dich aber auch noch einmal, wenn es NICHT an dem Programmier- adapter gelegen hat? MfG Paul
Wie wird die Schaltung versorgt? Was hängt am CAN-Bus? Es kann durchaus sein, daß beim Einstecken des Programmers kräftige Ausgleichsströme fließen, um Aufladungen abzuleiten. Diese Ströme mögen dann die ISP-Anschlüsse nicht. Vor dem Anschließen des ISP-Adapters sollte immer erst GND der Schaltung mit GND des PC verbunden werden. Ich schütze auch immer VCC der Schaltung mit einer Transzorbdiode (SMBJ5.0A).
Paul Baumann schrieb: > Meldest Du Dich aber auch noch einmal, wenn es NICHT an dem > Programmier- > adapter gelegen hat? Klar, mach ich. Aber das wird jetzt ein wenig dauern bis ich dazukomme mir den anzuschaffen. Peter Dannegger schrieb: > Wie wird die Schaltung versorgt? Jacy Jung schrieb: > Als externe Quelle dient ein Netzgerät > mit stabilisierter 12V-Spannung, von extern sollte es also zu keinen > Spannungsspitzen kommen. Peter Dannegger schrieb: > Was hängt am CAN-Bus? Das gleiche Modul nochmal, das über einen USB<->TTL Konverter den Bus ausliest und die Befehle seriell an den PC sendet. Dieses Modul habe ich mit ISP programmiert ohne dass die MCPs eingebaut waren und da hat die Programmierung geklappt. Seither habe ich dort den Code nicht mehr geändert. Und natürlich die obligatorischen 120 Ohm Terminierungen beiderseits. Das Modul soll später jedoch per Bootloader über CAN programmiert werden können, aber um den Bootloader zu optimieren/testen muss ich es eben noch über ISP programmieren. Peter Dannegger schrieb: > Es kann durchaus sein, daß beim Einstecken des Programmers kräftige > Ausgleichsströme fließen, um Aufladungen abzuleiten. > Diese Ströme mögen dann die ISP-Anschlüsse nicht. > > Vor dem Anschließen des ISP-Adapters sollte immer erst GND der Schaltung > mit GND des PC verbunden werden. > > Ich schütze auch immer VCC der Schaltung mit einer Transzorbdiode > (SMBJ5.0A). Das Modul habe ich aber am ISP-Adapter eingesteckt gelassen. Das heißt es ist kaputt gegangen wo es schon eingesteckt war.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
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.