Ich frage mich, wie der Bootloader vor überschreiben durch das Anwenderprogramm geschützt wird.
Üblicherweise wird das ja über
$loadersize = 1024
gemacht. Nur …. 1024 ist der Wert für den MCS-Bootloader!
Bootloader im Digispark
Re: Bootloader im Digispark
Die Hilfestellung von BASCOM schreibt hierzu:
When you use a boot loader it will use space from the available flash memory. The compiler does not know if you use a boot loader or not. When your program exceeds the available space and runs into the boot sector space, it will overwrite the boot loader. The $loadersize directive will take the boot loader size into account so you will get an error when the target file gets too big.
The directive can be used when you have a different programmer selected. For example an external programmer that does not know about the boot size.
Bei dem in https://www.forum.g-heinrichs.de/viewto ... ?f=7&t=120 angegebenen "Programmer" handelt es sich um einen "external programmer".
Ich verstehe die Hilfestellung so: Mit der Direktive $loadersize = xxx kann man die Größe des Bootloaders angeben. Ist das Anwenderprogramm so groß, dass es den Bootloader am oberen Speicherende überschreiben würde, dann gibt Bascom beim Kompilieren eine entsprechende Fehlermeldung heraus. (Alternativ könnte man auch ohne diese Direktive arbeiten und sich die Größe des Kompilats anzeigen lassen, um dann ggf. den Upload zu unterlassen.)
Der Bootloader des Digispark ist übrigens etwa 2 kB groß, bei der neuesten Version sogar nur noch 1588 Bytes groß, vgl. https://github.com/micronucleus/micronucleus. Mit der Direktive $loadersize = 2028 dürfte man also auf der sicheren Seite sein.
Unter https://digistump.com/board/index.php?topic=168.5;wap2 habe ich nun einige weitere Informationen gefunden, die ich hier gekürzt wiedergebe:
Micronucleus [meine Anm.: Das ist hier der Name des Bootloaders] is a small V-USB program, similar to the DigiUSB, DigiKeyboard, and other usb related libraries in the digispark arduino software. Normally programs exist at the very beginning of the flash memory in the attiny85 chip, but micronucleus has been modified so the start of the program is about 6kb of 0xFF bytes. After that, micronucleus begins and uses up the final 2kb. This leaves room at the start of the chip for your own programs, but micronucleus always stays installed at the end...
So when the micronucleus command line tool [meine Anm.: hier ist das Uploader-Programm auf dem PC gemeint] first finds a digispark, it asks it \"How much memory do you have, and how long should I wait after each type of request?\" ... Next, it asks the device to erase it\'s memory and waits the right amount of time for it to do so - about 50 milliseconds to do all 6kb of flash pages. Once that\'s done, it starts uploading 64 byte chunks of your new program. Micronucleus writes in these bytes at the starting 6kb of flash memory, but with one special exception:
In the first page there\'s an interrupt vector table. The bootloader (on the device) replaces the reset vector and the pinchange vector with jump instructions pointing to it\'s own interrupt vector table 6kb later. Other than that, the program is left alone.
When the computer is finished uploading, the bootloader finally writes down what the original values of the user\'s reset vector and pinchange vector were in the very last four bytes of that first 6kb chunk of blank memory.
Danach sollte dieses Tool eigentlich auch wissen, wie groß der Umfang des Anwenderprogramms maximal sein darf und bei Überschreitung dieser Grenze die (weitere) Übertragung nicht durchführen.
Für meine Attiny-Platine habe ich vor einigen Jahren selbst einmal einen einfachen Bootloader geschrieben; unter https://www.g-heinrichs.de/attiny/Bootloader.pdf habe ich recht detailliert beschrieben, wie er funktioniert. Das zugehörige Uploader-Programm verweigert die Übertragung von zu großen Anwenderprogrammen; so ist der Bootlader geschützt. Micronucleus scheint mit einem ähnlichen Prinzip zu arbeiten. Deswegen gehe ich davon aus, dass Micronucleus von sich aus schon ein Überschreiben des Bootloaders vermeidet.
Da mein Bascom-Compiler nur Kompilate bis zu 4 KB erzeugen kann und der Micronucleus-Bootloader 2 KB (je nach Version auch etwas weniger) groß ist, kann ich das aber leider nicht selbst austesten.
When you use a boot loader it will use space from the available flash memory. The compiler does not know if you use a boot loader or not. When your program exceeds the available space and runs into the boot sector space, it will overwrite the boot loader. The $loadersize directive will take the boot loader size into account so you will get an error when the target file gets too big.
The directive can be used when you have a different programmer selected. For example an external programmer that does not know about the boot size.
Bei dem in https://www.forum.g-heinrichs.de/viewto ... ?f=7&t=120 angegebenen "Programmer" handelt es sich um einen "external programmer".
Ich verstehe die Hilfestellung so: Mit der Direktive $loadersize = xxx kann man die Größe des Bootloaders angeben. Ist das Anwenderprogramm so groß, dass es den Bootloader am oberen Speicherende überschreiben würde, dann gibt Bascom beim Kompilieren eine entsprechende Fehlermeldung heraus. (Alternativ könnte man auch ohne diese Direktive arbeiten und sich die Größe des Kompilats anzeigen lassen, um dann ggf. den Upload zu unterlassen.)
- Fehlermeldung bei einem drohenden Überschreiben des Bootloaders
- Fehlermeldung_bei_drohendem_Ueberschreiben_des_Bootloaders.jpg (8 KiB) 62175 mal betrachtet
Der Bootloader des Digispark ist übrigens etwa 2 kB groß, bei der neuesten Version sogar nur noch 1588 Bytes groß, vgl. https://github.com/micronucleus/micronucleus. Mit der Direktive $loadersize = 2028 dürfte man also auf der sicheren Seite sein.
Unter https://digistump.com/board/index.php?topic=168.5;wap2 habe ich nun einige weitere Informationen gefunden, die ich hier gekürzt wiedergebe:
Micronucleus [meine Anm.: Das ist hier der Name des Bootloaders] is a small V-USB program, similar to the DigiUSB, DigiKeyboard, and other usb related libraries in the digispark arduino software. Normally programs exist at the very beginning of the flash memory in the attiny85 chip, but micronucleus has been modified so the start of the program is about 6kb of 0xFF bytes. After that, micronucleus begins and uses up the final 2kb. This leaves room at the start of the chip for your own programs, but micronucleus always stays installed at the end...
So when the micronucleus command line tool [meine Anm.: hier ist das Uploader-Programm auf dem PC gemeint] first finds a digispark, it asks it \"How much memory do you have, and how long should I wait after each type of request?\" ... Next, it asks the device to erase it\'s memory and waits the right amount of time for it to do so - about 50 milliseconds to do all 6kb of flash pages. Once that\'s done, it starts uploading 64 byte chunks of your new program. Micronucleus writes in these bytes at the starting 6kb of flash memory, but with one special exception:
In the first page there\'s an interrupt vector table. The bootloader (on the device) replaces the reset vector and the pinchange vector with jump instructions pointing to it\'s own interrupt vector table 6kb later. Other than that, the program is left alone.
When the computer is finished uploading, the bootloader finally writes down what the original values of the user\'s reset vector and pinchange vector were in the very last four bytes of that first 6kb chunk of blank memory.
Danach sollte dieses Tool eigentlich auch wissen, wie groß der Umfang des Anwenderprogramms maximal sein darf und bei Überschreitung dieser Grenze die (weitere) Übertragung nicht durchführen.
Für meine Attiny-Platine habe ich vor einigen Jahren selbst einmal einen einfachen Bootloader geschrieben; unter https://www.g-heinrichs.de/attiny/Bootloader.pdf habe ich recht detailliert beschrieben, wie er funktioniert. Das zugehörige Uploader-Programm verweigert die Übertragung von zu großen Anwenderprogrammen; so ist der Bootlader geschützt. Micronucleus scheint mit einem ähnlichen Prinzip zu arbeiten. Deswegen gehe ich davon aus, dass Micronucleus von sich aus schon ein Überschreiben des Bootloaders vermeidet.
Da mein Bascom-Compiler nur Kompilate bis zu 4 KB erzeugen kann und der Micronucleus-Bootloader 2 KB (je nach Version auch etwas weniger) groß ist, kann ich das aber leider nicht selbst austesten.
Zuletzt geändert von Heinrichs am Sa 27. Jul 2024, 15:55, insgesamt 2-mal geändert.
-
Alois Bachmeier
- Beiträge: 4
- Registriert: Di 19. Jan 2021, 13:09
Re: Bootloader im Digispark
Also vorneweg ... ich weiß, dass ich hier im falschen Thema bin aber es gelingt mir nicht im Forum "Mini-OLED-Display 128x32" eine Frage/Beitrag zu platzieren. Darum frage ich mal hier:
- Kann mir jemand bez. obigem helfen?
- Die eigentlich Frage: Ich will ein SSD1306 in einen Ruhezustand/Standby versetzten. Ziel ist es, den Stromverbrauch (Batterie!) zu minimieren. Setze ich die Anzeigefarbe auf black, reduziert sich der gezogene Strom von ca.3mA auf ca.1,7mA ..... was mir zu wenig ist. Wenn's keine Möglichkeit gibt, muss ich mit einem Transistor den Strom weg schalten.
- Kann mir jemand bez. obigem helfen?
- Die eigentlich Frage: Ich will ein SSD1306 in einen Ruhezustand/Standby versetzten. Ziel ist es, den Stromverbrauch (Batterie!) zu minimieren. Setze ich die Anzeigefarbe auf black, reduziert sich der gezogene Strom von ca.3mA auf ca.1,7mA ..... was mir zu wenig ist. Wenn's keine Möglichkeit gibt, muss ich mit einem Transistor den Strom weg schalten.
Re: Bootloader im Digispark
Eine Antwort findet man hier...