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

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...

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.

> -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

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.

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?

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.

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

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.

> 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.

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

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.

>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

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

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:-)