mikrocontroller.net

Forum: Compiler & IDEs delay für STK200


Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Ich habe immer mal wieder folgende Fehlermeldung:
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0x00
avrdude: verification error; content mismatch
ich hab -i <delay> bis auf 130 erhöht, es klappt auch besser wie ohne 
delay aber immer noch nicht zuverlässig. Muss ich damit leben, wenn ich 
den STK200 benutze, oder gibts da noch ne andere Möglichkeit?

Gruß Enton

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Möglichkeiten:
-Die Kabel möglichst kurz machen.
-Rechner wechseln.
-Einen anderen ISP bauen, der sich an die Schnittstellenstandards hält. 
Ein 910er ist imho das mindeste, was man sich bei ernsthafter 
Beschäftigung mit AVRs gönnen sollte. Und da du ja schon einen 
sporadisch funktionierenden ISP hast, bist du im Selbstbau für etwa 10€ 
dabei...

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

Bewertung
1 lesenswert
nicht lesenswert
Selbst AVR910 kann ich auf Grund seines mittlerweile völlig
verkorksten Konzepts von "device codes" nicht mehr empfehlen.
Bau gleich was STK500-kompatibles oder etwas vergleichbares,
USBisp oder USBasp kommen mir für den Selbstbau in den Sinn.
Oder investier in einen AVR Dragon, der kann ungleich viel mehr
fürs Geld.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> -Rechner wechseln.
Habs mit 2 verschiedenen Probiert. Immer mit dem gleichen Ergebnis. Mehr 
rechner hab ich leider nicht.
Hab ich das richtig verstanden, das es nur an der geschwindigkeit des 
PC's liegt? D.h. wenn ich es an 10 neuen PC's probieren würde, würde das 
auch nichts bringen, ich braüchte halt nen alten Pentium1 oder so.
Aber mit dem -i delay mach ich ihn doch langsamer, das müsste ja den 
gleichen Effekt haben, wie wenn ich nen alten PC benutze oder?
> -Einen anderen ISP bauen, der sich an die Schnittstellenstandards hält.
> Ein 910er ist imho das mindeste, was man sich bei ernsthafter
> Beschäftigung mit AVRs gönnen sollte.

Hab mal nach 910er 
gegoogelt(http://www.mikrocontroller.net/articles/AVR_In_Sys...) 
und für mich sieht es so aus, als wäre ein AVRISP (wie der STK200 ja 
einer ist) automatisch ein 910er. Oder hab ich da was falsch verstanden?

Gruß enton

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

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schillinger wrote:

> und für mich sieht es so aus, als wäre ein AVRISP (wie der STK200 ja
> einer ist) automatisch ein 910er. Oder hab ich da was falsch verstanden?

Alles komplett miteinander verwürfelt.

Der STK200 ist (aus Sicht seiner Programmierschnittstelle) einfachstes
Bitbanging über einen Parallelport.  Das eigentliche ISP-Protokoll muss
dabei der Hostcomputer abwickeln.  Das ist nicht viel anders als die
einfachsten Selbstbau-Adapter, die man sich teilweise schon mit paar
Drähten zusammenbauen kann.  (OK, der STK200 hat zumindest noch einen
Treiberbaustein mit drin.)

AVR910 und AVRISP (das ist der Name für ein Atmel-Produkt) sind
dagegen ,,intelligente'' Programmiergeräte: sie haben einen eigenen
Controller, der das ISP-Protokoll abwickelt, damit liegt das Timing im
Controller fest, statt durch den Host realisiert zu werden.  Mit dem
Host unterhalten sich beide diese Programmiergeräte über eine
Standard-RS-232-Schnittstelle.  Der Unterschied zwischen diesen beiden
wiederum ist, dass AVR910 ein eher simples Protokoll implementiert,
das erstens von Atmel schon seit Jahren nicht mehr gepflegt wird und
das zweitens die AVRs statt über die signature bytes über irgendwie
erfundene "device codes" adressiert werden, die, seit Atmel das
Protokoll nicht mehr pflegt, einem völligen Wildwuchs unterliegen.
Damit bringt nun jeder ,,seine'' Programmiersoftware für ,,seinen''
AVR910 mit. :-(  Das AVRISP hingegen implementiert die ISP-Hardware des
STK500 und fährt daher dessen Protokoll.  Seit der 2.x-er Firmware
arbeitet dieses Protokoll durchweg mit den signature bytes und mit vom
Host während der Initialisierung eingestellten ISP- Parametern, sodass
es ohne Firmwareänderung auch neuere AVRs programmieren kann.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das AVR Dragon Board sieht wirklich nicht schlecht aus.
In der beschreibung stand aber überall nur was von AVR Studio.
Kann ich das auch unter WinAVR benutzen?

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

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schillinger wrote:

> Kann ich das auch unter WinAVR benutzen?

Ist die Frage, welchen Teil von WinAVR du damit meinst...  Den Compiler
kannst du ja auch mit dem Debugger von AVR Studio betreiben und mit
dessen Programmierwerkzeugen benutzen.  Andererseits kann avrdude über
einen AVR Dragon programmieren und AVaRICE einen Dragon ansprechen,
damit man ihn vom AVR-GDB aus benutzen kann.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte AVRDUDE gemeint. Ich will einfach wie bisher in Programers 
Notepad meinen Code schreiben und dann mit make Program rüberflashen. 
Das müsste also funtionieren,oder?

Bei Reichelt hab ich nen JTAG für den ATMEGA gefunden, der 280€ kostet.
Wie kann das sein, das ein einzelner JTAG weitaus mehr kostet, wie das 
Dragon Board, bei dem der JTAG ja integriert ist?
Liegt das daran, das der JTAG von Reichelt Atmega's mit mehr als 32kB 
Flash unterstützt, oder gibt es da noch andere unterschiede?

Bei der Beschreibung vom Dragon Board wird von der HV Programierung 
abgeraten.
Wenn ich mein externes Board aber über den AVR Dragon versorge, kann 
nichts passieren, nur wenn das externe Board ne eigene Stromversorgung 
hat. Hab ich das richtig verstanden?

Gruß Enton

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

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schillinger wrote:

> Ich hatte AVRDUDE gemeint. ...
> Das müsste also funtionieren,oder?

Ja.

> Bei Reichelt hab ich nen JTAG für den ATMEGA gefunden, der 280€ kostet.

Das dürfte das JTAG ICE mkII sein.  Das ist gewissermaßen der ,,große
Bruder'' des AVR Dragon, der Dragon ist eine Art abgespeckte Version
davon, die auf Kostenersparnis optimiert worden ist.

> Wie kann das sein, das ein einzelner JTAG weitaus mehr kostet, wie das
> Dragon Board, bei dem der JTAG ja integriert ist?

Wie geschrieben, der Dragon ist eine Abrüstversion des ICE, das war
vorher da.  Allerdings hat man dem Dragon dafür noch die HV-
Programmierung vom STK500 zusätzlich mit spendiert.  Die zugehörige
Firmware sei wohl komplett aus dem JTAG ICE und dem STK500 ,,recyclet''
worden, hat mir mal jemand gesagt.

> Liegt das daran, das der JTAG von Reichelt Atmega's mit mehr als 32kB
> Flash unterstützt, oder gibt es da noch andere unterschiede?

Ja, volle Unterstützung für alle AVRs (einschließlich AVR32 und der
nun hoffentlich bald kommenden Xmegas) ist ein Teil davon.  Aber es
gibt noch mehr Dinge beim Dragon, wo man gespart hat:

. ein Gehäuse, klingt trivial, aber ist im Laborbetrieb wirklich
  hilfreich (und sei's nur, dass es Kurzschlüsse vermeiden hilft)

. die Kabelsätze, beim Dragon popelst du dir das alles selbst
  zusammen

. moderne Pegelwandler mit einer labortauglichen Schutzschaltung,
  ein Dragon ist viel schneller abzuschießen als ein JTAG ICE
  (beim ICE hat man in einer zweiten Boardversion die Schutzschaltung
  nochmal drastisch verbessert mittlerweile)

. die serielle Schnittstelle wurde gespart; ist ein netter Fallback,
  wenn USB aus irgendwelchen Gründen gerade streikt

> Bei der Beschreibung vom Dragon Board wird von der HV Programierung
> abgeraten.

Wer rät wo davon ab?

> Wenn ich mein externes Board aber über den AVR Dragon versorge, kann
> nichts passieren, nur wenn das externe Board ne eigene Stromversorgung
> hat. Hab ich das richtig verstanden?

Nö, das ist eigentlich egal, die ISP- und JTAG-Schnittstelle hat auch
beim Dragon Pegelwandler, nur eben einfachere als beim JTAG ICE.  Nur
die HV-Schnittstelle hat keine, aber die ist auch nicht für eine
in-system-Programmierung konzipiert.  Die ist mehr dafür gedacht, dass
du dir auf den Dragon ein paar Fassungen drauflötest und den AVR in
dieser Fassung dann programmierst.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ja, volle Unterstützung für alle AVRs (einschließlich AVR32 und der
> nun hoffentlich bald kommenden Xmegas)

Mit dem Dragon Board kann man doch auch den Atmega32 programieren, oder?
Es heißt doch in der Beschreibung "für Atmega's bis 32kB Flash".
Falls nicht wäre das schlecht, weil ich immer den Atmega 32 benutze.

Beim googeln habe ich 2 Dokumente gefunden, in denen stand, dass es für 
die HV Programierung keine Pegelwandler gibt, und man deshalb vorsichtig 
sein sollte.
Dann hat sich das wohl noch auf die erste Version des Dragon Boards 
bezogen.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich weiss, ist das Programmieren (Einsatz als ISP) von der 32KB 
Grenze nicht betroffen. Das Debuggen (Einsatz als ICE) ist davon 
betroffen.

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

Bewertung
0 lesenswert
nicht lesenswert
Daniel Schillinger wrote:

>> Ja, volle Unterstützung für alle AVRs (einschließlich AVR32 und der
>> nun hoffentlich bald kommenden Xmegas)
>
> Mit dem Dragon Board kann man doch auch den Atmega32 programieren, oder?

AVR32 != ATmega32

Wenn du den Unterschied nicht kennst, dann folge doch einfach mal dem
Link nach AVR32.

Ansonsten hat Stefan das korrekt beschrieben.

> Beim googeln habe ich 2 Dokumente gefunden, in denen stand, dass es für
> die HV Programierung keine Pegelwandler gibt, und man deshalb vorsichtig
> sein sollte.

"vorsichtig" = "HV-Programmierung macht man auf dem Dragon selbst,
nicht in einer externen Schaltung"

Du willst aber JTAG- oder ISP-Programmierung machen, die ist von
dieser Einschränkung nicht betroffen.

> Dann hat sich das wohl noch auf die erste Version des Dragon Boards
> bezogen.

Nein, du hast alles verwechselt. ;-)  Erstens trifft dieser Satz nach
wie vor zu.  Zweitens war das mit der neuen Boardversion das JTAG ICE
mkII, nicht der Dragon.  Drittens betraf es die Schutzschaltung an
den nach draußen geführten Pins (für ISP/debugWire/JTAG), nicht die
Pegelwandler.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Drittens betraf es die Schutzschaltung an
> den nach draußen geführten Pins (für ISP/debugWire/JTAG), nicht die
> Pegelwandler.

Wie kann ich mein Dragon Board beim ISP programmieren zerstören?
Da müsste ich meien Atmega ja schon auf 10V oder so legen, oder?
Wenn ich ihn normal mit 5V versorge kann sollte da doch nichts 
passieren.
( Will nur sicher gehen, das es auf dem Dragon Board in nächster Zukunft 
nicht mal raucht und ich 90€ in den Sand gesetzt habe)

Gruß enton

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

Bewertung
0 lesenswert
nicht lesenswert
Im Laborbetrieb draufgefallene Kabel oder eben ein falscher Griff zum
Spannungsregler am Lab-Netzteil sind da ,,beliebte'' Fehlerquellen.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Im Laborbetrieb draufgefallene Kabel oder eben ein falscher Griff zum
> Spannungsregler am Lab-Netzteil sind da ,,beliebte'' Fehlerquellen.

Mit nen paar Optokopplern müsste man das Problem ja eigentlich beheben 
können.
So hoch ist die Datenrate ja eigentlich nicht. Das müssten Optokoppler 
problemlos packen. Und ein Gehäuse dürfte auch grad noch machbar sein:-)

Autor: adx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man den Dragon im Betrieb an einer bestimmten Stelle anfasst geht 
er auch kaputt. Meines Wissens nach ist das der Schaltwandler für die 
RESET-Spannung beim HV-Programming. Dieses IC regelt sich bei Berührung 
einiger Pins (Berührung mit dem Finger reicht) immer weiter hoch, bis es 
sich schließlich zerstört. Ich frage mich ohnehin warum man dafür einen 
Schaltwandler braucht. Eine Ladungspumpe tut's bei 12V und max. 0,25mA 
doch auch allemal. Außerdem kann der Dragon angeblich kaputt gehen wenn 
der USB-Port zu wenig Strom liefert. Dann bricht die Spannung ein und 
der erwähnte Schaltwandler kommt in einen ungünstigen Betriebszustand. 
Das kann ihn bei längerem Betrieb ebenfalls zerstören. Ich weiß aber 
nicht, ob dann nur der HV-Modus nicht mehr funktioniert oder ob der 
Dragon komplett im Eimer ist. Außerdem sind - wie bereits erwähnt - 
keinerlei Schutzschaltungen an den Programmier-Pins vorhanden.

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.