ATMega1284p: falsche Device ID im AVR Dragon?

[Christian Thorge S. (christianthorge_s)]

Hallo Forum,

mein AVR Dragon zeigt mir für 2 alte (die ich mal mit einem USBasp 
"verfused hatte) sowie für einen grade frisch von ELV gekauften 
ATMega1284p folgende Device ID an:

avrdude: Device signature = 0x1e3705
avrdude: Expected signature for ATMEGA1284P is 1E 97 05

Die Bedrahtung des HVPP Interfaces habe ich jetzt mehrfach nach
http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/SCKT3100A3.htm 
überprüft.

Ein Auslesen eines ebenfalls vorhandenen ATTiny85, 2313 sowie eines 328p 
(jeweils mit deren richtiger HVPP Beschaltung) funktioniert.
Testweises setzen von Fuses schlägt ebenfalls schief:

$ avrdude -c dragon_pp -p m1284p -P usb -F -U lfuse:w:0x62:m -U hfuse:w:0x99:m -U efuse:w:0xff:m -B 100

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e3705
avrdude: Expected signature for ATMEGA1284P is 1E 97 05
avrdude: reading input file "0x62"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x62:
avrdude: load data lfuse data from input file 0x62:
avrdude: input file 0x62 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.05s

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

avrdude: safemode: lfuse changed! Was 62, and is now ff
Would you like this fuse to be changed back? [y/n] y
avrdude: and COULD NOT be changed
avrdude: safemode: Fuses not recovered, sorry
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

avrdude done.  Thank you.

Was kann da bloss grade schieflaufen?

Danke,
 Christian (langsam am verzweifeln).

[Thomas E. (thomase)]

Christian Thorge S. schrieb:
> Was kann da bloss grade schieflaufen?

Sowas ähnliches hatte ich auch schon. Wenn du einen Nullkraftsockel 
hast, klemm mal jeweils 100nF zwischen Vcc bzw. Avcc und GND mit ein. 
Hat bei mir geholfen.

mfg.

[Sascha W. (sascha-w)]

Hallo,

wenn der per HV, also auch parallel angeschlossen ist, dann geht Bit 7 
nicht

Sascha

[Christian Thorge S. (christianthorge_s)]

Welcher "Buchstabe" der Anschlusstabelle nach wäre das? Der Defekt muss 
dann ja irgendwie auf dem Dragon selbst sein?!
Gibt es eine Methode, das noch weitergehend zu testen (Kabel, PCB-Trace, 
Lötstelle, ...)?

[Christian Thorge S. (christianthorge_s)]

Das müsste der Anleitung nach doch HV Pin 8 sein - durchgeklingelt, 
nachgelötet, nochmals durchgeklingelt.
Selbes Ergebnis... ->

avrdude: Device signature = 0x1e3705

[Christian Thorge S. (christianthorge_s)]

> Wenn du einen Nullkraftsockel hast,
Ja, aber ich hab's auch mal ohne probiert. Keine Änderung.

> klemm mal jeweils 100nF zwischen Vcc bzw. Avcc und GND mit ein.
Werde ich gleich Anfang der Woche mal ausprobieren. Mist, dass die Läden 
am Sonntag zu haben wenn man mal was Dringendes braucht ;)

Danke für den Tip!

[Thomas E. (thomase)]

Christian Thorge S. schrieb:
> Das müsste der Anleitung nach doch HV Pin 8 sein - durchgeklingelt,
> nachgelötet, nochmals durchgeklingelt.
> Selbes Ergebnis... ->
War auch nicht anders zu erwarten.

Sascha Weber schrieb:
> wenn der per HV, also auch parallel angeschlossen ist, dann geht Bit 7
> nicht
Keine Ahnung, was man da, ausser gar nichts, drunter verstehen soll.

Christian Thorge S. schrieb:
>> klemm mal jeweils 100nF zwischen Vcc bzw. Avcc und GND mit ein.
> Werde ich gleich Anfang der Woche mal ausprobieren. Mist, dass die Läden
> am Sonntag zu haben wenn man mal was Dringendes braucht ;)
Von den Dingern sollte man aber immer mindestens, wenn nicht noch mehr 
in der Schublade haben.

mfg.

[Christian Thorge S. (christianthorge_s)]

Thomas Eckmann schrieb:
> War auch nicht anders zu erwarten.
Es hätte doch durchaus ein Kontakt-/Löt-/Kabelesoterikfehler des Pins 8 
sein können...

>> wenn der per HV, also auch parallel angeschlossen ist, dann geht Bit 7
>> nicht
> Keine Ahnung, was man da, ausser gar nichts, drunter verstehen soll.
Ich habe das so aufgefasst, dass Pin 8 (Bit 7 laut Anleitung (die ich 
natürlich erst jetzt "gefunden" habe ;)) kaputt/falsch/nicht beschaltet 
gewesen hätte sein können. Ich fand es (aus der besserwissenden 
Perspektive dessen dem man grade etwas erklärt hat) ganz logisch. War 
halt anscheinend nur nicht oder der Fehler liegt auf dem PCB des Dragon 
selbst.

>>> (...) 100nF (...)
>> (...)
> Von den Dingern sollte man aber immer mindestens, wenn nicht noch mehr
> in der Schublade haben.
Werde ich in Zukunft meiner Kleinteilesammlung in ausreichender Zahl 
hinzufügen.
Was genau wird der Kondensator eigentlich bewirken bzw. was läuft in der 
Schaltung mit Nullkraftsockel "falsch" dass ich die Dinger brauche?

[Wolfgang (Gast)]

Christian Thorge S. schrieb:
> avrdude: Device signature = 0x1e3705
> avrdude: Expected signature for ATMEGA1284P is 1E 97 05

Sascha Weber schrieb:
> wenn der per HV, also auch parallel angeschlossen ist, dann geht Bit 7
> nicht

Das würde aber nicht erklären, wieso aus einer 0x9 (0b1001) eine 0x3 
(0b0011) wird. Außer Bit 7 spielt da auch Bit 5 noch mit.

[Thomas E. (thomase)]

Christian Thorge S. schrieb:
> Es hätte doch durchaus ein Kontakt-/Löt-/Kabelesoterikfehler des Pins 8
> sein können...
Nö. Wenn Bit7 fehlte, also 0 wäre, würde aus 97 17 und nicht 37 werden.

Christian Thorge S. schrieb:
> Was genau wird der Kondensator eigentlich bewirken bzw. was läuft in der
> Schaltung mit Nullkraftsockel "falsch" dass ich die Dinger brauche?
Das hast du jetzt falsch verstanden. Da läuft nichts falsch. Man kann 
den Kondensator im Nullkraftsockel nur einfach mit einklemmen. Ansonsten 
müsste man ihn einlöten, was aber bei anderen Controllern mit anderer 
Pinbelegung zu Störungen führen würde. Dann müsste man ihn wieder 
auslöten.

mfg.

http://www.atmel.com/images/doc2521.pdf

[Christian Thorge S. (christianthorge_s)]

> Nö. Wenn Bit7 fehlte, also 0 wäre, würde aus 97 17 und nicht 37 werden.
Ahh. Mein Binär ist äußerst rudimentär, ganz im Gegensatz zu Fasel - das 
spreche ich fließend ;)

> http://www.atmel.com/images/doc2521.pdf
Danke!

[Christian Thorge S. (christianthorge_s)]

Es wird ja immer seltsamer.

Ich habe jetzt drei m1284p's - einer davon garantiert neu, s.o.

Wenn ich jetzt meinen USBasp clone anschließe und die Fuses versuche 
auszulesen geht es mit dem Neuen:

# avrdude -c usbasp -p m1284p -n -v -F

avrdude: Version 5.11.1, compiled on Mar 26 2013 at 19:58:26
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/opt/local/etc/avrdude.conf"
         User configuration file is "/Users/cts/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : unknown
         Using Programmer              : usbasp
         AVR Part                      : ATMEGA1284P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    10   128    0 no       4096    8      0  9000  9000 0xff 0xff
           flash         65    10   256    0 yes    131072  256    512  4500  4500 0xff 0xff
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9705
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FF

avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Mit den zwei "alten", von denen ich davon ausgehe das sie "verfused" 
sind, geht es weiterhin nicht:

# avrdude -c usbasp -p m1284p -n -v -F

(...s.o....)
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA1284P is 1E 97 05

avrdude done.  Thank you.

Liege ich also richtig in der Annahme, dass ich mich aller 
Wahrscheinlichkeit nach tatsächlich "ausgesperrt" habe und ich mich 
wahrscheinlich tatsächlich nur mit HVPP herausretten kann?

Ausserdem ist interessant, dass der Dragon auch den "heilen" m1284p mit 
der falschen Device ID ausliest:
Da ich jetzt nochmals alles nachgelötet habe und alle Kabel ausgetauscht 
habe (mit besonderer Beachtung der Bits 5 und 7 ;) ist doch wohl dem 
Dragon vorzeitig das Feuer ausgegangen, oder?

Ich muss bald weinen.

 Christian.

[MWS (Gast)]

Wenn das eine nicht geht, würd' ich das andere nehmen. Also ein 
AVR-Studio 4 laden und mit dessen Programmierdialog schauen, was da so 
passiert...

[Thomas E. (thomase)]

Christian Thorge S. schrieb:
> Ich muss bald weinen.
Verschieb das Geheule auf den Moment, nachdem du das mit den 
Stützkondensatoren am Dragon getestet hast.

mfg.

[Markus W. (Firma: guloshop.de) (m-w)]

Christian Thorge S. schrieb:
> Liege ich also richtig in der Annahme, dass ich mich aller
> Wahrscheinlichkeit nach tatsächlich "ausgesperrt" habe und ich mich
> wahrscheinlich tatsächlich nur mit HVPP herausretten kann?

Das glaube ich eher nicht...

> avrdude: warning: cannot set sck period. please check for usbasp
> firmware update.

Ich denke, diesen Rat solltest du befolgen. Mit der (inzwischen relativ) 
alten Firmware kann der USBasp nicht mit sehr niedrigen 
Geschwindigkeiten arbeiten. Da hilft auch der immer wieder genannte 
"Jumper 2" nichts, weil der Takt damit nur bis zu einem bestimmten Wert 
runtergesetzt werden kann.

> avrdude: error: programm enable: target doesn't answer. 1
> avrdude: initialization failed, rc=-1

Genau das passiert, wenn der Takt des Programmers zu schnell ist. 
Natürlich kommt dieser Fehler auch, wenn eine der Leitungen falsch oder 
gar nicht angeschlossen ist. Meistens liegts aber doch am Takt.

> avrdude: Device signature = 0x000000
> avrdude: Yikes!  Invalid device signature.
> avrdude: Expected signature for ATMEGA1284P is 1E 97 05

Das ist dann der übliche Folgefehler.

P.S.: Den Rat mit den Kondensatoren solltest du auch ernst nehmen, denk 
ich...

[Christian Thorge S. (christianthorge_s)]

Um es aufzulösen: Der Dragon war kaputt. Nach einem Telefonat mit einem 
(sehr netten) ELV-Techniker innerhalb von zwei Tagen (inkl. 
Postlaufzeit!) Austausch gegen ein nun funktionierendes Modell. Heute 
dann noch die E-Mail Bestätigung dass der Dragon wirklich kaputt war, 
das ist jetzt auch "vom Herstellerservice bestätigt worden" (wie auch 
immer das so schnell geklappt hat ;).

Danke an das Forum für die Tipps und die Ermunterung weiterzumachen!

 Christian.