Hallo! Ich moechte von meinem guten GALep3 auf einen USB-Programmer umsteigen, denn LPT-Schnittstellen werden rar. Dazu habe ich mir das AVRDragon zugelegt. Benoetigt wird er fuer Mega8 und Mega644. Nach einiger Bastelarbeit zwecks Erstellung der Kabel habe ich nun paar Probleme/Fragen: -ISP (getestet mit Mega8). Sobald ich die Frequenz auf 250kHz oder mehr einstelle, wird die Uebertragung nicht mehr stabil (ID-Bytes "wackeln"). Woher kommt diese geringe Frequenz? Kann doch nicht sein, dass die sechs ca. 8cm lange Leitungen das Problem sind? -PP/HV (getestet mit Mega8). Diesen Modus brauche ich unbedingt wegen Zugriff auf alle Fuses und wegen der Geschwindigkeit. Leider kriege ich keine Verbindung auf das Target im PP/HV-Modus (z.B. ID kann nicht gelesen werden). Kabel ist mittlerweile mehrfach geprueft. Gibt es etwas zu beachten ausser der korrekten Verkabelung?? -1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash werden verwendet? Danke im Vorraus. Th.Kusch
> zugelegt. Benoetigt wird er fuer Mega8 und Mega644. Nach einiger > Bastelarbeit zwecks Erstellung der Kabel Einige Bastel-Arbeit? Was ist an einem 1:1 6poligem Flachkabel so schwierig? Oder 10 polig für JTAG? > -ISP (getestet mit Mega8). Sobald ich die Frequenz auf 250kHz oder mehr > einstelle, wird die Uebertragung nicht mehr stabil (ID-Bytes "wackeln"). > Woher kommt diese geringe Frequenz? Kann doch nicht sein, dass die sechs > ca. 8cm lange Leitungen das Problem sind? Wie man direkt im Dialog der Einstellung der ISP-Frequenz im AVR-Studio lesen kann geht der ISP bis 1/4 der Target-Frquenz. Hast Du noch die ClkDiv8 Fuse drin? > -PP/HV (getestet mit Mega8). Diesen Modus brauche ich unbedingt wegen > Zugriff auf alle Fuses und wegen der Geschwindigkeit. Sorry, den verstehe ich nicht. Für PP/HV habe ich überhaupt noch keine Verwendung gehabt. > -1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch > auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash > werden verwendet? Erstens kann der Mega644 kein One-Wire-Debug und zweitens funktioniert Debuggen über den Dragon generell nicht mit Steinen die mehr als 32 KB FLASH haben, das hat leider nichts mit der Codegrösse zu tun.
@Rudolph: >> zugelegt. Benoetigt wird er fuer Mega8 und Mega644. Nach einiger >> Bastelarbeit zwecks Erstellung der Kabel >Einige Bastel-Arbeit? >Was ist an einem 1:1 6poligem Flachkabel so schwierig? >Oder 10 polig für JTAG? Da der Mega8 kein JTAG hat und das Programmieren ueber ISP fuer mich nicht in Frage kommt (1.dauert zu lange, 2. RESET-Leitung kann nicht als IO verwendet werden), muss ein HV/PP-Kabel gebaut werden. Mit 20 Leitungen ist es schon ein gefrickel. Das war aber auch nicht der Kern meiner Fragen. >> -ISP (getestet mit Mega8). Sobald ich die Frequenz auf 250kHz oder mehr >> einstelle, wird die Uebertragung nicht mehr stabil (ID-Bytes "wackeln"). >> Woher kommt diese geringe Frequenz? Kann doch nicht sein, dass die sechs >> ca. 8cm lange Leitungen das Problem sind? >Wie man direkt im Dialog der Einstellung der ISP-Frequenz im AVR-Studio >lesen kann geht der ISP bis 1/4 der Target-Frquenz. >Hast Du noch die ClkDiv8 Fuse drin? Der Atmel ist out-of-the-Box und hat noch nie einen Programmer gesehen.. Aber danke fuer den Hinweis, denn das macht Sinn. Die sind per Default auf 1MHz gefused. >> -PP/HV (getestet mit Mega8). Diesen Modus brauche ich unbedingt wegen >> Zugriff auf alle Fuses und wegen der Geschwindigkeit. >Sorry, den verstehe ich nicht. >Für PP/HV habe ich überhaupt noch keine Verwendung gehabt. Dann hast du entweder noch nie groessere Anzahl auf ein mal brennen muessen, hast noch nie mit einem schnellen Programmen gearbeitet (GALep braucht mit Erase und Verify vllt. 5-6sek fuer einen Mega8) und du hast noch nie ein Design gehabt, bei dem der Reset-Pin als IO verwendung findet. Der ISP ist fuer mich unbrauchbar. >> -1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch >> auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash >> werden verwendet? >Erstens kann der Mega644 kein One-Wire-Debug und zweitens funktioniert >Debuggen über den Dragon generell nicht mit Steinen die mehr als 32 KB >FLASH haben, das hat leider nichts mit der Codegrösse zu tun. Stimmt! Dann halt JTAG. Der zweite Teil der Aussage leuchtet mir aber nicht ein. Wenn ich dafuer sorge, dass keine Zugriffe auf die obere Haelfte des Flash erfolgen, sollte der Dragon imstande sein damit umzugehen. Das Problem sind doch nur die 32kB RAM auf dem Dragon. Es ist dann auch nichts anderes als ein Mega324. Gruss Th
Aehm... nochmal ein Posting reduziert auf eine Frage: hat schon jemand geschafft einen Mega8 mit dem Dragon ueber HV/PP zu programmieren? Das restliche Geplaenkel ist irrelevant. :) Gruesse, Th
Mit ISP schaffst Du den ATMega8 bei 1Mhz ISP-Frequenz locker in 3 Sekunden zu programmieren. Nicht schnell genug? Wenn Du den Reset-Pin als I/O brauchst, solltest Du über einen Controller mit mehr Pins nachdenken oder Deine Hardware optimieren. Der ISP braucht auf einer Platine lediglich 5 kleine Pads oder Headerpins. Was, wenn Du später noch erweitern/updaten willst? 20 Leitungen anbenzeln?
Hallo! OK, Argument gegen Geschwindigkeit ist vom Tisch. Das Design steht nicht zur Debatte (mehrere hundert Exemplare im Umlauf, Update ueber Chiptausch, kein "Freischaufeln" des Reset-Pins moeglich, da es Aenderung der Hardware nach sich zieht.) Bevor ich mich auf so etwas einlasse, bleibe ich beim GALep. Alles andere waere der totale Unsinn: Hardwareredesign wegen Umstellung des Programmiermodus??? Meine Frage ist weiterhin offen: hat schon jemand geschafft einen Mega8 mit dem Dragon ueber HV/PP zu programmieren? Gruss, Th
Nö, aber mit dem STK. Aber warum soll´s mit dem Drachen nicht gehen? Ist Dein USB-Port stark genug? Bricht die Power-LED in der Helligkeit ein?
>Aber warum soll´s mit dem Drachen nicht gehen? Ist Genau das frage ich mich :) >Dein USB-Port stark genug? Bricht die Power-LED in der Helligkeit ein? Nein. Sieht gut aus. An dem Port laeuft sonst eine 2.5" Platte problemlos. Werde wohl doch mal mit dem Oszi messen muessen. :(
Wichtig: versorgst Du Deinen Target-Controller vom Dragon? Falls nicht, kann es arge Probleme geben! Desweiteren darf der Resetpin nicht durch PullUps und/oder Kondensatoren oder gar andere Scahltungen, die an 5V liegen, beschaltet sein. Lies Dir nochmal die HVSP_Description zum Dragon im AVR-Studio (mind. Ver. 4.13 SP2) durch.
Hallo! AVRStudio ist 4.14. AVRDragon ist ueber das Studio aktualisiert worden. Der uC ist auf dem Prototype Area des Dragons in einem DIL-Sockel. Die Beschaltung ist nach dem Device Sheet fuer Mega8 aus der Dragon Doku. Es gibt keine externe Beschaltung des uC oder Fremdversorgung. Gruss, Th.
Miß nochmal alle Spannungen am Controller und check die Verdrahtung. Sonst habe ich keine Idee mehr.
Zum Speicher auf dem Dragon siehe hier: Beitrag "AVM DRAGON 32k Begrenzug aufheben" Kurzfassung: Es sind 128KiB drauf, ein alternativer Footprint für 512 KiB ist vorhanden, ein Austausch bringt aber nichts. Ich habe es ausprobiert, siehe ca. zweite Hälfte des Threads. Die Limitierung steckt in der (verschlüsselten) Firmware.
Hallo! Habe in der Mittagszeit einen HV/PP-Adapter fuer den Mega644 gebaut mit dem gleichen Ergebnis :( Komme leider erst morgen dazu zu messen. Gruss Th
Hallo Thomas, > ...geschafft einen Mega8 mit dem Dragon ueber HV/PP zu programmieren? > Das restliche Geplaenkel ist irrelevant. :) mehr Geplänkel: nein, bisher nur den ATmega32 (ging ohne Schwierigkeiten). Welche Version des AVR-Studio nutzt Du? Es gibt einen Bug ("7052: Removed erroneous check on the JTAG frequency when programming in HV or ISP mode."), der mit dem Studio 4.14 beseitigt wurde. Keine Ahnung, ob dieser Bug evtl. eine erfolgreiche Programmierung verhindern kann. Gruß Fred
Hallo Thomas,
> Danke :) Studio ist leider schon 4.14..
hattest Du ja auch schon oben geschrieben - und ich hab's überlesen...
Viel Erfolg!
Fred
So. habe nun den Support von Atmel angetriggert. ISP laeuft bei beiden Megas, JTAG funktioniert auch. PP/HV macht bei keinem einen Muck. Mal schauen was kommt :) Gruss, Th
Ich hatte letzthin ein paar Atmega88 zerschossen, weshalb ich mir für den Dragon auf die Schnelle einen PP-Adapter zusammengelötet habe. Resultat: Nachdem ich die verlöteten Kabel mehrmals kontrolliert habe, gab ich es auf: die Atmega88 sind billiger als mein Stundenlohn.
Hi, die HVPP-Dragon-Verdrahtung für den ATmega32 und den ATmega644p sind ja identisch. Deshalb habe ich gerade mal versucht, einen ATmega644p im HVPP-Modus zu programmieren. Statt 0x1E liest der Dragon immer 0xff als erstes "signature byte", die beiden anderen stimmen. Mit dem Mega32 gibt es im HVPP-Modus keine Probleme, auch nicht mit dem 644p per ISP. Wohl doch eher ein systematischer Fehler beim Dragon? Viele Grüße Fred
Hi, > HVPP-Modus.... Statt 0x1E liest der Dragon immer 0xff als > erstes "signature byte", die beiden anderen stimmen. Mit dem Mega32 gibt > es im HVPP-Modus keine Probleme, auch nicht mit dem 644p per ISP. Habe dies gerade dem Atmel-Kundendienst mitgeteilt. Mal sehen, wie die das kommentieren. Viele Grüße Fred
ATTiny26 hatte ich mit Dragon im PP Modus auch Probleme mit dem Studio 4.13, das ganze ist bekannt und steht auch in der Hilfe Datei so drin. Hatte mal absichtlich den Resetpin deaktiviert um ihn im PP Modus wieder zu aktivieren mit dem STK500 konnte ich ihn ersrt wieder aktivieren.
Hai! Ich kriege beim Versuch die Signature zu lesen entweder Setting device parameters.. OK! Entering programming mode.. OK! Reading lockbits .. FAILED! Leaving programming mode.. OK! oder (selten) als Signature 0xff 0xff 0xff. Ich hoffe mal, Atmel laesst von sich hoeren. Weiss jemand eine bezahlbare Alternative fuer einen (funktionierenden) HV/PP-USB-Programmer? Einen GALep4 zulegen will ich mir nicht unbedingt... Gruss, Th.
Thomas Kusch wrote: > -1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch > auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash > werden verwendet? Der ATmega644 hat keine debugWIRE-Schnittstelle. Du kannst ihn aber mit dem AVR Dragon per JTAG debuggen. Das setzt allerdings einige Modifikationen voraus, da du dem Dragon vorgaukeln musst, dein Controller hätte nur 32 KiB Flash-ROM. Beim AVR Studio musst du das ATmega644.xml editieren, beim AVaRICE die Datei src/devdescr.cc. Die HV-Programmierung eines ATmega8 mit dem Dragon kann ich heute abend mal zu Hause testen, allerdings habe ich kein Windows und damit kein AVR Studio, kann's also nur mit AVRDUDE testen.
Jörg Wunsch wrote: > Die HV-Programmierung eines ATmega8 mit dem Dragon kann ich heute > abend mal zu Hause testen, allerdings habe ich kein Windows und damit > kein AVR Studio, kann's also nur mit AVRDUDE testen. Funktioniert problemlos (naja, so problemlos wie halt das Gefummel mit den HV-Drähten da ist).
Hallo Jörg! Welches AVRStudio? Welche HW-Version des Dragons? Welche Firmwareversion? Gruss, Th.
Thomas Kusch wrote: > Welches AVRStudio? Gar keins, schrieb ich doch. Läuft bei mir nicht, da ich kein Windows habe (und keins haben will). Getestet mit AVRDUDE. > Welche HW-Version des Dragons? Eine relativ alte, kann ich dir so genau nicht sagen. Wird aber nicht wichtig sein. > Welche > Firmwareversion? Müsste die sein, die bei AVR Studio 4.13.irgendwas mit dabei war. Bin jetzt nicht zu Hause, kann also nicht nachgucken. Ich vermute, 4.13 build 528 war das letzte Mal, dass ich ihn an ein AVR Studio geschleppt habe für einen Firmwareupgrade. Ein 4.14 hat er bestimmt noch nie gesehen.
Hi, > ... Deshalb habe ich gerade mal versucht, einen ATmega644p im > HVPP-Modus zu programmieren. Statt 0x1E liest der Dragon immer 0xff als > erstes "signature byte", die beiden anderen stimmen. Mit dem Mega32 gibt > es im HVPP-Modus keine Probleme, auch nicht mit dem 644p per ISP. Nachricht von Atmel: ich solle mal die Leitungslängen der HV-PP-Verdrahtung überprüfen; bei Atmel konnte der von mir beschriebene Fehler nicht reproduziert werden. Vielleicht liegt es ja auch am ATmega644p (habe momentan nur einen zum Testen, und der kam frisch aus der ESD-Verpackung)? Gruß Fred
Hab gerade keine Zeit, das Gefummel auch noch für den '644P zu basteln. Viel wahrscheinlicher, dass dein Dragon selbst eine Macke hat. Vielleicht ist ja die 12-V-Reset-Mimik kaputt?
Halo Jörg, > Viel wahrscheinlicher, dass dein Dragon selbst eine Macke hat. > Vielleicht ist ja die 12-V-Reset-Mimik kaputt? bin nicht sicher, wem Du hier antwortest. Falls ich gemeint bin: mit dem ATmega32 klappt der HV-PP-Modus ja, nur eben mit dem ATmega644p nicht; das schließt ein Problem mit den 12V auf der Reset-Leitung IMHO aus. Gruß Fred
Ähm: Wenn Du Debug-Wire verwenden wolltest, wieso hast kannst Du dann den Reset-Pin nicht auch für ISP hernehmen?
Fred S. wrote: > Halo Jörg, Ich bin aber gar kein Himmelskörper. ;-) (http://de.wikipedia.org/wiki/Halo_%28Lichteffekt%29) > bin nicht sicher, wem Du hier antwortest. Das kommt davon, wenn man anderer Leute Threads hijackt... Mir war nicht mehr klar, dass es hier um zwei verschiedene Fragen ging. > Falls ich gemeint bin: mit dem > ATmega32 klappt der HV-PP-Modus ja, nur eben mit dem ATmega644p nicht; > das schließt ein Problem mit den 12V auf der Reset-Leitung IMHO aus. Ja, stimmt. Ich habe also doch nochmal das Kabelgewusel aus der Kiste geholt. Ergebnis: ATmega32L, ATmega324P, ATmega644 und ATmega644PV funktionieren allesamt problemlos. Hier noch die gewünschten statistischen Angaben (avrdude -v):
1 | M_MCU: |
2 | boot-loader FW version: 255 |
3 | firmware version: 1.01 |
4 | hardware version: 1 |
5 | S_MCU: |
6 | boot-loader FW version: 255 |
7 | firmware version: 1.09 |
8 | hardware version: 2 |
Angehängte Dateien:
-
parhelion_.jpg
7,3 KB
Hal(l)lo Jörg, > Ich bin aber gar kein Himmelskörper. ;-) siehe Bild. > Das kommt davon, wenn man anderer Leute Threads hijackt... Danke für diesen Vorwurf durch einen Moderator. Schade, dass ich hier so missverstanden werde. Eigentlich geht aus der Entwicklung des Threads hervor, dass es sich nicht um Hijacking handelt. In Zukunft werde ich es einfach vermeiden, Material zur Diskussion beizutragen; man lernt ja aus solchen Vorwürfen. Gruß Fred
Hallo! @Fred.S: nee. bloss nicht. Stoert mich nicht, dass mein Thread hijacked wurde. Kann jeden Hinweis gebrauchen. @coldtobi: >Ähm: Wenn Du Debug-Wire verwenden wolltest, wieso hast kannst Du dann >den Reset-Pin nicht auch für ISP hernehmen? Weil der Mega8 keins hat. Da muss ich HV/PP nehmen. Sonst habe ich von Atmel keine Antwort erhalten. Kam leider auch noch nicht dazu den Dude zu probieren (Master-Studium neben Hauptberuf und Selbststaendigkeit ist hart :) ). Gruss, Thomas
Fred S. wrote: >> Das kommt davon, wenn man anderer Leute Threads hijackt... > Danke für diesen Vorwurf durch einen Moderator. Schade, dass ich hier so > missverstanden werde. Eigentlich geht aus der Entwicklung des Threads > hervor, dass es sich nicht um Hijacking handelt. Du hast einfach dein eigenes Problem gehabt, das nicht notwendigerweise mit dem des OP gleich ist. Wie du siehst, kommt man dann als Leser des Threads nach einer Woche auch schnell durcheinander und hat gar nicht mehr in Erinnerung, dass es sich eigentlich um zwei Probleme gehandelt hat. Ein separater Thread (und ggf. hier ein Posting, was darauf hinweist, dass da ein möglicherweise ähnliches Problem vorliegen könnte) wäre da einfach klarer.
Hier nochmal eine Antwort auf einen ganz alten Beitrag. Ich hatte vorher dort nicht weitergelesen, weil Thomas dann erstmal alles auf die Frage reduziert hatte, ob jemand je erfolgreich einen ATmega8 mit dem Dragon HV-programmiert hat. Thomas Kusch wrote: >>Erstens kann der Mega644 kein One-Wire-Debug und zweitens funktioniert >>Debuggen über den Dragon generell nicht mit Steinen die mehr als 32 KB >>FLASH haben, das hat leider nichts mit der Codegrösse zu tun. > Stimmt! Dann halt JTAG. Der zweite Teil der Aussage leuchtet mir aber > nicht ein. Wenn ich dafuer sorge, dass keine Zugriffe auf die obere > Haelfte des Flash erfolgen, sollte der Dragon imstande sein damit > umzugehen. Das Problem sind doch nur die 32kB RAM auf dem Dragon. Es ist > dann auch nichts anderes als ein Mega324. Nein. Du verkennst das Problem. Der RAM auf dem Dragon hat damit rein gar nichts zu tun, der ist groß genug. Die Begrenzung auf 32 KiB Flash-ROM ist rein künstlich innerhalb der Firmware, damit der Dragon keine Konkurrenz zum JTAG ICE mkII selbst ist. Allerdings kann man das zu einem "Jein" abschwächen: der Dragon verweigert die Debug-Arbeit nur, wenn man ihm im device descriptor eine Flash-ROM-Größe von mehr als 32 KiB angibt. Wenn man ihm nur 32 KiB angibt, dann debuggt er auch einen größeren Prozessor. Ich weiß nur nicht, was passiert, wenn der PC dann jenseits der 32 KiB springt, schließlich weiß die CPU ja nichts davon, dass der Debugger denkt, sie hätte nur 32 KiB. ;-) Die Änderung im device descriptor kann man bei AVR Studio über das partdescription XML file machen, bei AVaRICE nimmt man sie in src/devdescr.cc vor.
@ Jörg Wunsch, danke für die Aufklärung. Ich habe einen separaten Thread eröffnet. Ursprünglich dachte ich, es handele sich um das gleiche Problem. Viele Grüße Fred
Hallo!
@Joerg: danke fuer die Infos zu dem Debug-Limit!!
Habe hier nun den Dude 5.5... benoetige ich irgeneinen Treiber um auf
den Dragon zuzugreifen (mit dem Studio kann ich mich doch nicht
anfreunden.. ist mir zu viel Mausgeklicke..)? Ich kriege naemlich
folgendes:
>avrdude -c dragon_isp -p m644 -P usb
avrdude: usbdev_open(): did not find any USB device "usb"
Gruesse,
Th.
Vergisst es mit dem Treiber... habe die libusb vergessen. Dude weigert sich jedoch wie das Studio im hv/pp-Modus zu programmieren: C:\Downloads\avrdude>avrdude -c dragon_pp -p m644 -P usb avrdude: AVR device initialized and ready to accept instructions Reading | | 0% 0.00savrdude: stk500v2_jtagmkII_recv(): failed Reading | ################################################## | 100% 0.59s avrdude: Device signature = 0xc3ffff avrdude: Expected signature for ATMEGA644 is 1E 96 09 Double check chip, or use -F to override this check. avrdude done. Thank you. :( Gruss, Th
Das stk500v2_jtagmkII_recv(): failed stimmt bedenklich. Das deutet auf tiefer liegende Probleme, möglicherweise mit deinem USB selbst, hin. Ggf. einen anderen USB-Hub benutzen, insbesondere sollte der Hub möglichst einen eigenen Netzteil besitzen.
Hallo! Das Problem ist erledigt.Ich habe das 1.8m lange USB Kabel durch ein 30cm kurzes ersetzt. Jetzt funktioniert auch HVPP! Gruss Th.
Hi, hat jemand in Zwischenzeit mal ausprobiert ob debuggen jenseits des 32KB Bereichs mit dem Dragon funktioniert? -michel
Thread beobachten
Seitenaufteilung abschaltenBitte 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.