Zugriffsverweigerung nach ISP Konflikt

[Stefan B. (-stefan-)]

Hallo,

Ich habe folgendes Problem. Habe einen Atmega8 welcher über ISP mit 
einem weiteren Bauteil kommuniziert. Soweit alles kein Problem. Das 
Programm steht. Doch dann wollte ich etwas an der Displayausgabe ändern. 
Also Programm neu auf den Atmega. Nur, hatte ich wie bei 4 anderen 
Atmegas bereits auch vergessen die ISP Anwendung zu trennen. Heißt im 
Klartext, dass ISP Anwendung und Programmer haben geleichzeitig Signale 
angelegt. Resultat nun, die Atmegas laufen noch einwandfrei. Nur flashen 
lassen sie sich NICHT mehr. Ich kann somit nur noch die alte Anwendung 
laufen lassen. Ist einem bekannt wie man wieder Zugriff auf den uC 
erhält?
Fehlermeldung: Unerwartete Signatur. Genau die Meldung wenn man den 
Flasher nicht mit dem uC verbindet.

Gruß

[(prx) A. K. (prx)]

Alternativen:
- ISP-Programmer verreckt.
- ISP-Pin vom Controller verreckt.
- Angeschlossener Perpherie-Pin verreckt.
- Fuses deprogrammiert.
- Stromversorgung weg.

Zukünftig: Atmels ISP-Programmer sowie die halbwegs brauchbaren 
Alternativen aktivieren ihre Ausgänge nur während der Programmierung, 
d.h. während Reset aktiv ist. Man kann ISP auf Controllerboards daher 
meistens auch so anschliessen, dass ein Konflikt auch bei permanent 
eingestecktem ISP nicht auftreten kann. Entweder indem man die Pins so 
nutzt, dass kein aktiver ISP-Ausgang auf einen aktiven 
Peripherie-Ausgang trifft, oder indem man die Peripherie mit 
Serienwiderständen versieht (extreme Naturen verwenden Muxer, das ist 
aber i.d.R. überflüssig).

[Stefan B. (-stefan-)]

Problem gelöst. Habe alle ISP-Leitungen vom Atmega getrennt. Das externe 
Bauteil hat obwohl nicht mit Spannung versorgt immer noch Einfluss auf 
den Programmer gehabt.

Ps. Danke für die Tipps

[(prx) A. K. (prx)]

Wenn dieses externe Bauteil wie üblich Schutzdioden hat, dann versuchen 
Programmer/Controller das Bauteil über diese Dioden mit Strom zu 
versorgen, sobald eine der Leitungen als Ausgang "1" führt.