atmega32 / atmega8 Grundschaltung - Probleme mit avrdude (Invalid device signature)

[xrtm4e]

Wenn ich die Baudrate kleiner mache geht gar nichts, dann antwortet der Programmer nicht. Wenn ich versuche ein Programm draufzuladen und die -F Option dazumache kommt folgendes:


Found programmer: Id = "AVR ISP"; type = S
Software Version = 1.1; Hardware Version = 1.4
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize = 64 bytes.

Programmer supports the following devices:
Device code: 0x13 = AT90S1200
Device code: 0x20 = ATtiny84
Device code: 0x28 = AT90S4414
Device code: 0x30 = AT90S4433
Device code: 0x34 = AT90S2333
Device code: 0x38 = AT90S8515
Device code: 0x48 = (unknown)
Device code: 0x4c = AT90S2343
Device code: 0x68 = AT90S8535
Device code: 0x6c = AT90S4434
Device code: 0x01 = (unknown)
Device code: 0x04 = (unknown)
Device code: 0x05 = (unknown)
Device code: 0x06 = (unknown)
Device code: 0x07 = (unknown)
Device code: 0x08 = (unknown)
Device code: 0x09 = (unknown)
Device code: 0x0e = (unknown)
Device code: 0x1a = (unknown)
Device code: 0x0f = (unknown)
Device code: 0x1b = (unknown)
Device code: 0x14 = (unknown)
Device code: 0x1c = (unknown)
Device code: 0x1d = (unknown)
Device code: 0x23 = (unknown)
Device code: 0x31 = (unknown)
Device code: 0x33 = (unknown)
Device code: 0x35 = (unknown)
Device code: 0x37 = (unknown)
Device code: 0x39 = (unknown)
Device code: 0x3d = (unknown)
Device code: 0x3e = (unknown)
Device code: 0x57 = (unknown)
Device code: 0x3a = ATMEGA8515
Device code: 0x3b = (unknown)
Device code: 0x41 = ATMEGA103
Device code: 0x43 = ATMEGA128
Device code: 0x44 = (unknown)
Device code: 0x45 = ATMEGA64
Device code: 0x46 = (unknown)
Device code: 0x5e = ATtiny2313
Device code: 0x60 = ATMEGA161
Device code: 0x61 = (unknown)
Device code: 0x62 = (unknown)
Device code: 0x63 = ATMEGA162
Device code: 0x64 = ATMEGA163
Device code: 0x66 = (unknown)
Device code: 0x69 = ATMEGA8535
Device code: 0x6a = (unknown)
Device code: 0x72 = ATMEGA32
Device code: 0x73 = (unknown)
Device code: 0x74 = ATMEGA6450
Device code: 0x75 = ATMEGA6490
Device code: 0x76 = ATMEGA8
Device code: 0x77 = (unknown)
Device code: 0x78 = ATMEGA169
Device code: 0x79 = (unknown)

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0xffffff
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATMEGA32 is 1E 95 02
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 "neu.hex"
avrdude: input file neu.hex auto detected as Intel Hex
avrdude: writing flash (180 bytes):

Writing | ################################################## | 100% 2.56s



avrdude: 180 bytes of flash written
avrdude: verifying flash memory against neu.hex:
avrdude: load data flash data from input file neu.hex:
avrdude: input file neu.hex auto detected as Intel Hex
avrdude: input file neu.hex contains 180 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.08s



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

avrdude: safemode: Fuses OK

avrdude done. Thank you.

Also der Ladebalken läd kurze Zeit (wie bei einer funktionierenden Schaltung) aber das Programm scheint nicht zu funktionieren (LED blinken).

[trekko]

Wenn ich die Baudrate kleiner mache geht gar nichts, dann antwortet der Programmer nicht.

Auch nicht bei der Option -B (groß B)?

Dann liegt es vermutlich wirklich an den Leitungen. Korrekt angeschlossen? Jede Leitung sicher verbunden (durchgemessen)? Kalte Lötstelle? Kurzschluss irgendwo?

Board ok?

Anderen Programmer probiert?

[xrtm4e]

Nein, mit -B funktioniert es leider auch nicht. Am Programmer sollte es eigentlich nicht liegen, da ich mit diesem auch mein fertiges Controllerboard programmiere (auch mit einem mega32) und da funktioniert es einwandfrei. Habe hier zwar noch einen Parallelport-Programmer (stk200) liegen, den bekomme ich aber momentan irgendwie nicht zum laufen. Ich nutze ein USB zu rs-232 + parallelport kabel, da will das stk200 aber irgendwie nicht. Wenn ich


avrdude -c stk200 -p m32 -P /dev/usb/lp0

mache dann erscheinnt das (schreibrechte sind gesetzt):

avrdude: can't claim device "/dev/usb/lp0": Inappropriate ioctl for device

[RP6fahrer]

Hi,

ich bin jetzt auch bei diesem Problem angelangt. Ich versuche grade, wie im thread https://www.roboternetz.de/community...?highlight=acs ein ACS selber zu entwickeln. Ich habe dazu testweise einen Atmega16 verwendet. da ich den Tip erhalten habe, es mal mit einem Atmega32 zu versuchen (da Code von der Roboter RP6 Lib), nahm ich meinen atMega32 vom meiner Modellbahnsteuerung. Er hat immer zuverlässig funktioniert, nur nachdem ich den Programmcode aufgespielt habe, lief er los und blinkt (genau wie programmiert). Allerdings hat meine Hinderniserkennung nicht funktioniert, aber egal, ich wollte dann wieder das Programm für die Modellbahnsteuerung aufspielen, aber er gibt mir nur noch aus:

E:\Roboter\WINAVR\bin\avrdude.exe -C E:\Roboter\WINAVR\bin\avrdude.conf -p m32 -P com2 -c stk500v2 -B100 -U hfuse:r:C:\Users\Daniel\AppData\Local\Temp\hfuse29 05653203157537424.hex:r -U lfuse:r:C:\Users\Daniel\AppData\Local\Temp\lfuse58 43379132835687097.hex:r

avrdude.exe: AVR device initialized and ready to accept instructions

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

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

Wie hat sich die Device signature geändert? Kann man den Controller irgendwie resetten? Quasi auf Werkszustand zurückversetzen?

Ich hoffe ihr könnt mir helfen. Es liegt definitiv keine Verdrahtungsfehler/USB-ISP-Programmer-Fehler vor, weil wenn ich den atmega 16 in den selben Sockel stecke, kann ich diesen programmieren.
Vielen Dank schonmal für eure Hilfe.

Mfg
RP6fahrer

[Besserwessi]

Wenn man bei der Device signature = 0xffffff oder Device signature = 0x000000 bekommt, ist das ein starker hinweis darauf, dass die Verbindung vom Programmer zum µC nicht funktioniert, oder µC nicht läuft, etwa weil der Takt fehlt.

Ob der µC läuft kann man sonst auch ganz gut am Stromverbrauch erkennen, zumindest bei genügend schnellem Takt. Der Mega32 braucht GND und VCC an je 2 Pins um zuverlässig zu laufen.

Solange die Divice ID nicht stimmt, funktioniert die ISP Schnittstelle nicht. Man könnte den µC theoretisch auch per pralleler Programmierung mit hoher Spannung am Reset Pin programmieren, wenn man z.B. ein original STk500 hat. Die meisten einfachen Programmer können dies aber nicht.

[RP6fahrer]

Hi,
Danke erstmal für die Info.
Ich habe mal versucht, was in dem Fenster stand:
...,or use -F to override this check.
Das Laden hat dann scheinbar funktioniert, aber sehr sehr lange gedauert. Kann es sein, dass ich nen Kurzschluss irgendwie zwischen den Pins verursacht habe und diese dann defekt sind und zu dem Fehler führen. Aber gleichzeitig kann ich mir das nicht vorstellen, weil sonst hätte ich das Programm ja nicht in den Controller laden können. Und wie gesagt, der Takt ist da, weil schließlich hat ja die LED normal geblinkt...

Man könnte den µC theoretisch auch per pralleler Programmierung mit hoher Spannung am Reset Pin programmieren, wenn man z.B. ein original STk500 hat. Die meisten einfachen Programmer können dies aber nicht.

Woher weiß ich, ob mein Programmer das kann? ich habe den DIAMEX USB-ISP Programmer : http://www.reichelt.de/Programmer-En...DIAMEX+USB+ISP
Er hat das STK500v2 Protokoll.
Danke für eure/deine Antwort

[Besserwessi]

Ohne den Diamex Programmer wirklich zu kennen, würde ich sagen, der kann das parallele Programmieren nicht. Das ist halt ein eher selten genutzter Mode den der original Atmel STK500 oder Atmel Dragon unterstützen. Dafür braucht man auch deutlich mehr Leitungen, so dass man das bei günstigen Nachbauten in aller Regel nicht findet - normal braucht man den Mode auch nicht, weil man das meiste auch per ISP machen kann. Das Protokoll vom STK500 wird relativ oft genutzt - was aber nicht heißt, dass auch alle der Funktionen unterstützt werden. Das Sorgt nur dafür das man auf der PC Seite die selbe Software nutzen kann und z.B. direkt aus AVRStudio die Datenübertragen kann.

Bei einer nicht richtig eingelesenen Chip ID mit -F zu arbeiten ist schon mutig. Das heißt ja dass man eine nicht zuverlässige (bzw. gar keine funktionierende) Datenverbindung vom µC zum Programmer hat. Wenn man Pech hat kann man so auch zufällig die Fuses verstellen - ist nicht wahrscheinlich aber möglich. Ähnlich unwahrscheinlich ist es auch das das programmieren dann geht. Eine mögliche Erklärung für diesen seltenen Fall wäre ggf. ein ungewöhnlich großer Kondensator am Reset Pin, so dass der µC länger braucht bis er auf das Programmieren reagiert. Die sehr langsame Programmierung würde eventuell noch für einen sehr langsamen Takt am µC spechen (z.B. 125 kHz vom Watchdog) - ggf. probiert der Programmer das nicht bei der Chip ID, obwohl es gerade da sinnvoll wäre.