Forum: Mikrocontroller und Digitale Elektronik Kein Zugriff mehr auf Controller nach Falsh


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von undeat (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe einen ATMega644P geflashed. Nach dem Flashen hat der Controller 
nicht gestartet und er ist nicht mehr ansprechbar. Ich kann weder die 
Fuse Bits noch die Signatur auslesen.

Ich habe mit dem AVRStudio 4 geflasht. Als Programmer kam ein mini "STK 
500" zum Einsatz. Ich habe das Projekt bereits bestimmt über 100 mal 
geändert und mit dieser Hardware neu eingespielt. Nachdem der Controller 
nicht mehr ging habe ich einen anderen drauf gesteckt. Damit Dasselbe. 
Die Controller funktionieren auch nicht auf dem Evaluationsboard. Ich 
hab noch einen Normalen 644. Bei dem kann ich auf dem Eva Board und auf 
meiner Prototypen Platine Fuse Bits und Signatur wieder auslesen.

Im Forum hat jemand berichtet, dass bei ihm die Fuse Bits für die 
Taktquelle verstellt wurde. Werden die Fuse Bits überhaupt übertragen, 
wenn ich im AVRStudio den Flash Button drücke? Mit einem Externen Takt 
an XTAL1 und XTAL2 offen kann ich die gebrickten Controller auch nicht 
auslesen. Ich habe mit dem Programmer wieder erfolgreich andere 
Programme auf den 644 gespielt. Das läuft soweit.

Ich habe jetzt erstmal 4 neue ATMega644P bestellt. Die Dinger kosten 
aber jedesmal fast 8 Euro. Ich will eigentlich nicht noch einen Bricken 
und am liebsten auch die anderen wieder erwecken. Hat noch jemand eine 
Idee was man machen kann? Ist es überhaubt wahrscheinlich, dass die Fuse 
Bits überschrieben wurden? Ist eventuell mein Programm irgendwie größer 
geworden als es für den ATMega644P sein darf? Eigentlich habe ich nur 52 
Falsh belegt laut AVR Studio.

Einen HV Programmer hab ich nicht. JTAG auch nicht und JTAG ist auch 
disabled. Wenn es der Clock nicht ist, könnte ja nur noch der Reset PIN 
deaktiviert sein. Die Signatur müsste ich aber dann doch trotzdem 
auslesen können oder nicht?

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Ja, wenn man die Fuses auf external Clock setzt kann man ihn nicht mehr 
programmieren.

Nebenbei : Nachmessen, am Pin Clk-2 muss fuer korrekte funktion die 
Quarzfrequenz messbar sein, etwas 400mVpp oder so.

Abhilfe : Einen externen Clock, zB Funktionsgenerator oder sonstwas an 
den Pin Clk-1 anhaengen und neu programmieren.

Geschieht jedem mal. Kein Problem.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Bei einem Atmega644P ist es mir mal passiert, dass ein fehlerhaftes 
Programm den Controller so sehr blockiert hat, dass er nicht mehr 
programmierbar war.

Die Lösung war ganz simpel: Reset gedrückt halten, Stromversorgung 
einschalten, Flashen und erst danach den taster loslassen.

Offensichtlich hat es geholfen, das Programm nicht zu starten.

von undeat (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten. Das mit dem Reset hat leider nicht geholfen.
Wie ich im 1. Post beschrieben habe, hab ich das mit Externen Clock auf 
anlegen schon versucht. Der Quarz muss auch gehen, da ein anderer 644 
auf der Platine geht und weil ich 2 644P gebrickt habe.

Ich habe außerdem nicht bewusst die Fuse Bits geflasht sondern nur das 
Programm geladen.

von Georg G. (df2au)


Bewertung
0 lesenswert
nicht lesenswert
undeat schrieb:
> Ich habe außerdem nicht bewusst die Fuse Bits geflasht sondern nur das
> Programm geladen.

Dann nimm zum Flashen ein .HEX File. In den .ELF Files können auch die 
Fuses versteckt sein (und das EEPROM).

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
undeat schrieb:
> enn es der Clock nicht ist, könnte ja nur noch der Reset PIN
> deaktiviert sein. Die Signatur müsste ich aber dann doch trotzdem
> auslesen können oder nicht?

Nein. ISP ist nur im Reset aktiv, ohne den Pin also kein ISP möglich.

JTAG kann man sich eventuell aus einem USB FT2232 Adapter basteln.

Ansonsten: STK500 o.ä. bei IBäh besorgen und via HV Programmierung 
versuchen die Chips wiederzubeleben.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Eas gibt einige beliebte Fehler, die den AVR scheinbar disablen:

1. AVCC nicht angeschlossen.
2. AREF auf intern programmiert, aber außen mit VCC verbunden.
3. Prescaler des CPU-Taktes auf hohen Teiler gesetzt, aber nicht den 
ISP-Takt verringert.

Wenn Du das HEX brennst, können sich die Fuses nicht verstellen.

von undeat (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke nochmal für euer Bemühen,
leider kann ich die Vorschläge ausschließen. Vielleicht hatte es nicht 
deutlich genug geschrieben. Ich habe einen AVR auf einer Prototypen 
Platine. An der Software arbeite ich schon etwas länger und daher habe 
ich den AVR einige Male geflasht. Irgendwann hab ich eine Zeile im 
Programm geändert (Zusätzliche Übertragung eines Strings per UART0), 
dass dann übertragen und dann ging der AVR nicht mehr. Dann hab ich 
einen anderen drauf gesteckt, den konnte ich erst auslesen, hab dann 
geflashed und dann ging auch der nicht mehr. Die AVR gehen auch auf dem 
EVO Board nicht. Hardwarefehler auf der Platine kann man daher 
ausschließen. Mit einem Takt an XTAL kann ich den AVR auch nicht wieder 
beleben. Also dieses Fuse Bit kann ich auch ausschließen. Außerdem habe 
ich nochmal nachgesehen. Im AVR Studio Projekt ist ganz klar 
eingestellt, dass nur die .Hex File geflashed wird. Außerdem ist der 
Haken bei Erase device gesetzt und bei verify nicht. Die Optionen für 
die ELF sind leer. Ich habe auch das Fenster zum Auslesen und ändern der 
Fuse bits nicht angefasst.

Naja ich denke, es kann nur sein, dass es beim Flashen zu einem 
Übertragungsfehler gekommen ist und unbeabsichtigt Fuse oder Lockbits 
überschrieben wurden. An dieser Theorie wundert mich nur, dass es zwei 
mal kurz nacheinander aufgetreten ist und vorher 100 mal gar nicht. Was 
ich allerdings beobachtet habe ist, dass der Controller manchmal öfters 
nacheinander geflasht werden musste, da er sonst das Programm nicht 
gestartet hat. (Verify war aus).

Dann muss ich mir wohl mal jemanden mit einem STK500 suchen. Vielleicht 
kann man die Controller wieder Retten. Dennoch würde ich die Ursache 
gerne wissen, da ich keine weiteren AVR bricken will.

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>An dieser Theorie wundert mich nur, dass es zwei
>mal kurz nacheinander aufgetreten ist und vorher 100 mal gar nicht.

Kabelbruch im Programmierkabel?

von Georg G. (df2au)


Bewertung
0 lesenswert
nicht lesenswert
undeat schrieb:
> jemanden mit einem STK500 suchen

Wie in so vielen ähnlichen Fällen, in denen Hardware suspekt ist, wäre 
es sinnvoll, wenn du deine Postleitzahl nennen würdest. Dann kann man 
sich ggfs persönlich treffen und du hast mehr von der Aktion. Ansonsten 
musst du zweimal Porto spendieren.

von Undeat (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kabelbruch in Programmer? Dagegen würde sprechen das ich den avr mit dem 
ich den Takt für xtal generiert habe ohne Probleme flashen konnte.

Plz wäre 37671 aber da glaub ich nicht dran das ich hier jemanden finde 
?.

In Paderborn ist glaube ich ein fablab.  Aber das sind auch 60km und ne 
Stunde Fahrzeit.

von wendelsberg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
undeat schrieb:
> Ich habe auch das Fenster zum Auslesen und ändern der
> Fuse bits nicht angefasst.

Vielleicht waere es an der Zeit, einfach mal zu pruefen, was genau darin 
steht.

wendelsberg

von undeat (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da steht ja immer genau das drin was zuvor vom Controller ausgelesen 
wird, sofern das geht. Das geht bei meinem aber ja schon nicht mehr.

Wenn man das Fenster öffnet wird der Istzustand ausgelesen, dann kann 
man was ändern und dann muss man es explizit flashen bevor man das 
Fenster wieder zu macht. Meine neuen AVR sind heute eingetroffen. Ich 
werde sicherheitshalber mal das GSM Modul abschalten bevor ich flashe. 
Nicht dass das Störung gemacht hat. Wenn ich dann keiner mehr brickt ist 
es ja ok, aber wenn dann noch ein 3. kaputt geht, dann muss echt die 
Ursache gefunden werden :(.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Nochn möglicher Fehler:

SPI-Slave mit an ISP und den Pullup an /SS vergessen.

von undeat (Gast)


Bewertung
0 lesenswert
nicht lesenswert
SPI wird leider nur zum Proggen benutzt

von tommy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hast Du mal an ESD als Ursache gedacht?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.