Hallo Leute! Kann mir jemand sagen, ob ich meine ATmega8 Controller weg schmeißen kann, oder ob es noch Hoffnung gibt? Bin ein blutiger Anfänger und habe zwei meiner ATmega8 zur Unprogrammierbarkeit getrieben, indem ich ihre Spannungsversorgung beim Flashen unterbrochen habe. Programmer: USB ASP (Bausatz von Ulrich Radig) hab den auf Low SPI Speed gestellt, weil im schnellen Modus hatte ich ebenfalls einen hohen Verschleiß an Controllern -.- -geschrieben wird immer mit AVR-Dude über programmers notepad aus dem Win-AVR Paket, wie es mich das Tutorial hier gelehrt hat. die Problemsituation: Ich wollte ein neues Hex-File aufspielen und hatte die Spannungsversorgung vergessen einzuschalten. Der Programmiervorgang startete trotzdem, weil in der Schaltung ein Servo angeschlossen war, dessen Kondensatoren noch genügend Ladung inne hatten, um eine Kommunikation aufzubauen (ich bin Anfänger und hab mich dagegen nicht mit Dioden in der Schaltung abgesichert, war dumm^^). Leider brach dann bei der Hälfte ca die Kondensator-Spannung ein und seit dem kann ich nur noch die Fuses auslesen (mit AVR-Burner und dem selben USB-ASP) und nicht mehr Flashen. Ich hab standardmäßig immer den Erasevorgang angeschaltet und die Verifizierung auch, hab mir keine großen Gedanken gemacht, ob man da was ändern sollte. Meine Fragen: Was ist so schlimm an einem Spannungsabfall beim Flashen? Man zerstört doch kein wichtiges Dateisystem oder sowas, man überschreibt doch nur, dachte ich. Kann man die Controller wieder "heile machen"? Ist das so OK und EEPROM-schonend, wenn ich den Erase-Vorgang an lasse, das war so voreingestellt.
Vielleicht kannst Du Dir ein STK500 leihen, damit lassen sich alle Deine AVRs wiederbeleben. Ich benutze fürs SPI-Proggen das STK500 bzw. AVR-ISP MK2 und habe damit noch keinen einzigen AVR ausgesperrt. Ich hab nur einmal einen ATtiny26 ausgesperrt, weil ich mich bei den Fuses verklickt hatte. Hab ihn dann wiederbeleben müssen (HVP-Modus). Will man nur neu flashen, dann besser die Fuses nicht anfassen. Neuere AVR-GCC legen im ELF-File auch die Fuses ab und dann werden sie unnötiger Weise immer mit geschrieben. Am sichersten ist für das häufige Programmieren ein Bootloader. Da ein Bootloader nicht die Fuses ändern kann, ist ein Aussperren ausgeschlossen. Je nach Außenbeschaltung sollte man zusätzlich noch nen Pullup (4,7k) an den SCK-Pin hängen um damit ein versehentliches SPI-Takten zu verhindern. Dann kann auch keine eingekoppelte Brummspannung zufällig ein Fuse-Write bewirken. Mit USB ASP und AVR-Dude kenne ich micht nicht aus. Erase muß sein, aber das automatische Fuse schreiben solltest Du beim AVR-Dude ausschalten. Peter
ah ok danke, da waren ja schon mal mehrere Anhaltspunkte drinn, womit ich mich wieder erst ma auseinander setzen muss. der Widerstand ist schnell verlötet (auch wenns daran ja nicht lag). Das mit dem ELF ist interessant, auch wusste ich nicht, dass der jedes mal die Fuses schreibt, das ist ja echt übelst gefährlich, nur an ein STK500 komm ich nicht, bin noch an keiner Hochschule oder sowas, ich bin 20Jahre alt und mach das nebenbei als hobby, wenns der Abi-Stress zulässt.
Hallo! Schau Dir mal die Internetseite an: http://www.tuxgraphics.org/electronics/200705/article07052.shtml Ich habe mir den Programmer vor kurzen auch nachgebaut und er funktioniert tadellos. Allerdings weis ich nicht ob man den Programmer mit einem original STK500 Board vergleichen kann, aber zumindest arbeitet er mit dem STK500v2 Protokoll. LG Jens
> Was ist so schlimm an einem Spannungsabfall beim Flashen? Man zerstört > doch kein wichtiges Dateisystem oder sowas, man überschreibt doch nur, > dachte ich. Wenn die Versorgungsspannung zu niedrig ist, tut der Controller manchmal seltsame Dinge. Gerade während des Programmierens kann es dann passie- ren, dass die Fuses verändert werden. Die meisten Fuses sind relativ unkritisch und können anschließend wieder korrigiert werden. Wenn es aber die Fuses zur Konfiguration der Taktquelle erwischt hat, springt der Controller anschließend evtl. nicht mehr an. Das ist bspw. dann der Fall, wenn fälschlicherweise ein Quarz konfiguriert wurde, obwohl gar keiner angeschlossen ist. > Kann man die Controller wieder "heile machen"? Am einfachsten und sichersten geht es so, wie Peter geschrieben hat. Hast du kein STK500, hilft es meist, dem Controller mit einem externen Takt Starthilfe zu geben. Dazu nimmst du irgendetwas, was ein Rechteck- signal von 1 bis 8MHz erzeugt, bspw. einen Quarzoszillator, einen Funktionsgenerator oder einen weiteren AVR. Dieses Signal legst du am XTAL1-Pin des Controllers an, XTAL2 bleibt frei. Ist an XTAL1 und XTAL2 bereits ein Quarz angeschlossen, stört dieser normalerweise nicht. Jetzt sollte es wieder möglich sein, in den Programmiermodus zu gelangen und die Fuses auf die richtigen Werte zurückzusetzen. Ist dies gesche- hen, kannst du die externe Taktquelle wieder wegnehmen, und der Control- ler sollte wieder von alleine anlaufen. Damit das Problem in Zukunft nicht wieder auftritt, solltest du auf dem Controller den Brownout-Detektor aktivieren. Dadurch geht der Controller bei Unterspannung in den Reset-Zustand und tut keine seltsamen Dinge mehr. @Jens: > Allerdings weis ich nicht ob man den Programmer mit einem original > STK500 Board vergleichen kann, aber zumindest arbeitet er mit dem > STK500v2 Protokoll. Nicht das richtige Protokoll ist entscheidend, sondern die Möglichkeit, den Parallel-Programming-Modus zu verwenden. Diesen Modus unterstützt der Programmer in deinem Link aber nicht.
Ich verwende einen externen quarz mit kondensatoren und für die nächsten Projekte habe ich auch schon Quarzoszillatoren hier liegen, weil ich eh nichts Zeitkritisches in der Einschwingzeit mache, kann ich die auch locker nehmen. Die Fuses stimmen ja auch noch am quarz, ich werde die aber noch ma auslesen um ganz sicher zu sein. Das war ja das komische, Fuses kann ihc vllt sogar noch ändern, nicht nur auslesen, nur ich kann keinen Code aufspielen, ich check das noch mal. Jo danke an Euch alle, mein Fazit: 1.) die kaputten uC aufbewahren, vllt bin ich ja ma an ner technischen FH und darf mit nem STK500 spielen und reanimieren^^ 2.) ich werde mich um das ELF-File kümmern, versuchen, dass nicht immer die Fuses mitgeschrieben werden, sau gefährlich is das ja 3.) Ich werde mich mal um Bootloader kümmern, hab die dinger bisher verdrängt, ich dachte ich brauch das nich, aber die geben ja schon Sicherheit. Da war auch was im tutorial drüber zu finden, glaub ich. 4.) Die 4,7kOhm werden auch noch an den SCK kommen, das gewöhn ich mir auch an. 5.) Den Brownout-Detektor muss ich mir auch noch vornehmen. Noch ma danke für die vielen Ratschläge, jetzt bin ich wieder auf dem richtigen weg^^
> Die Fuses stimmen ja auch noch am quarz, ich werde die aber noch ma > auslesen um ganz sicher zu sein. Das war ja das komische, Fuses kann > ihc vllt sogar noch ändern, nicht nur auslesen, nur ich kann keinen > Code aufspielen, ich check das noch mal. Wenn du die Fuses tatsächlich noch ändern kannst, den Flash-Inhalt aber nicht, dann bringt weder das STK500 noch der Oszillatortrick etwas und der Controller ist wahrscheinlich wirklich hinüber.
Ein anderer Punkt der leicht zu fehlern beim Programieren führt ist, wenn das kabel zwischen Programmer und der Platine zu lang ist. Wenn man sicher sein will sollten es nicht mehr als 20 cm sein. Etwas hilft hier auch ein Widerstand von 50-100 Ohm in der SCK Leitung, direkt am Programmer. Das ist dann eine Art von Leitungsterminierung. Bei einer selbstgelöteten Schaltung kann man das ja eventuell nachrüsten.
@yalu: Das mit dem Verändern der Fuses teste ich gleich noch mal zur Sicherheit. wenns nicht geht, schmeiß ich die beiden weg, ich hab ja genug Ansätze bekommen, um mich in Zukunft besser abzusichern. @Ulrich: Sofern der Controller seine stabilen 5V hatte, war das nie das Problem, is ne doppelseitige industrille Platine auf der der Programmer aufgebaut wurde. daher kann ich da nich so gut rum fummeln, ich denke das wird auch nicht nötig sein. Solange mir dieser Spannungsunfall nicht passiert, ist auch immer alles 100%ig gelaufen. ich mach aber 4,7Ohm an die SCK an meiner zu programmierenden Platine. das Flachbandkabel hat keine 10cm und daher kann man da auch sicher sein, dass die Kabellänge hier nicht relevant war. Aber danke für den Tip, das wird ja auch zu oft nicht bedacht, kennt man aus dem Forum. Die Leute meinen immer zu schnell mit dem tutorial fertig zu sein, meiner Meinung nach ist das mehr ein Nachschlagewerk als nur ein einfaches tutorial. Dafür und für die Möglichkeit hier spezielle Fragen zu stellen, liebe ich diese Seite!^^
Hi >Ein anderer Punkt der leicht zu fehlern beim Programieren führt ist, >wenn das kabel zwischen Programmer und der Platine zu lang ist. Wenn man >sicher sein will sollten es nicht mehr als 20 cm sein. Ist sehr vom Progammer abhängig. Mit Equinox EPSILON5 MKII, STK500, AVRISP MKII sind Prgrammierkabel mit einer Länge von 1..1,5m kein Problem. MfG Spess
Oben wurde gesagt, dass AVR-Dude beim Flashen auch immer die Fuses mit brennt. Da das so gefährlich ist, will ich das abstellen und ich suche den ganzen Tag danach, wie das geht. Weiß da jeman Rat? Ich finde im Internet keinen Hinweis darauf. Wenn ich das Schaffe, dann benötige ich auch keinen Bootloader mehr. ich finde das unnötig, ich hab ja eh einen Programmer hier und kann dann die Bootloader Sektoren als Anwendungs-speicher mit nutzen. Wie das mit dem Brownout-Detector läuft, weiß ich jetzt ^^ Sehr komfortabel über die Fuses einstellbar.
Ulrich Ter horst schrieb: > Oben wurde gesagt, dass AVR-Dude beim Flashen auch immer die Fuses mit > brennt. Nö, nicht immer. Es ist möglich, daß im ELF-File die Fuses mit eingebunden werden und dann von einem Programmer, der ELF versteht, gebrannt werden. Ob das aber bei Dir so eingestellt ist, weiß ich nicht. Mußt mal im Manual zu AVR-Dude nachschauen. Peter
> Es ist möglich, daß im ELF-File die Fuses mit eingebunden werden und > dann von einem Programmer, der ELF versteht, gebrannt werden. Ob das > aber bei Dir so eingestellt ist, weiß ich nicht. Mußt mal im Manual zu > AVR-Dude nachschauen. Der Avrdude kann ELF-Files nicht direkt verarbeiten. Sie müssen erst mit avr-objcopy in Intel Hex, Motorola S-record oder raw binary konvertiert werden. Da keines dieser Dateiformate Sections unterstützt, muss für jede Section eine eigene Datei angelegt und dem Avrdude per -U-Option übergeben werden. Daran kann man leicht sehen, ob Fuses geschrieben werden, nämlich nur dann, wenn der Aufruf von Avrdude Optionen der Form -U lfuse:w:… -U hfuse:w:… -U efuse:w:… enthält.
das war hilfreich! Übrigens, kann ich ich die Fuses nur noch lesen, nicht mehr beschreiben.
blinch schrieb:
> Übrigens, kann ich ich die Fuses nur noch lesen, nicht mehr beschreiben.
Da es beim Lesen kein ACK gibt, ist das völlig ohne Bedeutung.
Ob Du Verbindung zum MC hast, kannst Du nur dadurch feststellen, daß die
Signatur stimmt.
Peter
ah ok danke^^ "Wenn du die Fuses tatsächlich noch ändern kannst, den Flash-Inhalt aber nicht, dann bringt weder das STK500 noch der Oszillatortrick etwas und der Controller ist wahrscheinlich wirklich hinüber." Fuses kann ich nicht ändern --> keine Verbindung kommt zu stande Und wegen der der zitierten Aussage hier heißt das: Es könnte sein, dass ein STK500 immer noch eine letzte Rettung sein kann? also erst ma nicht in den Elektronikschrott mit den Controllern? Ich frag nicht nur wegen Pfennigfuchserei, sondern auch wegen meinem Verständnis zum Prinzip.
den letzten atmega8 wo ich die fuses zerbombt habe und nicht mehr drangekommen bin (nein es war nicht nur ein falsch eingestellter oszillator) hab ich ich danach naja nennen wir es UHV programmiert, damit ich nicht auf die idee komme für sowas einen stk500 zu kaufen oder einen HV progger zu bauen.
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.