Ich nutze fastboot
(https://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger)
auf einem attiny45, habe reset deaktiviert und muss den bootloader
ändern - ohne HV-Programmer.
Gibt's irgendwo ein Programm, in dem ich den neuen Bootloader als Daten
(hex, bin?) einfügen kann, und das diese dann an die richtige Adresse
schreibt (und sich evtl. selbst löscht)?
Beim nächsten Reset läuft dann der neue Bootloader und ich kann die
eigentliche Anwendung übertragen...
Sollte aber doch bei einem ATtiny45 möglich sein, oder? Zumindest finde
ich auf die Schnelle nichts Gegenteiliges im Datenblatt.
Wobei ich selbst HV-Programmierung vorziehen würde, ist einfacher und
schneller.
Solch ein Programm kann man sich natürlich bauen. Es hat Ähnlichkeit mit
dem russischen Roulett. Um den neuen Bootlader zu programmieren muss es
den alten löschen. Wenn nun ein Fehler auftritt oder der neue Bootlader
eine Macke hat, steht man dumm da. Ich rate dringend davon ab.
Georg G. schrieb:> Um den neuen Bootlader zu programmieren muss es> den alten löschen.
Wie soll er das tun, wenn er auf der gleichen Stelle liegt?
Das einzige was denkbar wäre, daß der vorhandene Bootloader eine SW
lädt, die von einem anderen Speicherbereich aus den Bootloader in den
Flash schreibt.
S. Landolt schrieb:> modifizierte fastboot
Bestimmt, das wäre für mich aber ein großer Umbau in Assembler. Da geht
umlöten schneller.
Statt Schnittstelle gibt es Daten aus dem Flash und die Zieladresse ist
nicht am Ende vom Bootloader sondern irgendwo am Anfang.
IsDochEgal schrieb:> Gibt's irgendwo ein Programm
Wärend du lange danach suchst, wäre ein eigenes sicher bereits fertig.
Prinzip:
Andreas B. schrieb:> Das einzige was denkbar wäre, daß der vorhandene Bootloader eine SW> lädt, die von einem anderen Speicherbereich aus den Bootloader in den> Flash schreibt.
Hier ist, was ich suche, aber ich kann es nicht benutzen:
https://github.com/micronucleus/micronucleus/blob/master/firmware/upgrade.c
// Upgrade is an in-place firmware upgrader for tiny85 chips
// The 'bootloaderAddress' variable in bootloader.h, and the
bootloaderData
// progmem array with the bootloader data, are generated by the
makefile.
//
// Upgrade will firstly rewrite the interrupt vector table to
disable the bootloader,
// rewriting it to just run the upgrade app. Next it erases and
writes each page of the
// bootloader in sequence, erasing over any remaining pages leaving
them set to 0xFFFF
// Finally upgrader erases it's interrupt table again and fills it
with RJMPs to
// bootloaderAddress, effectively bridging the interrupts in to the
new bootloader's
// interrupts table.
//
// While upgrade has been written with attiny85 and micronucleus in
mind, it should
// work with other bootloaders and other chips with flash self
program but no hardware
// bootloader protection, where the bootloader exists at the end of
flash
//
// Be very careful to not power down the AVR while upgrader is
running.
// If you connect a piezo between pb0 and pb1 you'll hear a bleep
when the update
// is complete. You can also connect an LED with pb1 positive and
pb0 or gnd negative and
// it will blink
https://github.com/micronucleus/micronucleus/blob/master/firmware/Makefile#L145
Wie kann ich ein eigenes .hex bzw. .bin dort einbauen? Inwiefern muss
ich auf Adressen / die Größe von fastboot aufpassen?
IsDochEgal schrieb:> - ohne HV-Programmer
Mein Gott.
HV-Programmer kostet auch nicht die Welt, aber gut, muss man nicht haben
wollen.
Eh du da auch nur 1h investierst, schmeiss den Tiny85 weg und setz einen
neuen rein mit dem richtigen Boolader drauf.
Da würde ich nicht mal ansatzweise drüber nachdenken den zu retten.
folgendes auskommentiert:
main.bin: $(OBJECTS)
# @$(CC) $(CFLAGS) -o main.bin $(OBJECTS) $(LDFLAGS)
# @avr-objdump -d -S main.bin > main.lss
main.hex: #main.bin
das bin kann man erzeugen mit avr-objcopy.exe -I ihex boot.hex -O binary
boot.bin
mal schauen, ob das funktioniert...
S. Landolt schrieb:> Sollte aber doch bei einem ATtiny45 möglich sein, oder?
Das ist generell möglich, zumindest so lange keine Lockbits gesetzt
sind. Allerdings muss man dazu natürlich die bestehende "Infrastruktur"
benutzen, d.h. den alten Bootloader, zumindest einen kleinen Teil davon.
Machbar ist das. Aber wohl nicht für den TO...
Man kann eine Applikation schreiben (einen sogenannten Bootloader
Updater), welche den Bootloader austauscht.
Diese Applikation flasht man mit dem alten Bootloader.
Die Applikation startet und überschreibt den alten Bootloader mit dem
neuen.
Währenddessen darf aber nichts schieflaufen. Weil sonst startet der
Kontroller nicht mehr.
Danach kann man wieder eine normale Applikation flashen.
IsDochEgal schrieb:> mal schauen, ob das funktioniert...
nicht so richtig: der geänderte bootloader hat sich zwar manchmal
gemeldet, trotzdem hat es mit dem flashen nicht funktioniert -
wahrscheinlich aber meine Schuld.
Was willst Du denn mit der ganzen Aktion eigentlich erreichen?
Der Sinn eines Bootloaders ist, daß er nach dem Reset immer als erstes
ausgeführt wird und so das Laden einer neuen Applikation ermöglicht.
Insbesondere, wenn eine Applikation fehlerhaft oder unvollständig ist.
Genau - und jetzt soll eben, einmalig, die "neue Applikation" ein
geänderter Bootloader sein; für den Autor von fastboot wäre das sicher
eine fünfminütige Fingerübung.
Eine eigene Frage?
Dieser Thread ist über 5 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
