Hallo, vielleicht wisst ihr Rat? Folgendes Setup ich habe ein selbst entwickeltes Board mit ATMega328, 5V, 16MHz und ISP Interface. Abweichend vom Standard nutze ich den Athena Bootloader, sodass ich später per Netzwerk die Software aktualisieren kann. In Arduino arbeite ich mit der Einstellung "Arduino Pro oder Pro Mini". Ein rein privates Projekt. Den Bootloader kann ich mit avrdude auch erfolgreich flashen und dann per tftp auch Software aktualisieren. Wenn ich aber über die Arduino IDE mit dem AVRISP mkII oder direkt mit avrdude meine Software flashe, ist der Bootloader weg. Wie kann ich Arduino bzw avrdude so konfigurieren, dass der Bootloader nicht überbügelt wird? Danke für jegliche Tips!
Gero schrieb: > Wie kann ich Arduino bzw avrdude so konfigurieren, dass der Bootloader > nicht überbügelt wird? Das geht nicht! Ein Chip Erase ist ein Chip Erase und bleibt ein Chip Erase. Aber: Du kannst eine eigene boards.local.txt erstellen wo du dann deinen Bootloader einstellst und dann Programm+Bootloader in einem Stück schreibst.
Gero schrieb: > Wie kann ich Arduino bzw avrdude so konfigurieren, dass der Bootloader > nicht überbügelt wird? Zum Beispiel indem man den vorhandenen avrdude(.exe) in der Arduinoinstallation löscht und durch ein FTP-Programm für den Athena-Bootloader ersetzt, das dann in avrdude umbenannt wird. Dann wird nichts weggebügelt. Just my 2 cents
EAF (Gast) 18.12.2022 15:31 >Das geht nicht! >Ein Chip Erase ist ein Chip Erase und bleibt ein Chip Erase. Eher nicht. Das Flash wird "Page" weise gelöscht und man kann den Boodloader stehen lassen. Was man tun muss: im Linker File die Code-Section entsprechend setzen, damit der Bootloader nicht überschrieben wird.
Klaus S. schrieb: > Zum Beispiel indem man den vorhandenen avrdude(.exe) in der > Arduinoinstallation löscht und durch ein FTP-Programm für den > Athena-Bootloader ersetzt, das dann in avrdude umbenannt wird. Sicher, dass das ein guter Tipp ist? Hier wird festgelegt welches upload tool verwendet wird: https://github.com/arduino/ArduinoCore-avr/blob/master/boards.txt#L197 https://github.com/arduino/ArduinoCore-avr/blob/master/boards.txt#L202 Eigene Einstellungen kann man in der boards.local.txt vornehmen Hier wird der Path festgelegt: https://github.com/arduino/ArduinoCore-avr/blob/master/platform.txt#L101 Eigene Einstellungen kann man in der platform.local.txt vornehmen Somit besteht keinerlei Notwendigkeit AVRdude zu entfernen. chris_ schrieb: > Das Flash wird "Page" weise gelöscht Ja? Wie? Mein Stand ist: Wenn man einen ISP Adapter nutzt, wird bei -U, auch der Bootloader gelöscht. Der Linker hat da gar nichts dran zu melden. Dabei ist es doch gar kein Problem, wenn der Bootloader dabei gelöscht wird, da doch Arduino auch eine *.hex mit Anwendung und Bootloader, in einem Brocken, erstellt.
EAF schrieb: > Mein Stand ist: > Wenn man einen ISP Adapter nutzt, wird bei -U, auch der Bootloader > gelöscht. Der Linker hat da gar nichts dran zu melden. Mit dem ISP-Adapter hat das auch nichts zu tun. Und -U ist eine Option für das verbreitete ISP-Programm(!) avrdude. In der Tat führt avrdude(nicht der ISP-Adapter!) beim Vorhandensein der Option -U ein chip erase durch. Das kann man aber abschalten:
1 | man avrdude |
2 | |
3 | -D Disable auto erase for flash. When the -U option with |
4 | flash memory is specified, avrdude will perform a chip |
5 | erase before starting any of the programming operations, |
6 | since it generally is a mistake to program the flash with‐ |
7 | out performing an erase first. This option disables that. |
Man kann also durchaus den Bootloader und die Applikation einzeln flashen. Man muß bloß sicherstellen, daß sie sich nicht überschneiden (vulgo: Linkerskript). Und man muß beim zweiten Flashvorgang das automatische Löschen abschalten. Alles kein Hexenwerk. OK, für einen Verwender der Arduino "IDE" vielleicht doch.
:
Bearbeitet durch User
EAF schrieb: > Sicher, dass das ein guter Tipp ist? Ja, klar. Hätte ich ihn sonst gegeben? Für mich ist es eben die einfachste Lösung. Jeder darf aber seine Lösung als die Einfachste anbieten, ich werde nicht widersprechen. EAF schrieb: > Somit besteht keinerlei Notwendigkeit AVRdude zu entfernen. Deswegen begann mein Satz mit: Zum Beispiel. Lesen bildet! Außerdem kann jeder, der den avrdude noch braucht und ein wenig Resthirn im Kopf hat, den avrdude umbenennen. Hatte nicht damit gerechnet, daß sowas hier unbekannt ist. Ich bitte um Entschuldigung. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Lesen bildet! Ja! Z.B. könntest du mal das Eingangsposting lesen... Dort steht, dass ihm seine Firmware updaten will, ohne den Bootloader zu überschreiben. Und du möchtest AVRdude umbenennen.... Sicher, dass das ein guter Tipp ist?
EAF schrieb: > Dort steht, dass ihm seine Firmware updaten will, ohne den > Bootloader zu überschreiben. Dort steht, dass ihm seine Firmware updaten will, über einen ISP Adapter, ohne den Bootloader zu überschreiben.
Axel S. schrieb: > Und man muß beim zweiten Flashvorgang das > automatische Löschen abschalten. Auch der Kollege kann nicht lesen! Oder verstehen..... Im ersten Beitrag steht, dass ihm seine Firmware updaten will, über einen ISP Adapter, ohne den Bootloader zu überschreiben. Das geht nicht ohne das Flash vorher gelöscht zu haben! Ohne löschen, mit alter Firmware drin, kommt eine solche oder vergleichbare Meldung:
1 | avrdude: verifying ... |
2 | avrdude: verification error, first mismatch at byte 0x0002 |
3 | 0x10 != 0x34 |
4 | avrdude: verification error; content mismatch |
Es bleibt dabei: Damit die Arduino IDE da mitspielt, muss man ihr den neuen Bootloader zur Verfügung stellen und die Boarddefinition anpassen. Dann klappt das schon! Aber ich habe ja keine Ahnung (von AVR/Arduino/ISP/Flash)... Und kann offensichtlich auch nicht lesen. Oder gar die maximale Programmgröße dort eintragen....
https://github.com/embeddedartistry/athena-bootloader Wenn diese Hardware Definition genutzt wird, dürfe eine Zeile in der (noch anzulegenden) platform.local.txt ausreichen, damit das Eingangs geschilderte Problem nicht mehr auftritt:
1 | tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.with_bootloader.hex:i" |
Dann lädt der Menüpunkt "Hochladen mit Programmer" Anwendung und Bootloader in einem Rutsch hoch. Incl. vorhergehendem Chip Erase Den Menüpunkt "Bootloader brennen" muss man nur einmal ausführen, damit die Fuses richtig stehen.
Gero schrieb: > Wie kann ich Arduino bzw avrdude so konfigurieren, dass der Bootloader > nicht überbügelt wird? EAF schrieb: > Dort steht, dass ihm seine Firmware updaten will, über einen ISP > Adapter, ohne den Bootloader zu überschreiben. Mal davon abgesehen, daß ich die Passage "dass ihm seine Firmware updaten will" etwas befremdlich finde, kann ich auf den Ausgangssatz des TO so lange draufglotzen, wie ich will, ich finde da keine Festlegung auf ISP. Ich habe einen Vorschlag für Arduino-IDE ohne ISP gemacht, EAF hat einen Vorschlag mit ISP gemacht. Beide werden vermutlich funktionieren. Eigentlich wäre jetzt der TO dran, seine sehr vornehme Zurückhaltung aufzugeben. So langsam kommt mir der Verdacht, daß es sich wieder mal um so ein Exemplar vom Stamme Nimm handelt, der gerne seinen Arsch abgewischt haben möchte. Just my 2 cents P.S. Habe gerade eine eklige Grippe. Vielleicht bin ich deshalb so grantig :-(
Klaus S. schrieb: > ich finde da keine Festlegung > auf ISP. ich schon: Gero schrieb: > Wenn ich aber über die Arduino IDE mit dem AVRISP mkII oder direkt mit > avrdude meine Software flashe, ist der Bootloader weg. Sein Upload über Ethernet funktioniert ja schon..... Ist also hier nicht sein Problem.
EAF schrieb: > Sein Upload über Ethernet funktioniert ja schon..... > Ist also hier nicht sein Problem. Eben dehalb hab ich ja genau den empfohlen. Wie lange dauert es noch, bis der Groschen fällt?
Hallo zusammen, hier nochmal der TO Ich habe es nun so gelöst: Bauen mit dem Menüpunkt "kompilierte Binärdatei exportieren" Dann starte ich auf der Kommandozeile ein kleines shell script, welches das entstandene hex zunächst in ein bin umwandelt. Dann schickt es per UDP ein spezielles Kommando an den Atmel, der bootet daraufhin neu und steht somit im Bootloader. Das Script startet sodann den tftp upload. Es ist zwar nicht der ursprünglich beabsichtigte Weg, hat sich jedoch als sehr komfortabel, zuverlässig und schnell erwiesen. Ein Update-Zyklus dauert ca. 3 Sekunden. Danke an alle und frohe Weihnachten
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.