Bootloader size

[spamiam]

When reading Chapter 5 of the language reference, I saw reference to the need to specify the size of the bootloader. The text seemed to suggest that default bootloader would fit in 1024 bytes, but I didn't see this explicitly stated.

What is the size of the default bootloader? I will then set the fuses appropriately. I will first be using a 20MHz 328P, but I also have 88 and 168 devices as well as some larger devices to test.

I am really looking forward to this new facet of the ZBasic world!

-Tony

[dkinzer]

I saw reference to the need to specify the size of the bootloader.

You only need to specify the bootloader size (or the starting address) if you change it significantly. For example, if you add a bunch of code that pushes the mega644P bootloader over 1K you'd need to move up to the next available size: 2K. Then, you'll have to specify the corresponding bootloader start address so that the compiler knows how to access the bootloader entry points. Specifying the bootloader size (2K in this example) is an alternate way to specify the starting address. The compiler subtracts the size from the total flash size to arrive at the starting address.

If you look at the bootloader code you'll see a jump table at the beginning of the code. This is used so that you can modify the bootloader as you wish but the entry points never change relative to the bootloader start address.

Code: Select all

    // bootloader vector table
boot:
    rjmp    startup             // enter here on reset

    // see the routine headers for more details
    rjmp    getLoaderVer        // get loader version
    rjmp    writeFlashWord      // write a word to a page buffer address
    rjmp    writeFlashPage      // write page buffer to a Flash address
    rjmp    runLoader           // run the loader

What is the size of the default bootloader?

For devices with 64K of Flash or less the bootloader size is 1K. For the larger devices it is 2K. The makefile in the zboot directory sets the bootloader address based on the target type. The size is also set (implicitly, via FLASH_SIZE) but this is only used by a program that checks the final linked image to make sure it is not too big. For example (excerpt from the zboot makefile):

Code: Select all

# ATmega devices with 64K of Flash, 1K boot section
ifneq ($(findstring -$(DEVICE)-,-mega64- -mega640- -mega644- -mega644p- -mega645- -mega645p- -mega6450- -mega649- -mega649p- -mega6490- -90can64- -90usb646- -90usb647-),)
BOOT_ADDR  = 0xFC00
FLASH_SIZE = 0x10000
endif

[stevech]

for AVRs with more than 64KB of flash, does the ZBasic language make it totally transparent as to which 64KB area that constant data is stored in? (RAMPZ need not be manipulated by a user program when reading constants that are in flash)?

[dkinzer]

for AVRs with more than 64KB of flash, does the ZBasic language make it totally transparent as to which 64KB area that constant data is stored in?

No. Currently, Flash-based data is assumed to reside in the first 64K of Flash.

[stevech]

does the build/linker place constant data in the first 64K automatically?

[dkinzer]

does the build/linker place constant data in the first 64K automatically?

Yes. The standard avr-gcc linker script places the constant data immediately after the interrupt vector table. The executable code section then follows the constant data. Although ZBasic applications use a customized linker script, that behavior is maintained.

[stevech]

that's OK.
The reason I asked is that I did a web server with an AVR. All the HTML was in-flash string constants. Larger than 64KB. PITA having to do my own flash access code to manipulate RAMPZ. Ideally, this would be on an SD card or some such, but it wasn't that big.