atmega2560 Probleme

[Jonas (Gast)]

Hallo zusammen,
Ich habe vor kurzem einen ATmega2560 16au in ein Projekt eingebaut. Es 
hat auch alles super funktioniert.  Während dem austesten der Schaltung 
und nach einigem programmieren über ISP war avrdude plötzlich nicht mehr 
in der Lage mit dem atmega zu kommunizieren, was sich mit dem bekannten 
0x000000 identifikationsfehler widerspiegelt.  Es wurde nichts externes 
angeschlossen was ein plötzlicher Fehler rechtfertigen könnte.

Als erstes habe ich alle Verbindungen getestet, danach habe ich den 
Programmer (usbasp) an einem anderen uC ausprobiert. Als dies nichts 
ergab habe ich den 16MHz crystal ausgewechselt. Trotzdem konnte keine 
Verbindung mehr hergestellt werden.

Wüsste jemand vielleicht aus eigener Erfahrung was schief gegangen sein 
könnte? Mein nächster Schritt wäre ansonsten den atmega auszutauschen. 
Und hier kommt meine zweite Frage: hat jemand so einen herumliegenden? 
Am besten in der Schweiz? Bei einer Bestellung in den elektronik 
Geschäfte ist mir der Versand ein wenig zu teuer.

Vielen dank und gruss
Jonas

[matrixstorm (Gast)]

und...

...verfust ;-)

Ernsthaft, belese dich mal ueber das Thema "Fusebits" bzw. "verfusen".

Mit grosser Wahrscheinlichkeit hast du deinen AVR auf eine falsche 
Taktquelle konfiguriert, oder "serial programming" deaktiviert.

...HVPP schafft abhilfe, ist bei SMD aber unlustig...

MfG

[Stefan (Gast)]

schließ mal eine externe Taktquelle an (referenzsignal vom Oszi oder ne 
0815 Scahltung mit einem Attiny). Wenn das nix bringt, hilft nur noch 
HVP wie Matrix schon erwähnte

[Jonas P. (jonas_p31)]

Danke für eure Antworten.  was ich nicht verstehe ist, dass alles 
funktionierte. Fusebits waren gesetzt, ich hatte schon mehrere 
Testprogramme erfolgreich am laufen, und plötzlich lief nichts mehr...

[Jonas P. (jonas_p31)]

Ich habe es jetzt auch mit einem externen Takt (aus einem Arduino) 
versucht, leider ohne Erfolg!
Somit bleibt mir wohl nur noch den uC auszutauschen...

[Jonas P. (jonas_p31)]

Tut mir Leid für die Selbstgespräche die ich hier führe :).
Ich habe das Problem jedoch gelöst, indem ich den externen Takt an 
XTAL2, und nicht an XTAL1, angeschlossen habe. Warum es die fusebits 
verändert hat ist und bleibt wohl ein Rätsel.

Danke und gruss

Jonas

[Stefan (Gast)]

Jonas P. schrieb:
> Warum es die fusebits
> verändert hat ist und bleibt wohl ein Rätsel.

Das liegt zu 99% am Programmer. Viele Leute glauben, am Programmer Geld 
sparen zu können (ich früher auch). Man büßt aber dabei nur eine Menge 
Zeit und Nerven ein. Seitem ich meinen MKII habe, gab es keine Probleme 
mit Fuses und dgl. mehr

[Stephan B. (matrixstorm)]

Stefan schrieb:
> Das liegt zu 99% am Programmer

Naja, das ist quatsch. Auch wenn ich mich jetzt nicht deswegen streiten 
will.
(Es gibt genuegent Topics hier im Forum, die bestaetigen, das es gute 
und guenstige Alternativem zum MKII gibt.)

Vermutlich liegt es an der Verkabelung. Ein Kabelknick oder aehnliches.
Dies hat dann waehrend der Uebertragung zu einem unguensitgen 
Uebertragungsfehler gefuehrt. Am Programmer selbst liegt es meiner 
Meinung nach nicht.

MfG

[Jonas P. (jonas_p31)]

Vielleicht weiss ich jetzt wo das Problem liegt/lag!
In meiner Schaltung ist das SCK Signal über ein Op-Amp an ein LED 
angeschlossen (Ähnlich wie bei Arduino). Nur wird dieser nicht von den 
5V, sondern von einer Batterie gespeist, weil er auch gleichzeitig als 
Differenzverstärker für eine Spannungsmessung gebraucht wird. Während 
dem Programmieren habe ich die Batterie nie angeschlossen, weshalb der 
Op-Amp selber und die LED über die Schutzdioden des Op-Amps gespeist 
wurden, also direkt vom SCK Signal!

Ohne Schema ist dies wohl nicht sehr einfach zu verstehen, aber einfach 
gesagt: könnte es sein, dass das Problem daher kommt, dass zuviel Strom 
vom SCK Signal gezogen wurde, und deshalb manchmal irgendetwas 
zufälliges Einprogrammiert wurde?
Ich habe es jetzt mit angeschlossener Batterie versucht und hatte bisher 
keine Probleme, was aber nicht heisst, dass es nie mehr welche geben 
wird...

Gruss

Jonas