avrdude: Yikes! Invalid device signature.

[Matthias H. (turing)]

Hallo zusammen,

ich gerade mit Mikrocontrollerprogrammierung begonnen.

Ich habe mir den USBprog 4.0 aus dem Shop gekauft und wollte zum testen 
einen ATMega8 programmieren.

Dazu habe ich auf einer Lochrasterplatine einen 6-poligen Wannenstecker 
und einen ATMega8 angebracht (siehe Fotos).
Dabei habe ich die Pins entsprechend des ATMega8 Datenblattes und dieser 
Beschreibung 
http://www.mikrocontroller.net/articles/AVR_In_System_Programmer#Pinbelegung 
verbunden

MISO: Wannenstecker Pin1, ATMega8 Pin18
VCC: Wannenstecker Pin2, ATMega8 Pin7
SCK: Wannenstecker Pin3, ATMega8 Pin18
MOSI: Wannenstecker Pin4, ATMega8 Pin17
RESET: Wannenstecker Pin5, ATMega8 Pin1
GND: Wannenstecker Pin6, ATMega8 Pin22 (GND gibt es auch noch bei Pin8, 
ich dachte es ist egal welchen ich nehme)


Außerdem habe ich Eclipse installiert
http://www.mikrocontroller.net/articles/AVR_Eclipse
 und damit das Einführungsbeispiel des AVR-GCC-Tutorials kompiliert.
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Einf.C3.BChrungsbeispiel

Bis zu diesem Punkt funktionierte alles Perfekt.


Nun wollte ich die von Eclipse (bzw. dem gcc) erzeugte .hex Datei mit 
avrdude auf den ATMega8 bringen.

Doch der Befehl

avrdude -c avrispmkII -p m8 -P usb -U bChaos.hex -n

liefert das folgende Resultat

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

Verwende ich statt dessen den Befehl:

avrdude -c avrispmkII -p m8 -P usb -U bChaos.hex -n -B 100

bekomme ich die Fehlermeldung

avrdude: stk500v2_command(): command failed
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

Ich habe die Verbindungen auf meiner Lochrasterplatine mit einem 
durchgangsprüfer untersucht: Alle Verbindungen leiten, zwischen allen 
anderen Punkten gibt es keinen Kurzschluß.

Nun weiß ich nicht mehr weiter.
Was kann ich tun?
Was will mir diese Fehlermeldung sagen? Welche Signatur ist ungültig? 
Die meines USBprogs, die des ATMega8 oder die der .hex Datei?

[Verwirrter Anfänger (Gast)]

Deinem Mega8 fehlt noch eine ganze Reihe an zusätzlichen Verbindungen.

Grundsätzlich gibt es keinen Unterschied zwischen der Beschaltung zum 
Programmieren und der Beschaltung zum "normalen" Programmablauf.

Es müssen alle GND und VCC Verbindungen angeschlossen sein (die 
verschiedenen Anschlüsse versorgen verschiedene Teile des Chips) und 
jedes VCC+GND Paar sollte über einen Kondensator versorgt werden.

Eine sinnvolle Beschaltung findest du hier:
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment#Selbstbau

Wenn dein µC frisch vom Händler ist, brauchst du den Quarzoszillator 
erstmal nicht, standardmäßig ist der interne Oszillator aktiviert.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Matthias Heizmann schrieb:
> Welche Signatur ist ungültig?
> Die meines USBprogs, die des ATMega8 oder die der .hex Datei?

Die des Mega8. avrdude kann nicht mit ihm kommunizieren.

Matthias Heizmann schrieb:
> Ich habe mir den USBprog 4.0 aus dem Shop gekauft

Ich will ja nicht rummeckern, aber warum kaufen sich Anfänger nicht 
einfach den AVRISP MkII? Der wird auch von moderneren Atmel Produkten 
direkt unterstützt und kostet nur ein paar Euro mehr. Und er 
programmiert alle AVRs inkl. XMega und die meisten MCS51 Derivate. Die 
Zeit, die man in einen Billigprogrammierer steckt, gleicht den Mehrpreis 
des ISP MkII meistens mehr als aus.

[Bert 0. (maschinist)]

Matthias Sch. schrieb:

> Ich will ja nicht rummeckern, aber warum kaufen sich Anfänger nicht
> einfach den AVRISP MkII? Der wird auch von moderneren Atmel Produkten
> direkt unterstützt und kostet nur ein paar Euro mehr.

Dann mecker halt nicht rum.

Auch der von Dir favorisierte AVRISP MkII hätte den TO nicht 
weitergebracht, er hat es schlicht versäumt, dem Mega8 die notwendigen 
Versorgungsspannungen, Puffer-Cs und Resetbeschaltung zu spendieren.

Am Programmiergerät liegt es eher nicht.


Gruß Maschinist

[Matthias H. (turing)]

Vielen Dank für die Antworten.

Ich weiß nicht mehr wie ich zu dieser Annahme kam, aber ich dachte dass 
ich mit dem USBprog diese zusätzliche Beschaltung nicht brauche.

Sehe ich das richtig, dass ich keinen externen Takt benötige und der 
interne zum programmieren genau genug ist?

[Martin (Gast)]

Verwirrter Anfänger schrieb:
> Deinem Mega8 fehlt noch eine ganze Reihe an zusätzlichen Verbindungen.

Gerade in andere Therad gefunden:

http://evolutec.publicmsg.de/index.php?menu=software&content=avrminimalbeschaltung

Vielleicht sind da paar Fragen beantwortet.

[Matthias H. (turing)]

Heute Abend konnte ich weiterbasteln - erste Erkenntnisse:

1. VCC (und GND?) waren nicht angeschlossen, im Auslieferungszustand 
erwartet der USBprog 4.0 eine externe Stromversorgung. Nach dem einlöten 
einer Brücke liefert der USBprog 4.0 die Spannung selbst.

2. Pin8 (GND) und Pin22 (GND) des Atmega8 sind intern schon verbunden. 
Pin7 (VCC) und Pin 20 (AVCC) des Atmega8  sind intern nicht verbunden.

3. Diese Minimalbeschaltung funktioniert für mich nicht
http://evolutec.publicmsg.de/index.php?menu=software&content=avrminimalbeschaltung
Ich habe wie zuvor (MISO, VCC, SCK, MOSI, RESET, GND) verbunden und 
zusätzlich den 10kOhm Widerstand zwischen Pin1 (RESET) und VCC 
eingelötet. Als Resultat (avrdude -c avrispmkII -p m8 -P usb -U 
bChaos.hex)
erhalte ich das folgende.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.10s

avrdude: Device signature = 0x1e9307
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "bChaos.hex"
avrdude: input file bChaos.hex auto detected as Intel Hex
avrdude: writing flash (108 bytes):
:2000000012C02CC02BC02AC029C028C027C026C025C024C023C022C021C020C01FC01EC0A3
:200020001DC01CC01BC011241FBECFE5D4E0DEBFCDBF10E0A0E6B0E0ECE6F0E002C005908A
:200040000D92A036B107D9F710E0A0E6B0E001C01D92A036B107E1F702D006C0D1CF8FEF11
:0C00600087BB83E088BBFFCFF894FFCF84
:00000001FF
avrdude: 108 bytes of flash written
avrdude: verifying flash memory against bChaos.hex:
avrdude: load data flash data from input file bChaos.hex:
avrdude: input file bChaos.hex auto detected as Intel Hex
avrdude: input file bChaos.hex contains 108 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.46s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x12 != 0xff
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Als nächste werde ich die Puffer-Kondensatoren hinzufügen und die hier 
erwähnten 
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment#Selbstbau
(nicht-Taktgeber) Pins beschalten.

[Verwirrter Anfänger (Gast)]

Matthias Heizmann schrieb:
> 2. Pin8 (GND) und Pin22 (GND) des Atmega8 sind intern schon verbunden.

Nur als Warnung: Für das Programmieren mag es reichen einen der beiden 
anzuschließen. Im richtigen Betrieb würde ich mich aber nicht darauf 
verlassen. Wer weiss, wie die intern verbunden sind. Vielleicht macht 
das bei Strömen über 5mA einfach mal "Puff" und dann sind sie nicht mehr 
verbunden.

[Matthias H. (turing)]

Vielen Dank für eure Vorschläge.

Es dauerte ein paar Woche bis ich wieder Zeit zum Weiterbauen fand. 
Mittlerweile habe ich aber erfolgreich einen attiny85 und einen atmega8 
programmiert :-)

Dieser verification error hat mich auch nach dem auflöten der 
Kondensatoren zur Pufferung einige Zeit beschäftigt.
Die Lösung war allerdings einfach: Ich hatte avrdude zunächst mit der 
Option -n (Do not write anything to the device.) aufgerufen. Danach gab 
es natürlich immer einen verification error. Da nichts (neues) in den 
Mikrocontoller programmiert wurde, könnte sein Inhalt anschließend auch 
nicht der neuen .hex Datei entsprechen....