I have never even considered using or writing a bootloader because it seemed so complicated. The great advantage of it is that you can update the program without any specialized hardware! Once the bootloader is written and installed, all future software changes (other than the bootloader itself) do not require expensive (and delicate) electornics. Since the om128 support files include all the source for the bootloader, I wanted to see how a bootloader works.

The first thing I had to do was to see if I could get it to compile and build with my favorite C programming tools for the AVR.

Atmel's AVR Studio and WinAVR work together to provide a reasonably comprehensive environment. And it is FREE. One thing that Studio will do for you is create a makefile. I always found that the makefile was the hardest thing to figure out, and it always had to be modified as the source modules changed names. Studio keeps track of that stuff for you.

Unlike normal program code, the bootloader is located near the end of the flash memory. The ATMega128 has room for 4096 bytes of bootloader code, but you can specify less if the bootloader is smaller. Lesser processors have less room available for a bootloader.

The OakMicros bootloader is just over 1024 bytes in length, so it needs to have 2048 bytes reserved.

To get the source code to assemble, I put omboot.c, omdevice.c, omdevice.h all in the same folder. I then set the AVR Studio configuration options as follows:

In the general options window, I set the "output file directory" to the same one that has the copies of the bootloader source files.

In the Libraries options window, I selected libc.a and libm.a, and nothing else.

In the memory settings window I had to make a critical change and an addition. Normally you will have nothing specified here and this will
allow the code you write to be placed in the default location (i.r. a regular program). The program code for a bootloader needs to be placed at the start of the bootloader section. on the M128, this is set by the fuses which determine select 512, 1024, and 2048 WORDS (16 bit words) of space to reserve. The fuses are going to be set to allow 1024 words of space.

Program code is placed in the ".text" memory segment. The default location for this is to start at 0000 hex. We need it to start at 1024 words before the end. The end of program space is at FFFF , and the end of normal program space will be 400 hex (1024 decimal) less than that. Therefore the end of normal program space will be at 0xFFFF - 0x400 = 0xFBFF. The first word of bootloader program space therefore is one more than that: 0xFC00.

In the memory section we need to add the following. Click "Add", and this bringe up a small window titled "edit memory segment". Select FLASH as the memory type, type the name as ".text" (do not use quotes), and type 0xFC00 as the memory location.

We need to add another memory section for the permanent data. 16 bytes (8 words) is used, and it is located at the VERY end of the bootloader section. The end of the bootloader is at 0xFFFF - 0x08 = 0xFFF7. The first word of the data is going to be at the next word: 0xFFF8.

So add a new memory section. It also will be in FLASH, it is called ".bootdata" (again skip the quotes), and enter 0xFFF8 as the location.

After this, I clicked "re-build all", and everything compiled. I checked the .lss file and it looks like everything will be loaded and linked properly. I ran the simulator and it seemed to put everything in the right places. The simulator does not simulate a bootloader properly, as far as I can tell, so it only goes so far with the testing before it is necessary to try to load it into your om128.

All of these settings in the configuration allow Studio to create and manage the makefile for you. Believe me, it is worth it to have Studio do it for you!

I have not yet tested the fuse setting aspects of the bootloader installation.

These issues of memory locations are only occasionally necessary for normal programs. I only needed to manually define a new memory segment when I wanted the compiler/linker to manage the locations data in FRAM memory for me. But that is a subject for a different message. Once I get it all straightened out.

-Tony

Post edited by: spamiam, at: 2007/11/10 21:57

spamiam wrote:
The OakMicros bootloader is just over 1024 bytes in length, so it needs to have 2048 bytes reserved.
The bootloader in the om128 download package is 758 bytes long not including the 16 bytes of data at the end. My guess is that you compiled it without optimization. I used the -Os flag which inlines much of the code and eliminates lots of register pushing and popping. Other reasons for the difference might be the version of WinAVR. The om128 bootloader is compiled with WinAVR 20060421.

The fuses are going to be set to allow 1024 words of space.
There is a comment error in the omboot Makefile that documents the bootloader size as 1024 words. That value was used for the development version of the bootloader that was compiled without optimization. For the production version the bootloader is less than 512 words as mentioned.

The Makefile comment has been fixed in the development version of the code. The bootloader source code (omboot.c) correctly documents the HFUSE value of 0xc6. To use the bootloader you have built use a HFUSE setting of 0xc4 which specifies a boot loader flash section of 1024 words (see table 112 on page 287 in the mega128 documentation).


All of these settings in the configuration allow Studio to create and manage the makefile for you. Believe me, it is worth it to have Studio do it for you!
Perhaps you can append the Studio project file to this thread.

I ca confirm that your makefile will result in the smaller code. This is because Studio's makefile does not disable the interrupt vector table and a few other lead-in's. I am investigating how (if possible) to get Studio to delete these things.

Also, your makefile has something in it resulting in a more verbose output that what I get from Studio.

Of course the alternative is clear. Tell Studio to use an external makefile, and point it to your makefile!

I will follow-up if I succeed in doing enough contortions to get Studio to create a makefile as good as the one you supply!

Regarding how much space to reserve for the bootloader.... With a 758 byte (379 word) long bootloader, only 512 words (the smallest possible) need to be reserved. The bootloader memory section in that case starts at 0xFE00 and a byte address of 0x1FC00 (which is what you had listed in your makefile!

Well, it seems as if this ENTIRE thread is a bust. You have all the bases covered, and it may not be worthwhile trying to force AVR Studio to create its own makefile... However, I will plug at it a little longer, just so I learn more about the details of makefiles!

-Tony

I did more playing around. I got a little help from AVRFreaks.

I found that the following lined can be entered in the configuration options:

In [All Files] add "-mno-tablejump" (do not use the quotes)

In [Linker Options] add the following: "-nodefaultlibs" and "-nostartfiles" (also no quotes). These two options could be combined into one: "-nostdlib"

With these settings (and setting the 0xFE00 start of the .text section in memory settings), I got it to match the results of the OakMicros version of the makefile.

At first, I had 850 bytes of program code, but I found that I had 2 extra functions, the ones in omdevice.c which are not used, but were being linked because I had listed that as a source file. When I deleted it from the source file list, I got 736 bytes. The memory map is identical too.

I still do not get the slightly more verbose building output, but there is enough info to know what the final sizes are.

I will attach the project file.

Hmmm, I could not attach the file. I had to convert it to a zip. Then when I wnet back to edit and add the file, the option to attach a file was no longer present. The image attachment option still existed. Anyway, here is the zip file.

spamiam wrote:
In [All Files] add "-mno-tablejump" (do not use the quotes)

In [Linker Options] add the following: "-nodefaultlibs" and "-nostartfiles" (also no quotes). These two options could be combined into one: "-nostdlib"
I was investigating the same thing this afternoon and did the same thing. These additional options can all be found in the omboot Makefile.

At first, I had 850 bytes of program code, but I found that I had 2 extra functions, the ones in omdevice.c which are not used, but were being linked because I had listed that as a source file. When I deleted it from the source file list, I got 736 bytes. The memory map is identical too.
Do you really mean 736 bytes? I checked your APS file and you used bootdata instead of .bootdata; the extra period is significant to match the name in the omboot.c source code.

I will attach the project file.
Only certain filetypes can be attached to appends in this forum. I have added a prompt string to the user interface to remind you which filetypes are accepted.

It turns out that the aps project file is only partly useful because it contains hard-coded paths. I usually use external Makefiles and it turns out that the recognized practice is to export a Makefile from Studio.

I'm glad you got this all setup in Studio now.