Hallo hochgeschätztes Forum, ein ganz konkretes Problem mit dem flashen eines HEX files (konkret ein Ethersex Kompilat) auf einen ATmega644P in einem NetIO: Das flashen scheint erstmal zu funktionieren. Danach scheitert aber die Verifikation. Ich meine sogar gleich an der Adresse 0. Es scheint immer noch das alte Image auf dem Controller zu sein. Dieses funktioniert aber so gut (oder schlecht) wie vor dem Programmierversuch. Ich habe bereits: -AVR Studio von 6.1 auf 6.2 aktualisiert. Verwendet habe ich hier einen AVR Dragon. Keine Besserung. -Einen China USB ISP Programmierer mit avrdude verwendet. Gleiches Verhalten. -Alle Leitungen des 6 poligen ISP Steckers bis zu den Controller PINs durchgemessen. Alles ok. Signatur auslesen geht, Fuses scheinen aber auch nicht gesetzt zu werden. Der Programmierjumper auf dem NetIO ist gesetzt. Ist es wahrscheinlich, dass hier der ATmega schaden genommen hat und nun meine versuche konkret ignorierte? Gibt es eine Schreibschutz Fuse die ich gesetzt haben könnte? Oder hat evtl. mein HEX File / Kompilat einen Fehler der dazu führt, dass dieses vom Controller ignoriert wird? Vielen Dank schonmal! Peter
Peter H. schrieb: > Fuses scheinen aber auch nicht gesetzt zu > werden. Du kannst die Fuses auslesen. Du brauchst Dich nicht auf Vermutungen zu verlassen.
Das, was du schilderst, klingt nach gesetzten Lockbits. Hast du evtl. das Häkchen zum automatischen Löschen vor dem Programmieren nicht gesetzt? Lösch ihn manuell. Dann müssen das alte Programm und auch evtl. Lockbits in jedem Fall gelöscht sein. Ist das nicht so, passt irgendwas an deiner Verbindung nicht oder der Controller ist i.A.. Ich hab sowal mal mit einem 1284 gehabt. Der lief, liess sich aber weder über JTAG noch über ISP programmieren. Peter H. schrieb: > Oder hat evtl. mein HEX File / Kompilat einen Fehler der dazu führt, > dass dieses vom Controller ignoriert wird? Nein. Der Controller ist dämlich. Der weiss gar nichts von einem Hexfile, sondern bekommt lediglich Binärdaten vom Programmer. mfg.
:
Bearbeitet durch User
Vielen Dank für die schnellen Antworten! Die lockbits klangen gut. Leider sind sie es scheinbar nicht. Sind laut AVR Studio nicht gesetzt. Ich haben dann noch mal versucht den Controller im STK500 mit meinem Dragon zu programmieren. Gleiches Verhalten. Er ignoriert übrigens auch mein Versuche Fuses zu setzen. Ich geben den Controller dann mal auf. Hoffentlich kommt der ersatzweise bestellte heute an. Wenn mal ganz viel Zeit totschlagen werden muss werde ich den mal mit High Voltage programmier Methoden attackieren... Gruss Peter
Peter H. schrieb: > Er ignoriert übrigens auch mein Versuche Fuses zu setzen. Der 1. Punkt bei Problemen ist, die Signatur zu lesen. Solange das nicht klappt, sind alle weiteren Aktionen sinnlos. Das SPI-Protokoll enthält keinerlei Bestätigung, ob eine Aktion geklappt hat. Peter H. schrieb: > Ich geben den Controller dann mal auf. Warum? Du kannst ihn im STK500 doch parallel programmieren.
Ich hatte vor einiger Zeit auch mal Probleme, auf neue Atmega8 zuzu- greifen. Manche ließen sich "normal" ansprechen, andere stellten sich tot. Das veranlaßte mich, diese Schaltung hier: http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en zu bauen. Ich habe es nicht bereut. Seitdem wird jeder neue Kontroller erst mal dort drin "behandelt" und danach hatte ich keine Schwierigkeiten mehr. MfG Paul
Ich habe es nun auch mal mit HVPP im STK500 probiert. Gleiches Resultat. Es wird scheinbar geschrieben aber dann scheitert die Verifikation gleich an der ersten Adresse. Device-Erase wird ignoriert wie alles andere. Der inzwischen eingetroffene neue 644P lässt sich wunderbar beschreiben. Macht die Fuse-Doctor Schaltung etwas anderes als ein STK500 mit HVPP? Gruss Peter
Peter Dannegger schrieb: > Der 1. Punkt bei Problemen ist, die Signatur zu lesen. Peter H. schrieb: > Signatur auslesen geht Peter H. schrieb: > aber dann scheitert die Verifikation gleich an der ersten Adresse. Bis hier klingt es nach gesetzten Lockbits. Da kann man auch die Signatur lesen, und die Lockbits und Fuses, aber nichts anderes (Speicherinhalte). Und das Chip erase muß eigentlich immer gehen... > Device-Erase wird ignoriert wie alles andere. Wenn auch das Erase nicht geht, würde ich tatsächlich auf eine Macke im µC tippen. Vor allem, wenn die gleiche Aktion mit einem neuen Chip funktioniert. Eine Möglichkeit fällt mir gerade noch ein. Ist vielleicht der Reset-Pin wegprogrammiert? Also als normaler Pin genutzt? Ach nee, dann würde ja auch das Auslesen der Signatur nicht gehen... Also vermutlich doch irgendwas im µC selbst kaputt.
Peter H. schrieb: > Ich habe es nun auch mal mit HVPP im STK500 probiert. Gleiches Resultat. > Es wird scheinbar geschrieben aber dann scheitert die Verifikation > gleich an der ersten Adresse. Device-Erase wird ignoriert wie alles > andere. Natürlich auch da immer zuerst die Signatur lesen! Ich hatte mich beim HVPP auchmal dumm angestellt und irgendein Käbelchen oder Jumper falsch gesteckt. Aber kaum macht mans richtig, funktionierts.
Signatur lesen hat auch über HVPP mit dem STK500 geklappt. Bin mir nicht ganz sicher, ob ich evtl. zwischendurch das Flashen eines Image probiert habe oder gleich den Chip Erase... Ich habe den Controller aufgegeben. Ein bisschen mache ich mir Sorgen, dass der neue Controller in der Schaltung und in seinem Einsatzgebiet wieder den selbe Schaden abbekommt... Ob da also z.B. eine Schutzdiode am Reset PIN zu empfehlen wäre...
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.