Hallo,
habe einen geschriebenen Bootloader im .hex Format
Kann mir jemand sagen wie ich den im Atmel Studio 6 programmieren kann.
in den Fuse sehe ich die einstellungen nicht das ich den aktivieren
kann.
Grüße und hoffe auf Hilfe, bin Anfänger
Stefan
> ... (und Flash Self-Programming) kann erst ab dem Mega88> benutzt werden
Ich denke doch, schließlich gibt es im Datenblatt das Kapitel
'Self-Programming the Flash, ATmega 48A/48PA', allerdings gibt es keinen
eigenen Bereich dafür, 'no separate Boot Loader Section'.
Es ist jetzt die Frage, für welchen Controller dieser "geschriebene
Bootloader" gedacht ist.
Der bootloader ist direkt für den atmega48pb.
Nur stellt sich eine Frage wie bekomme ich den drauf.
Ich kann doch nur mit atmel Studio 6 die Firmware programmieren die ich
auch noch dafür habe als hex file.
> ... bootloader ... wie bekomme ich den drauf
Na, mit einem Programmiergerät; entsprechende Hilfe gibt es sicher hier
in der Artikelsammlung.
Bedenken kommen mir jedoch, wenn ich ausschließlich von "Hex-Files"
lese - ob das etwas wird, so ganz ohne weitere Kenntnisse?
Ich habe einen avr mkii USB mit dem promme ich meine Sachen immer im
atmel Studio.
Nur einen bootloader habe ich noch nicht geprommt.
Da fehlt mir das Wissen halt.
PS:
Natürlich muss diese Firmware berücksichtigen, dass es den Bootloader
gibt, denn beim ATmega48 gibt es nur den Resetvektor, bekanntlich fehlt
der Bootvektor; speziell bei Interrupts wird das wichtig.
Also ganz so einfach wird das wohl dann nicht.
Ich dachte ich promme erst den bootloader genauso wie eine Firmware dann
stelle ich die Fuse um und danach mit Studio die Firmware prommen.
Aber die fuse wie Bootsz zeigt atmel studio ja schon gar nicht an.
Ich wollte das übrigens alles über ISP machen.
S. Landolt schrieb:> Natürlich muss diese Firmware berücksichtigen, dass es den Bootloader> gibt, denn beim ATmega48 gibt es nur den Resetvektor
Nein, das muss sie nur dann, wenn sie sozusagen "am Bootloader vorbei"
gebrannt werden soll. Ansonsten nicht, dann kümmert sich der Bootloader
um alle nötigen Maßnahmen (wenn er denn was taugt).
Allerdings: wenn sie am Boolader vorbei gebrannt werden soll, ist es
i.d.R. nötig, zuvor den Flash zu löschen, damit die Anwendung
funktionieren kann. Sofern das Löschen des Flashs über Chip-Erase
erfolgt (und nicht über eine entsprechende Funktion des Bootloaders) ist
der Bootloader aber wech'...
D.h.: die Applikation darf auch in diesem Fall nix berücksichtigen, denn
es gibt dann nix mehr, was zu berücksichtigen wäre.
Sprich: es gibt (von eher exotischen Sonderfällen abgesehen) nur ein
Szenario, in dem die App die Existenz des Bootladers berücksichtigen
muss:
Wenn sie zusammen mit dem Bootloader in einem Rutsch gebrannt werden
soll. Dann muß mindestens der Resetvector auf Init des Bootloaders
zeigen. Und der eigentliche Inhalt ihres Resetvektors muss in den
entsprechenden Backup-Bereich des Bootloaders verfrachtet werden.
Sprich: der Linker muss dann das tun, was normalerweise der Bootloader
tut.
Die Dokumentation des Bootloaders (PDF File im ZIP File) sagt klar, dass
man die Boot Fuses einstellen muss. Die gibt es beim ATmega48 aber
nicht.
Da der Autor "Peter Dannegger" hier im Forum erreichbar ist, schlage ich
vor, dass du ihn persönlich kontaktierst und fragst, was er sich vor 11
Jahren dabei gedacht hat.
Viel Glück
Stefanus F. schrieb:> Da der Autor "Peter Dannegger" hier im Forum erreichbar ist, schlage ich> vor, dass du ihn persönlich kontaktierst und fragst, was er sich vor 11> Jahren dabei gedacht hat.
Der Trick ist recht einfach. Der Bootloader schnappt sich den RJMP der
Applikation an der Adresse 0x0000 und verschiebt ihn ans Ende der
letzten Page der Applikation. Dafür schreibt er an 0x0000 einen RJMP zu
sich selber.
D.h. die Applikation muß mit einem RJMP starten, was bei C-Compilern für
die ATmega/ATtiny <= 8kB immer der Fall ist.
Damit bei einem Stromausfall während des Programmierens der Bootloader
nicht unerreichbar wird, muß er die Pages der Applikation abwärts
löschen, d.h. den Sprung zu sich selber zuletzt. Fällt genau dann der
Strom aus, ist der Bereich bis zum Bootloader komplett mit 0xFFFF
gefüllt, was wie ein NOP wirkt. D.h. auch im worst-case bleibt der
Bootloader immer erreichbar.