Forum: Compiler & IDEs Bootloader auf Attiny85 jedesmal neu brennen?


von Georg (georgwa)


Lesenswert?

Guten Tag zusammen,

ich versuche, auf dem Arduino Uno R3 laufende Sketche an Attiny85 
anzupassen. Klappt soweit. Vor ein paar Jahren habe ich das Gleiche mit 
demselben Uno und derselben Charge Attiny85 gemacht, und ich meine mich 
erinnern zu können, dass man den Bootloader nur ein einziges Mal brennen 
musste. Jetzt ist es so, dass der Upload eines Sketches ohne Neubrennen 
des Bootloaders nur geht, wenn man den unveränderten Sketch ein zweites 
Mal hochlädt, was natürlich wenig Sinn ergibt. Ändere ich auch nur eine 
Variable, kommt beim Hochladen folgende Meldung:

Der Sketch verwendet 2252 Bytes (29%) des Programmspeicherplatzes. Das 
Maximum sind 7616 Bytes.
Globale Variablen verwenden 32 Bytes (6%) des dynamischen Speichers, 480 
Bytes für lokale Variablen verbleiben. Das Maximum sind 512 Bytes.

avrdude: verification error, first mismatch at byte 0x000a
         0x24 != 0x36
avrdude: verification error; content mismatch
Fehlgeschlagenes Hochladen: Hochladefehler: exit status 1

Brenne ich dann den Bootloader neu, funktioniert es.
Ich benutze die IDE 2.3.1 auf Linux Mint und den Arduino Uno R3 als ISP. 
Der Bootloader ist "Optiboot". Ist der vielleicht nicht der Richtige? 
Blind probieren möchte ich nicht, weil ich nicht weiß, ob dabei die 
Attinys Schaden nehmen können. Wäre nett, wenn mir jemand in für Laien 
geeigneten Worten etwas dazu sagen könnte.

von Monk (roehrmond)


Lesenswert?

Für mich klingt das danach, dass Avrdude mit der Option -D "Disable auto 
erase for flash" aufgerufen wird. Normal ist das nicht.

Welchen Arduino Core verwendest du (bitte genau mit Version angeben)? 
Hast du an den vorgegebenen Avrdude Parametern herum gefummelt?

: Bearbeitet durch User
von Georg (georgwa)


Lesenswert?

Wo finde ich die Core-Version?
Es passiert allerdings mit zwei Arduinos auf die gleiche Art. Einer ist 
ein genuiner Uno, der andere ein Clon namens M.J duino Uno R3.

Nein, an Avrdude Parametern habe ich nichts geändert. Wüsste gar nicht 
wo. Allerdings habe ich die IDE einmal wieder deinstalliert und neu 
installiert, ohne dass das etwas verändert hätte.

von Monk (roehrmond)


Lesenswert?

Georg schrieb:
> Wo finde ich die Core-Version?

Im Boardmanager
https://docs.arduino.cc/learn/starting-guide/cores/

Georg schrieb:
> Einer ist ein genuiner Uno, der andere ein Clon namens M.J duino Uno R3.

Ich meine den Core für den ATtiny85.

: Bearbeitet durch User
von Georg (georgwa)


Lesenswert?

Es ist SpenceKonde ATTinyCore Version 1.5.2

von Björn W. (bwieck)


Lesenswert?

Steve van de Grens schrieb:
> Für mich klingt das danach, dass Avrdude mit der Option -D "Disable auto
> erase for flash" aufgerufen wird. Normal ist das nicht.

Bei der Arduino IDE ist das normal.

EDIT: wenn man Optiboot benutzt.

: Bearbeitet durch User
von Georg (georgwa)


Lesenswert?

Heißt das, dass ein anderer Bootloader den beschriebenen Effekt 
vermeiden würde? Welcher wäre dazu denn geeignet?

von Monk (roehrmond)


Lesenswert?

Ich habe gerade versucht, dein Problem nachzustellen, scheitere 
allerdings an der Installation des Cores. Die URL 
http://drazzy.com/package_drazzy.com_index.json leitet auf HTTPS um und 
verwendet dort ein ungültiges Zertifikat.

von Georg (georgwa)


Lesenswert?

Ich habe hier:

https://github.com/SpenceKonde/ATTinyCore/releases

die zip-Datei heruntergeladen, entpackt, einen Ordner "hardware" im 
Sketch Ordner angelegt und die entpackte Datei dort hineinkopiert. Dann 
taucht sie im Boardmanager auf.
Bei der Arduino-App von Microsoft hat das allerdings nicht funktioniert. 
Ich rede hier von meinem Linuxrechner.

von Monk (roehrmond)


Lesenswert?

Ich konnte den Core manuell installieren. Avrdude wird bei mir so 
aufgerufen:
1
/home/stefan/Downloads/arduino-1.8.19/hardware/tools/avr/bin/avrdude -C/home/stefan/Arduino/hardware/ATTinyCore-2.0.0-devThis-is-the-head-submit-PRs-against-this/avr/avrdude.conf -v -pattiny85 -carduino -P/dev/ttyUSB0 -b28800 -D -Uflash:w:/tmp/arduino_build_890587/sketch_feb19a.ino.hex:i

Also der Parameter "-D" ist dabei, wie Björn schrieb. Das muss dann wohl 
so sein.

Was ich mir noch vorstellen könnte ist, dass die Baudrate des ATtiny 
nicht genau genug mit dem USB-UART Adapter überein stimmt. Bei 
Verwendung des R/C Oszillators kommt das manchmal vor. Eventuell hilft 
es, die Versorgungsspannung auf 3,6V zu reduzieren oder am Chip für 
Zimmertemperatur zu sorgen (falls nicht bereits geschehen).

von Georg (georgwa)


Lesenswert?

Der Attiny hat um die 18 Grad, soweit ein daran anliegendes Thermometer 
aussagekräftig genug ist.

von Monk (roehrmond)


Lesenswert?

Georg schrieb:
> Der Attiny hat um die 18 Grad, soweit ein daran anliegendes Thermometer
> aussagekräftig genug ist.

OK

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Monk schrieb:

> Also der Parameter "-D" ist dabei, wie Björn schrieb. Das muss dann wohl
> so sein.

Ja, natürlich. Wäre unschön, wenn der gesamte Flash gelöscht werden 
würde. Hinweis: auch der Bootloader liegt im Flash...

Weil das so ist, funktioniert das nur so: der Bootloader löscht den 
Flash seitenweise, immer bevor er eine Seite beschreibt. Und er 
überschreibt sich natürlich selber nicht.

Übrigens wäre es auch recht ungewöhnlich, wenn ein Bootloader überhaupt 
so ein globales Löschkommando anbietet. Die Gefahr, das es versehentlich 
aufgerufen wird, wäre wohl zu hoch.

Was das eigentliche Problem betrifft: Zur Analyse der Problematik sollte 
der TO mal über ISP den Flash auslesen, und zwar nach dem zweiten 
(fehlgeschlagenen) Schreibversuch. Dieses Images und dazu die originalen 
Hexfiles der beiden Programmversionen dann mal hier hochladen.

Mit ein wenig Glück läßt sich aus dem Vergleich der drei Hexfiles auf 
die Fehlerursache schließen oder zumindest bestimmte mögliche Ursachen 
ausschließen.

von Peter D. (peda)


Lesenswert?

Nun, die classic ATtiny haben keine Bootsektion, d.h. die Ausführung 
startet immer an Adresse 0x0000.
Um dennoch einen Bootloader zu implementieren, gibt es einen Trick. Der 
Bootloader schnappt sich den ersten Sprung von Adresse 0x0000 und packt 
ihn z.B. ans letzte Word der letzten Page unter dem Bootloader. An 
Adresse 0x0000 schreibt er stattdessen einen Sprung zu sich selber. 
Somit wird er immer zuerst ausgeführt.
Macht der Bootloader diesen Trick nicht, dann überschreibt er den Sprung 
mit der Applikation und ist danach nicht mehr erreichbar.

Daneben gibt es wohl noch die Möglichkeit, das durch ein spezielles 
Linkerscript machen zu lassen. D.h. die Applikation darf dann nur mit 
diesem Script gebaut werden. Dieses Script sollte daher in Optiboot 
dabei sein. Dieses Script muß auch an die Flashgröße des konkreten 
ATtiny angepaßt sein.

Weiterhin muß der Bootloader die Pages der Applikation immer absteigend 
löschen. Nur dann wird der Einsprung an 0x0000 als letztes gelöscht und 
ist somit sicher gegen einen Verbindungsabbruch (Stromausfall).

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Peter D. schrieb:
> Nun, die classic ATtiny haben keine Bootsektion, d.h. die Ausführung
> startet immer an Adresse 0x0000.
[...]
> Macht der Bootloader diesen Trick nicht, dann überschreibt er den Sprung
> mit der Applikation und ist danach nicht mehr erreichbar.

So weit ist das erstmal alles vollkommen richtig. Aber deine 
Schlussfolgerung ist es nicht.

> Weiterhin muß der Bootloader die Pages der Applikation immer absteigend
> löschen. Nur dann wird der Einsprung an 0x0000 als letztes gelöscht und
> ist somit sicher gegen einen Verbindungsabbruch (Stromausfall).

Nein, er kann auch in ganz normaler Reihenfolge schreiben, muss eben nur 
"on the fly" patchen. Sprich: erste Page kommt vom Host, wird zum 
Backup-Ort geschrieben, Pageinhalt wird gepatched und dann an den 
eigentlichen Zielort geschrieben.

Die Sonderbehandlung für eine Page hat man immer drinne. Ob die als 
erstes oder letztes geschieht, ist egal.

Bezüglich des Problem des TO spielt diese ganze Problematik übrigens 
keine Rolle. Optiboot kann mit den Classic-Tinys durchaus korrekt 
umgehen. Außerdem würde der Mismatch-Fehler irgendwo auf Adresse 0..3 
liegen, wenn dies hier das Problem wäre.

von Peter D. (peda)


Lesenswert?

Ob S. schrieb:
> Nein, er kann auch in ganz normaler Reihenfolge schreiben

Die Page mit dem Sprung zu sich selber muß als letzte gelöscht und als 
erste wieder geschrieben werden.

Ob S. schrieb:
> Optiboot kann mit den Classic-Tinys durchaus korrekt
> umgehen.

Ich habe keine Beschreibung gefunden, wie der das macht. Für mich sieht 
er eher wie eine Black Box aus.
Aber irgendein Problem muß es ja geben, wenn er nur einmal funktioniert.

: Bearbeitet durch User
von Jobst Q. (joquis)


Lesenswert?

Georg schrieb:
> Heißt das, dass ein anderer Bootloader den beschriebenen Effekt
> vermeiden würde? Welcher wäre dazu denn geeignet?

Wenn du einen Programmer hast, um einen Bootloader zu brennen, brauchst 
du doch keinen Bootloader mehr.

Ein Bootloader ist gedacht, um Arduinomodule über USB oder seriell ohne 
Programmer zu programmieren. Für pure Chips ist er sinnlos, verringert 
nur den Speicher.

Mit ATTinyCore kannst du "No Bootloader" wählen und mit Strg-shift-U das 
Programm hochladen.

Den Programmpunkt "Bootloader brennen" brauchtst du aber eventuell 
trotzdem einmal pro Chip, um über die Fuses den Takt einzustellen. Es 
ist eine Pseudofunktion, dabei werden nur die Fuses geschrieben, der 
Flashspeicher bleibt unberührt.

von Oliver S. (oliverso)


Lesenswert?

Jobst Q. schrieb:
> Wenn du einen Programmer hast, um einen Bootloader zu brennen, brauchst
> du doch keinen Bootloader mehr.

Bei den allermeisten und auch beim TO wirds eher umgekehrt sein...

Oliver

von Jobst Q. (joquis)


Lesenswert?

Oliver S. schrieb:
> Bei den allermeisten und auch beim TO wirds eher umgekehrt sein...

Er hat einen Programmer.

Georg schrieb:
> Brenne ich dann den Bootloader neu, funktioniert es.
> Ich benutze die IDE 2.3.1 auf Linux Mint und den Arduino Uno R3 als ISP.

Und ein AT85-Chip hat anders als ein Modul fabrikmäßig noch keinen 
Bootloader.

von Oliver S. (oliverso)


Lesenswert?

Natürlich.

Und der allgemeine und auch hier vorliegende Anwendungsfall ist dann, 
daß man auf dem AVR gerne einen bootloader hätte, den man dann einmalig 
per Programmer drauf braten muß, weil halt ab Werk keiner drauf ist - 
was bei so gut wie allen AVRs der Fall ist. Die Maker-Sonderlocke 
"Arduino" ist nicht der Normalfall.

Oliver

von Jobst Q. (joquis)


Lesenswert?

Oliver S. schrieb:
> Natürlich.
>
> Und der allgemeine und auch hier vorliegende Anwendungsfall ist dann,
> daß man auf dem AVR gerne einen bootloader hätte, den man dann einmalig
> per Programmer drauf braten muß, weil halt ab Werk keiner drauf ist -
> was bei so gut wie allen AVRs der Fall ist. Die Maker-Sonderlocke
> "Arduino" ist nicht der Normalfall.
>
> Oliver

Hat sich vielleicht in der Arduino-Szene noch nicht genug 
herumgesprochen, dass man Mikrochips auch ohne Bootloader programmieren 
kann. Und dass dazu nicht mehr gebraucht wird, als man braucht, um einen 
Bootloader neu zu brennen.

Auch die Arduinomodule ohne USB wie den Pro-Mini programmiere ich direkt 
ohne Bootloader. Zum Uploaden kurz zusätzlich die Umschalttaste zu 
drücken, ist ja kein merklicher Mehraufwand. Und man spart sich den 
ganzen Ärger mit den Inkompatibilitäten der Bootloader.

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
Noch kein Account? Hier anmelden.