ATmega8 MISO reagiert nicht beim ISP => Anfänger- und Standardfehler sind "abgeklopft"!

[Bernd O. (bitshifter)]

Hallo zusammen,

ich scheitere gerade dabei, per ISP einen ATmega8 (TQFP-Gehäuse) zu 
programmieren. MISO regt sich nicht und der Programmer (avrdude über 
RS232 (bit-banging)) meldet daraufhin "AVR device not responding".

Der Programmieradapter ist schon jahrelang im Einsatz und funktioniert 
problemlos an ATmega16, ATmega32 und diversen ATtinys. War damals in 
Elektor beim "MiniMegaBoard" dabei und hängt an einer echten (non-USB) 
RS232.

Hier noch etwas mehr Hintergrundinformationen:
Der Controller sitzt auf einer winzigen Brushless-Regler Platine und 
darauf läuft aktuell noch die Original-SW des Herstellers. Einige 
Sekunden nach Spannung ein "piepst" der angeschlossene Brushlessmotor 
als Zeichen, dass alles O.K. ist. Controller und SW laufen also (ich 
konnte ja auch noch keine ISP-Verbindung aufnehmen, so dass alles noch 
"original" ist).

Der Takt wird über einen winzigen Quarz erzeugt (vermutlich 10 oder 16 
MHz). Die Fuses sollten dazu passend programmiert sein, da die 
Original-SW ja läuft.

Reset-Pin, SCK und MOSI arbeiten korrekt, nur MISO reagiert nicht. Nach 
dem erfolglosen ISP-Versuch kommt einige Sekunden später (gleiche Zeit 
wie nach Poweron) das Piepsen des Motors, das mir anzeigt, dass die SW 
wieder läuft - und das zumindest der Reset beim ATmega angekommen ist 
(zumindest RSTDISBL also nicht programmiert ist). Wenn ich den Reset 
manuell auf Gnd ziehe, dann initialisiert sich der Controller danach 
ebenfalls wieder und der Motor piepst.

Fazit:
Reset kommt "durch", SCK und MOSI funktionieren (Pegel ändert sich), nur 
MISO bleibt tot.

=> Kann der Hersteller die Fuses so "fies" programmiert haben, dass der 
Reset durchkommt, aber kein ISP mehr möglich ist? Selbst das Lesen der 
Signaturbytes - was so weit ich weiß immer gehen sollte klappt nicht. So 
komme ich nicht zum geplanten "erase device" um meine eigene SW 
einspielen zu können.

Die Verkabelung des ISPs ist "solide", (MOSI auf MOSI, MISO auf MISO, 
SCK auf SCK, ...), die betreffenden Pins sind "durchgeklingelt", also 
keine Kurzschlüsse zu den Nachbarn und auch die internen Schutzdioden 
der Pins kann ich im stromlosen Zustand ausmessen, also auch kein 
Kurzschluß auf Vcc oder Gnd. Eigentlich alles O.K. - nur leider 
funktioniert's nicht und ich komme nicht weiter.

Hat jemand eine kluge Idee?

Gruß,
Bernd

[holger (Gast)]

Man kann das programmieren über ISP per Fuse abschalten.

[Bernd O. (bitshifter)]

holger schrieb:
> Man kann das programmieren über ISP per Fuse abschalten.

Das könnte der Grund sein. Folgender Abschnitt im Datenblatt hat mich 
fehlgeleitet:

"All Atmel microcontrollers have a 3-byte signature code which 
identifies the device. This code can be read in both Serial and Parallel 
mode, also when the device is locked."

Das heißt strenggenommen aber ja nur, dass man über die Lock Bits das 
Auslesen der Signatur-Bytes nicht verhindern kann. Wenn man aber bei den 
Fuse-Bytes "SPIEN" deaktiviert hat, dann ist es wohl egal, wie die 
Lock-Bytes stehen, da SPI (ISP) ja schon totgelegt wurde.

Schade - ich dachte immer, dass ISP immer dann geht wenn RSTDISBL nicht 
aktiviert ist und CKSEL nicht ganz im "Wald steht". Aber die beiden sind 
wohl nur eine der Möglichkeiten für nichtfunktionierendes ISP.

Blöd, dass der Hersteller die Türe so gründlich verbarrikadiert hat, 
denn ich will ja gar nicht an seine SW 'ran (schließlich gibt es 
wesentlich bessere freie Software). Um die SW zu schützen hätte es doch 
ausgereicht, die LockBits zu programmieren. Vermutlich hat der 
Entwickler, der das gemacht hat gedacht "Sicher ist sicher".

Letztlich ist es nun sogar so sicher, dass mir der Aufwand für das 
Auslöten und Einlöten eines neuen ATmega zu groß ist und ich lieber das 
technisch etwas schlechtere Konkurrenzprodukt kaufe, bei dem ich meine 
eigene SW dann per ISP aufspielen kann.


Gruß,

Bernd