Operation of Luna bootloader

Summary of the contribution to the explanation of the boot loader functionality from the Luna-Forum.

A so-called bootloader is a small program that is executed beforce starting the user program, dependent on the fusebits of the controller. A boot loader is also stored in the same flash memory of the controller as the user program, but with the difference that it is placed just before the end of the flash memory on certain boundary addresses. The address limit is the einspringpunkt, the controller starts after a hardware reset if the Fusebit BOOTRST has been activated. Which of the usually four different border areas is started, determine the fusebits BOOTSZ0 and BOOTSZ1. The special thing about it is that a program from the boot loader section can writing flash pages (except for the area in which the boot loader itself is located).

Depending on the controller put the two fusebits BOOTSZ0 and BOOTSZ1 determine what the size should be the bootloader area. The size of the bootloader program here determined what size to choose. The available sizes vary between the different controllers, thus it is necessary to look up the values in the data sheet.

Is a boot loader on the controller uploaded, it looks in the flash memory of the controller then, for example like this:

If the boot loader is flashed normally, the controller starts from the set address, in this case, as in the screenshot above with activated Fusebit BOOTSZ1THIRD BOOT START.

The Luna boot loader checks 10x with very short breaks if a command has arrived that puts him in the flash mode, otherwise the boot loader jumps via the command „ReSeT“ to address 0x0000 and thus to a stored there, the user program. If there is none to be found, the program counter moves through the entire flash to the bootloader where it is running again. This is because is written in flashing in the unused areas of the value 0xff, which is the machine instruction „nop“ (do nothing).

From now on his user program must be no longer with z.Bsp. Avrdude to upload the controller, otherwise the bootloader would be deleted / overwritten. It now loads the user program z.Bsp. the boot uploader to the controller. Once this is done, it looks in the store then like this:

If one wants to implement from the user program the function „Firmware supports reset command“ in the boat uploader, we must not jump to address 0x0000 (happens with Luna command reset) with the command to restart. This would even start only the user program again, nothing else. it is necessary for the „reset“ support in the boot uploader only to jump to the bootloader: jump THIRD BOOT START so this is also carried out.

Example

This example contains the boot loader, adapted for the Atmega168, as well as a matching user program. The controller board then requires a serial connection to the PC.
The necessary to be activated fuse bits are:
[x] BOOTRST
[x] BOOTSZ0
[x] BOOTSZ1
The execution start point (or bootloader address) in this case is then FOURTHBOOTSTART.