Auch nicht bei der Option -B (groß B)?Zitat von xrtm4e
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?
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
Geändert von xrtm4e (10.03.2012 um 12:31 Uhr)
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
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.
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...
Woher weiß ich, ob mein Programmer das kann? ich habe den DIAMEX USB-ISP Programmer : http://www.reichelt.de/Programmer-En...DIAMEX+USB+ISPMan 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.
Er hat das STK500v2 Protokoll.
Danke für eure/deine Antwort
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.
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
Berechtigungen
Zitieren
Lesezeichen