Hallo, wie schon in einem anderen Thread angedeutet, ist es mir nicht gelungen, einen ATmega644P auf der ZIF-Fassung auf dem Dragon im HV-PP Modus zu programmieren. Das erste Signature Byte wurde fälschlicherweise konsistent als "0xFF", die beiden anderen Signature Bytes wurden korrekt gelesen. Meine Anfrage bei Atmel brachte nur die Antwort, ich sollte mal die Leitungslängen überprüfen. Daraufhin habe ich mir eine kleine (mit Drähten "verdrahtete" Lötpunktratser-Platine) für die SCKT3100A3 HV-PP Leitungsführung gebaut und siehe da: jetzt klappt es in 90% der Versuche, ab und zu wird immer noch "0xFF" als erstes Signature Byte gelesen. Scheinbar waren die Leitungen (siehe Bild) so zu lang. Seltsamerweise gab es beim ATmega32 mit identischer Verdrahtung keine Probleme. Viele Grüße Fred
Das ist allerdings in der Tat seltsam. Die Leitungslängen bei meinen Versuchen sind ähnlich wie deine, lediglich dass ich bunte Hosenträger- leitung für das HVProg-Kabel benutzt habe (das mit der Widerstands- farbcodierung). Welche Firmwareversion hast du denn benutzt?
Hallo Jörg, danke für Deinen Kommentar. Ich programmiere mit dem AVRStudio 4.14 unter XP SP2; der Dragon hat das neueste Update (leider sagt einem das AVR Studio nicht, welche Firmware Version; es führt einfach immer wieder ein Update durch, auch wenn schon die neueste Firmware im Dragon ist!). Noch eine Korrektur: Das Bild zeigt die HV-PP Verdrahtung für einen der 8-Pin AVRs; für die SCKT3100A3 Verdrahtung habe ich aber die gleichen Drähte (also Leitungslängen) verwendet. Viele Grüße Fred
bei dem Aufbau wirst du bestimmt auch mit Kontaktprobleme zu kämpfen haben.
Fred S. wrote: > danke für Deinen Kommentar. Ich programmiere mit dem AVRStudio 4.14 > unter XP SP2; der Dragon hat das neueste Update (leider sagt einem das > AVR Studio nicht, welche Firmware Version; es führt einfach immer wieder > ein Update durch, auch wenn schon die neueste Firmware im Dragon ist!). In irgendeinem der kleinen Nachrichten-Fenster ganz unten oder irgendwo da sollte das stehen. Aber ich mag AVR Studio nicht wirklich. Nicht nur, dass ich dafür ein Windows haben müsste, ich finde es auch alles in allem ziemlich unübersichtlich. Die Firmware meines Dragon dürfte leicht älter sein und irgendeiner Version von AVR Studio 4.13 entstammen. Allerdings mimmt AVRDUDE nicht die XML-Dateien direkt, sondern hat die HV-Parameter daraus irgendwann einmal übernommen. Möglicherweise könnte das Problem also auch durch einen geänderten HV-Parameter in der XML-Datei entstanden sein. Kannst du eventuell auch mal ein AVRDUDE testen?
@ Thomas O., > bei dem Aufbau wirst du bestimmt auch mit Kontaktprobleme zu kämpfen > haben. das ist schwer nachzuprüfen -- bisher hat sich bei mir 0.5mm verzinnter Kupferdraht in diesen Fassungen sehr gut bewährt (außer dass er nicht vergoldet ist, unterscheidet sich der Draht ja wenig von den "richtigen" zugehörigen Steckern). Für Deine These spricht, dass es mit einer Steckerleiste und kürzeren verlöteten Drähten eben funktioniert. Komisch allerdings, dass nur der ATmega644P die Probleme hatte; mit dem ATmega32 ging alles problemlos. @ Jörg W., > Kannst du eventuell auch mal ein AVRDUDE testen? Werde ich mal versuchen. Mit dem Studio kenne mich gut aus, bei AVRDUDE habe ich allerdings die gleichen Probleme wie Du mit Windoof und dem Studio... Viele Grüße Fred
teste mal mit einem anderem Resetpullup vielleicht ist der eine µC bezüglich der Standart 10 kOhm etwas grenzwertig oder der Programmer ist in der hinsicht etwas schwach. Oder verwendest du Werte unter 10 kOhm?
Thomas O. wrote:
> teste mal mit einem anderem Resetpullup
Thema verfehlt. :-o Lies dir den ersten Beitrag nochmal ganz in Ruhe
durch...
Fred S. wrote: >> Kannst du eventuell auch mal ein AVRDUDE testen? > Werde ich mal versuchen. Mit dem Studio kenne mich gut aus, bei AVRDUDE > habe ich allerdings die gleichen Probleme wie Du mit Windoof und dem > Studio...
1 | avrdude -p atmega644p -c dragon_pp -P usb |
sollte genügen um zu sehen, ob das überhaupt funktioniert. Allerdings musst du die passende libusb haben. Meiner Erinnerung nach ist die libusb, die bei WinAVR mitkommt dafür gedacht, standalone als eigener Treiber zu arbeiten. Wenn du oberhalb des Jungo-Treibers arbeiten willst, der bei AVR Studio dabei ist, dann solltest du die libusb0.dll von WinAVR wegwerfen und die "Filter"-Version installieren: http://sourceforge.net/projects/libusb-win32/
Hallo Jörg, danke für die Tipps! Mit der von Dir genannten libusb liest avrdude mit dem Dragon und meiner neuen (kurzen!) Verdrahtung die Signature Bytes des ATmega644P korrekt. Ich wede später mal den "Drahtverhau" rekonstruieren und es dann noch einmal mit avrdude versuchen. Viele Grüße Fred
Hallo Jörg, so: mit dem "Drahtverhau" (etwa 6cm Leitungslänge zwischen den Kontakten) liest avrdude+Dragon die Signature Bytes des ATmega644P korrekt, wohingegen AVRStudio 4.14 + Dragon weiterhin das erste Byte als "0xFF" liest (die anderen beiden Bytes stimmmen). Ist das ein Timing Problem? Wie unterscheiden sich die HV-PP Parameter des AVRStudio von denen, die avrdude verwendet? (Mit kürzeren Leitungen funktioniert es ja mit dem Studio in ca. 90% der Versuche!) Viele Grüße Fred
Nachtrag: avrdude (Beim ersten Versuch hatte das AVRStudio noch Kontrolle über den Dragon - daher keine Verbindung per avrdude möglich.)
Ist schon seltensam... Im avrdude.conf steht:
1 | pp_controlstack = |
2 | 0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F, |
3 | 0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F, |
4 | 0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B, |
5 | 0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02; |
6 | hventerstabdelay = 100; |
7 | progmodedelay = 0; |
8 | latchcycles = 6; |
9 | togglevtg = 0; |
10 | poweroffdelay = 0; |
11 | resetdelayms = 0; |
12 | resetdelayus = 0; |
13 | hvleavestabdelay = 15; |
14 | chiperasepulsewidth = 0; |
15 | chiperasepolltimeout = 10; |
16 | programfusepulsewidth = 0; |
17 | programfusepolltimeout = 5; |
18 | programlockpulsewidth = 0; |
19 | programlockpolltimeout = 5; |
Die Herkunft müsste ich mal im CVS nachsehen, kann sein, dass das mal aus einer älteren XML-Datei des ATmega644P stammte, kann auch sein, dass es durch copy&paste ohne eingehende Kontrolle aus dem Eintrag des ATmega644 entstanden ist. Wenn ich die Parameter aus der aktuellen XML-Datei konvertiere, ergibt sich:
1 | pp_controlstack = |
2 | 0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F, |
3 | 0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F, |
4 | 0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B, |
5 | 0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02; |
6 | hventerstabdelay = 100; |
7 | progmodedelay = 0; |
8 | latchcycles = 6; |
9 | togglevtg = 1; |
10 | poweroffdelay = 15; |
11 | resetdelayms = 1; |
12 | resetdelayus = 0; |
13 | hvleavestabdelay = 15; |
14 | chiperasepulsewidth = 0; |
15 | chiperasepolltimeout = 10; |
16 | programfusepulsewidth = 0; |
17 | programfusepolltimeout = 5; |
18 | programlockpulsewidth = 0; |
19 | programlockpolltimeout = 5; |
Die Unterschiede sind also insbesondere togglevtg, poweroffdelay und resetdelayms. Du kannst ja probieren, diese Parameter manuell in deiner ATmega644P.xml zu editieren um zu sehen, ob's dann auch mit dem AVR Studio funktioniert. Wirklich seltsam daran ist nur, dass AVRDUDE mit ,,falschen'' Parametern hier besser funktioniert.
Hallo Jörg, Volltreffer! Wenn ich powerOffDelay auf "0" setze (und die anderen Parameter belasse, wie sie in der XML-Datei stehen), wird auch das erste Signature Byte richtig gelesen. Danke für den Tipp! Ich glaube, ich schreibe noch mal an den Atmel Support... Viele Grüße Fred
Fred S. wrote: > Danke für den Tipp! Ich glaube, ich > schreibe noch mal an den Atmel Support... Gute Idee. Du wirst ja eh' noch 'ne Ticketnummer haben.
Fred S. wrote: > Ob das nicht auch für Beitrag "Drei Fragen zu AVR Dragon" > relevant sein könnte?? Da sehe ich zwar auch Parameterunterschiede, aber nichts, von dem ich erwarten würde, dass das die Relevanz wie bei dir hat. Insbesondere ist poweroffdelay sowohl in avrdude.conf als auch in der XML-Datei gleich 15.
Hallo Jörg, >> schreibe noch mal an den Atmel Support... > Gute Idee. Du wirst ja eh' noch 'ne Ticketnummer haben. Das Ticket war zwar schon "closed", aber ich habe trotzdem noch einmal geschrieben und auch auf die URL dieses Threads verwiesen. Viele Grüße Fred
Antwort vom Atmel Support: "Thanks, I will take note of this for further references."
Hallo, das könnte evtl. auch die Lösung beim ATTiny26 sein hier hat mein Dragon im HV/PP Mode auch immer eine falsche Signatur ausgelesen. Nachdem dann nichts mehr ging habe ich in der Hilfedatei gelesen das der Dragon Probleme mit dem ATTiny im HV/PP Modus hat das STK500 dagegen nicht. Ich könnte ihn dann vom STK500 aus wieder reanimieren. Werde mir mal den Wert in der XML Datei anschauen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.