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

[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.

[RP6fahrer]

Ok, danke erstmal für deine Bemühungen.
Also, das Programm raufspielen hat fehlerfrei geklappt. Da ich aber nicht weiß, was der eigentliche Fehler ist, hab ich mir gestern einen neuen µC bestellt. vielleicht ist er einfach kaputt. Naja...

Zum Programmer, der hat nur 6 Pins.... VDD (5V/3,3V) GND, MISO,MOSI,SCK,Reset...

Ich fand es halt nur schade, dass der Controller mit einmal nicht mehr funktionierte.
Nochmals danke, für deine Hilfe.
MfG
RP6fahrer