Moin, ich programmiere gerade einen ATMEGA644 mit dem Atmel Studio 7. Die Spannungsversorgung erfolgt über einen USB-Port, der ATMEGA644 selbst läuft mit 3.3V. Zu Testzwecken lief die Schaltung an einem Rechner, der auch nachts an ist; auf diesem kann ich allerdings nicht programmieren. Um jetzt etwas an meinem Programm zu ändern, musste ich die Verbindung trennen und an meinen anderen Rechner stecken. Da Prgramm des uCs ist jedoch nicht mehr gestartet, erkennbar an dem fehlen einer Ausgabe per UART und das Nichteinschalten von zwei LEDS. ich dachte mir, das Problem könnte durch eine Neuprogrammierung behoben werden. Leider brachte das keinen Erfolg, das Ergebnis war immer noch gleich: keine Funktion. Was ich bisher geprüft habe: Betriebsspannung korrekt, Clock vorhanden, Reset auf high. Alles trifft zu, daran kann es also nicht liegen. Um zu verhindern, dass ewentuell das I2C-Device auf dem Baord nicht antwortet, die Abfrage diese ausgeschaltet um nicht in einer Endlosschleife hängen zu bleiben. Zum Testen ein einfaches Programm benutzt, welches nur die LED toggeln soll. Auch keinerlei Funktion. Merkwürdigerweise lässt sich der uC laut Atmel Studio noch korrekt programmieren. Auch das Ändern von Fuses ist problemlos möglich. Was könnte der Fehler sein, dass der uC trotz erfolgreicher Programmierung nicht mehr arbeitet, obwohl er das schon getan hatte? gruß
Hmm, bleibt ja nicht mehr viel. - klemme alle Peripherie ab außer LED und Vorwiderstand, - Nimm mal einen zweiten Chip / anderen AVR und vergleiche, - Bootloader - Fuse gesetzt mit fehlerhaftem Bootloader?
Rainer U. schrieb: > - klemme alle Peripherie ab außer LED und Vorwiderstand, Leider nicht so einfach möglich, da es sich um ein Board handelt und die Peripherie als SMD vorliegt. Ist außer einer RTC und einem USB-UART-Chip auch nicht weiter angeschlossen (und die LED) Rainer U. schrieb: > - Nimm mal einen zweiten Chip / anderen AVR und vergleiche, Kann ich aus den bereits erwähnten Gründen nicht machen, da es sich auch hierbei um SMD handelt. Mir fehlt es leider an Equipment ihn zu tauschen. Rainer U. schrieb: > - Bootloader - Fuse gesetzt mit fehlerhaftem Bootloader? War bisher keiner drauf, der Controller hatte bereits erfolgreich funktioniert, nur nach einem "Tausch" des Rechners nicht mehr. Resets sind aber schon vorher erfolgt, dann hätte das Problem ja schon früher auftreten müssen, oder eher nicht? Also muss schon fast davon ausgehen, dass der uC defekt ist?
Die Spannung, gemessen direkt an den Pins Vcc und GND ist ok? Der Oszillator schwingt? Hast du einen zweiten 644 zum Testen?
Jörg schrieb: > Die Spannung, gemessen direkt an den Pins Vcc und GND ist ok? > > Der Oszillator schwingt? > > Hast du einen zweiten 644 zum Testen? Ja direkt an den Pins, 3,29V sollten ausreichend sein. Der Oszillator tut seinen Dienst (gemessen) Theoretisch ja, nur Tauschen kann ich ihn im Moment nicht.
Marco G. schrieb: > Leider nicht so einfach möglich, da es sich um ein Board handelt und die > Peripherie als SMD vorliegt. Verstehe, dann spiel halt Dein Programm auf einen zweiten gleichen Chip mit gleichen Fuses auf einem anderen Board ohne Peripherie und guck, ob es da läuft. Man glaubt gar nicht, wie man sich selbst austricksen kann. Mir ist es z.B. mal passiert, dass mein Programmier-Tool eine falsche Datei geflasht hat - und ich hab ewig gemessen und rumprogrammiert.. :-)
:
Bearbeitet durch User
Ein ähnliches Problem hatte ich auch bei einem Board. Hier war der Programmer schuld, der ein undefiniertes Dauer-Reset an die MCU legte. Erst durch Abziehen des Programmers startete die MCU.
Marco G. schrieb: > Merkwürdigerweise lässt sich der uC laut Atmel Studio noch korrekt > programmieren. Auch das Ändern von Fuses ist problemlos möglich. Bekommst Du denn die Fuses bei einem Read richtig und reproduzierbar angezeigt?
Bei mir war mal der GND-Pin von einem ATTINY2313 (SMD) nicht richtig angelötet. War sehr irritierend, dass die angeschlossenen LEDs sogar ca. das getan haben was sie sollten, aber manche Funktionen garnicht mehr getan haben. Wenn du das Board selbst gelötet hast, prüf also nochmal alle Pins genau durch, ob die auch wirklich sauberen Kontakt mit dem Board haben.
Rainer U. schrieb: > Mir ist es z.B. mal passiert, dass mein Programmier-Tool eine falsche > Datei geflasht hat - und ich hab ewig gemessen und rumprogrammiert.. :-) Das kenn ich auch, allerdings eher mit dem EEPROM-file. Da habe ich auch schon wundersame Dinge mit erlebt. BlaBla schrieb: > Ein ähnliches Problem hatte ich auch bei einem Board. Hier war der > Programmer schuld, der ein undefiniertes Dauer-Reset an die MCU legte. > Erst durch Abziehen des Programmers startete die MCU. Macht mein Programmer auch, allerdings nur wenn der Rechner ausgeschaltet ist. Außerdem hatte ich es auch ohne aufgesteckten Programmer probiert. Der Fehler trat ja nach trennen der Vorsorgung und Wiederherstellen dieser. Pete K. schrieb: > Bekommst Du denn die Fuses bei einem Read richtig und reproduzierbar > angezeigt? Ja, es sind immer reproduzierbar die (korrekten) Fuses, die ausgelesen werden. Robin R. schrieb: > Bei mir war mal der GND-Pin von einem ATTINY2313 (SMD) nicht richtig > angelötet. War sehr irritierend, dass die angeschlossenen LEDs sogar ca. > das getan haben was sie sollten, aber manche Funktionen garnicht mehr > getan haben. Wenn du das Board selbst gelötet hast, prüf also nochmal > alle Pins genau durch, ob die auch wirklich sauberen Kontakt mit dem > Board haben. Ja das Board ist selber gelötet, allerdings hinterher mit den Mikroskop überprüft. Auch mittels druck auf den Chip läuft der uC nicht mehr.
Marco G. schrieb: > Da Prgramm des uCs ist jedoch nicht mehr gestartet, erkennbar an dem > fehlen einer Ausgabe per UART und das Nichteinschalten von zwei LEDS. > ich dachte mir, das Problem könnte durch eine Neuprogrammierung behoben > werden. Leider brachte das keinen Erfolg, das Ergebnis war immer noch > gleich: keine Funktion. Dann ist vielleicht etwas in der internen Peripherie des Controllers duch!? Dann hilft Neuprogrammieren auch nichts. Rainer U. schrieb: > Verstehe, dann spiel halt Dein Programm auf einen zweiten gleichen Chip > mit gleichen Fuses auf einem anderen Board ohne Peripherie und guck, ob > es da läuft. Man glaubt gar nicht, wie man sich selbst austricksen kann. Das würde ich auch als nächstes ausprobieren. Du kannst den zweiten Controller ja auf einem Steckbrett aufbauen oder als Deadbug fliegend verlöten.
Wie kann es denn dazu kommen, das die interne Peripherie schaden nimmt. Der Fehler trat ja nach dem Abziehen vom USB-Port auf. Das Programm nicht aber mein Blinky. Allerdings ist auch die Srromaufnahmexdes Boards gesunken was heisst das der originale uC far nicht mehr zu arbeiten scheint
Marco G. schrieb: > Wie kann es denn dazu kommen, das die interne Peripherie schaden nimmt. > Der Fehler trat ja nach dem Abziehen vom USB-Port auf. Statische Überspannungen, Produktionsfehler, ...
Natürlich, ich benutze den ADC also muss AVCC angeschlossen sein ;) Außerdem handelt es sich um einen Fehler, der bei einem bereits funktionierenden Board aufgetreten ist. Außerdem mache ich keinen unterschied, ob ich die ADCs benötige oder nicht, AVCC wird immer angeschlossen
:
Bearbeitet durch User
Hallo Macro, Peter wollte nur darauf hinweise, dass der Pin AVcc immer mit dem Pegel von Vcc verbunden werden muss. Nutzt man der ADC, ist es sinnvoll zwischen Vcc und AVcc ein C-L-C Filter zu setzen.
Der Unterschied zwischen VCC und AVCC beträgt nur ca 3mV. Ich denke das sollte kein Problem darstellen. Einen solchen Filter habe ich jetz nicht drin, sollte aber nicht zum Ausfall des uCs führen.
Hallo Marco, da du den µC Neuprogrammieren und sogar problemlos an Fuses kommst. Schließe ich mal ein defekt des µC aus. Eins verwundert mich aber das die Stromaufnahme nun geringer ist. Ist ja eigentlich ein Zeichen das der µC schläft oder nicht mehr getaktet wird. Mein Vorschlag: Im Programm vor Do Loop eine Ausgabe per UART setzen(Print “Bla Bla“) und mit Terminal anzeigen. Kommt nach anlegen der Spannung oder Reset die Anzeige nicht. Ist meine erste Vermutung VCC ist kleiner Brown-out, wenn im Fuses auf ein enabled gesetzt. Gruß Fred
Jetzt wird es ganz merkwürdig. Nachdem ich die Schaltung etliche Stunden von einer Quelle getrennt hatte habe ich sie jetzt wieder an den Rechner gesteckt um die Vorschläge von Fred zu prüfen. auf jeden Fall läuft die Schaltung nun wieder. Was jetzt genau das Problem war lässt sich ncht wirklich nachvollziehen.
Marco G. schrieb: > Jetzt wird es ganz merkwürdig. Nachdem ich die Schaltung etliche Stunden [...] Evtl. hat es was mit der Temperatur zu tun? Ansonsten klingt das doch eher nach einer geladenen Kapazität die Mist baut.
Hallo Marco, dies währ für mich das übelste Verhalten was es nur geben kann. Großer Fehler(Totalausfall) nun plötzlich und unerwartet alle wieder okay. Es sei denn es war nur eine Kontaktsache. Die hattest du aber ausgeschlossen. Gruß Fred
das macht mir auch ein wenig sorgen. da es sich um ein privates Projekt handelt, ist das nicht dramatisch. Trotzdem unschön... Aber ich hatte den uC mehrmals per Mikroskop geprüft.
Marco G. schrieb: > Natürlich, ich benutze den ADC also muss AVCC angeschlossen sein AVcc muss immer angeschlossen werden. Das A ist nur der Hinweis, dass die Analogmodule ihre Versorgung von diesem Pin bekommen und man bei der Verwendung der Analogmodule gut beraten ist, hier noch einen extra Filter einzusetzen. Aber angeschlossen werden muss dieser Pin immer. Marco G. schrieb: > Was jetzt genau das > Problem war lässt sich ncht wirklich nachvollziehen. Da tippe ich auf eine fiese Lötstelle.
M. K. schrieb: > AVcc muss immer angeschlossen werden. Das A ist nur der Hinweis, dass > die Analogmodule ihre Versorgung von diesem Pin bekommen und man bei der > Verwendung der Analogmodule gut beraten ist, hier noch einen extra > Filter einzusetzen. Aber angeschlossen werden muss dieser Pin immer. Muss nicht.... Sollte aber auch wenn ADC nicht genutzt wird. Wird oft falsch verstanden. AVCC = VCC haben eben eine „Saulange interne Verbindung“ nicht nur der Spannungsabfall sonder der kapazitive Kurzschluss ist nicht von ohne.(Taktabhängig) Also last mal den Hinweis: “wird AVCC nicht mit VCC verbunden geht nichts mehr.“ Stimmt so nicht. Wenn es so währe, würden doch die Hersteller die Strippen intern extrem niederohmig verbinden und hätten noch 2 Pin frei. Ja die Entwickler wussten und wissen wie die internen Motoren zuverlässig und unabhängig drehen sollen, eine zweite Spritzufuhr anzubieten war wohl das Okay und natürlich auch eigennützig. Anwender muss entscheiten wie µC optimal beschaltet wird. Gruß
Fred R. schrieb: > Muss nicht.... Sollte aber auch wenn ADC nicht genutzt wird. > ... Doch, muss. In den Datenblätter steht zwar "It should be" aber wir haben es hier im Forum schon oft erlebt: Ist AVcc nicht angeschlossen kann der AVR zu merkwürdigem Verhalten tendieren. Beim letzten Problem, an das ich mich hier erinnere, und dessen Ursache ein nicht angeschlossener AVcc war, war das Problem, dass der AVR (ich mein es war ein Atmega328) bei rund 3.3 V Vcc nicht anlief. Kaum war AVcc angeschlossen war das Problem behoben. Fred R. schrieb: > AVCC = VCC haben eben eine „Saulange interne Verbindung“ nicht nur der > Spannungsabfall sonder der kapazitive Kurzschluss ist nicht von > ohne. Intern sind die, wenn überhaupt, nur hochohmig miteinander verbunden und das mit voller Absicht: Man will ja grade, dass AVcc nur ein gefiltertes Vcc bekommt, das praktisch nicht gestört wird wegen dem ADC. Nur wenn man den ADC nicht braucht kann man Vcc mit AVcc brücken, ansonsten sollte man immer einen Filter einsetzen.
Zufällig mit Lötfett oder so gelötet und die Platine ist schon ein paar Monate alt?
Kannst du eine zweite Platine bauen? Dann kannst du gucken, ob die Probleme damit auch auftreten.
Alex W. schrieb: > Poste doch mal ein Bild vom Aufbau und die Schematik der > Schaltung! Genau! Ohne das ist alles nur Stochern im Nebel.
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.