www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Leitungslänge beim Dragon


Autor: Fred S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei dem Aufbau wirst du bestimmt auch mit Kontaktprobleme zu kämpfen 
haben.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. wrote:

> teste mal mit einem anderem Resetpullup

Thema verfehlt. :-o  Lies dir den ersten Beitrag nochmal ganz in Ruhe
durch...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
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/

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fred S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Bild des "Drahtverhaus"

Autor: Fred S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: avrdude

(Beim ersten Versuch hatte das AVRStudio noch Kontrolle über den Dragon 
- daher keine Verbindung per avrdude möglich.)

Autor: Fred S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und AVRStudio: siehe Bild

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist schon seltensam...

Im avrdude.conf steht:
    pp_controlstack     =
        0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F,
        0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F,
        0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B,
        0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02;
    hventerstabdelay    = 100;
    progmodedelay       = 0;
    latchcycles         = 6;
    togglevtg           = 0;
    poweroffdelay       = 0;
    resetdelayms        = 0;
    resetdelayus        = 0;
    hvleavestabdelay    = 15;
    chiperasepulsewidth = 0;
    chiperasepolltimeout = 10;
    programfusepulsewidth = 0;
    programfusepolltimeout = 5;
    programlockpulsewidth = 0;
    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:
    pp_controlstack     =
        0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F,
        0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F,
        0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B,
        0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02;
    hventerstabdelay    = 100;
    progmodedelay       = 0;
    latchcycles         = 6;
    togglevtg           = 1;
    poweroffdelay       = 15;
    resetdelayms        = 1;
    resetdelayus        = 0;
    hvleavestabdelay    = 15;
    chiperasepulsewidth = 0;
    chiperasepolltimeout = 10;
    programfusepulsewidth = 0;
    programfusepolltimeout = 5;
    programlockpulsewidth = 0;
    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.

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob das nicht auch für Beitrag "Drei Fragen zu AVR Dragon" 
relevant sein könnte??

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Antwort vom Atmel Support: "Thanks, I will take note of this for further 
references."

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.