Comiling Bootloader With Avr

compiling the bootloader with AVR STudio & WinAVR
Posted by spamiam - 2007/11/10 21:54

_____________________________________
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.
Forums - Oak Micros fireboard Forum Component version: 1.0.2 Generated: 21 February, 2014, 02:21
-Tony
Post edited by: spamiam, at: 2007/11/10 21:57
============================================================================
Re:compiling the bootloader with AVR STudio & WinA
Posted by Mike - 2007/11/11 01:13
_____________________________________
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 add "-mno-tablejump" (do not use the quotes)
In 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.

============================================================================
Re:compiling the bootloader with AVR STudio & WinAVR
_____________________________________
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.
http://oakmicros.com/content/images/fbfiles/files/omboot.zip
============================================================================
Re:compiling the bootloader with AVR STudio &
Posted by Mike - 2007/11/11 17:58
_____________________________________
spamiam wrote:
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.
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.

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.

============================================================================
Posted by Mike - 2007/11/11 18:07
_____________________________________
spamiam wrote:
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.
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.

Only certain filetypes can be attached. I have added a prompt string to tell you which filetypes like ZIP 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.

============================================================================
_____________________________________
I usually use external Makefiles and it turns out that the recognized practice is to export a Makefile from Studio.
Well, I am not sure WHAT the recognized practice is. When I posted a question on AVRFreaks about what to do to get
Studio to make the appropriate bootloader makefile, I was told to grow up and use my own makefile rather than have
Studio create one for me.
Personally, I think that the makefile is so standard and mechanical, that a program OUGHT to be able to make a good
one as long as it knows what to ask you about your intentions.
When I built the omboot project, I was told I got 736 bytes of "Program" (.test + .data + .bootdata) There was also 263
bytes of Data (.data + .bss + .noinit)
When I did the same build with your makefile, I got 736 bytes in .text, 12 bytes in .bootdata, and 263 in .bss. Your output
was more specific and it outlined the individual types.
Thanks for pointing out the missing period in bootdata. I had made changes so often to all those entries as I tried to sort
out the way to get it to work. I was wondering why occasionally the bootdata would turn up elsewhere!
-Tony
============================================================================
Posted by Mike - 2007/11/11 20:27
_____________________________________
spamiam wrote:
mike wrote: I usually use external Makefiles and it turns out that the recognized practice is to export a Makefile from
Studio.
Well, I am not sure WHAT the recognized practice is.
I didn't explain myself very well. What I meant was that instead of exporting a Atmel Studio project, the recognized
practice to interchange this information is to use a Makefile.
============================================================================
_____________________________________
Yes, 736 bytes, at least that is what the compiler is telling me.
Here is the lss and elf file as well as the fixed project file. Here is the output after I modified the Studio file to give more
verbose results vrom avr-size.
Build started 11.11.2007 at 22:55:02

avr-gcc.exe -mmcu=atmega128 -Wall -gdwarf-2 -mno-tablejump -DF_CPU=16000000UL -Os -
funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT omboot.o -MF dep/omboot.o.d -c
../omboot.c
avr-gcc.exe -mmcu=atmega128 -W1,--cref -nodefaultlibs -nostartfiles -Wl,-Map=omboot.map -Wl,-section-
start=.text=0x1e000 -Wl,-section-start=.bootdata=0x1fff0 omboot.o -lc -lm -o omboot.elf
avr-objcopy -O ihex -R .eeprom omboot.elf omboot.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex omboot.elf
omboot.eep
avr-objdump -h -S omboot.elf > omboot.lss
omboot.elf :
section size addr
.data 0 8388864
.text 736 122880
.bootdata 12 131056
.bss 263 8388864
.noinit 0 8389127
.eeprom 0 8454144
.debug_aranges 28 0
.debug_pubnames 92 0
.debug_info 1449 0
.debug_abbrev 463 0
.debug_line 929 0
.debug_str 597 0
.debug_ranges 24 123616
Total 4593
Build succeeded with 0 Warnings...
What do you think? You can check out the lss file to see how the code is getting compiled. Where is the difference from
yours.
I d/l'ed the bootloader into a blank M128, and I get the 1hz blinking LED on PE5. It is configured for 16MHz, because I
don't have a 14.7Mhz crystal to put in it (not easily)
-Tony http://oakmicros.com/content/images/fbfiles/files/omboot-1458fce1d76e999e0f8124b1a120a720.zip
============================================================================
Posted by Mike - 2007/11/12 09:00
_____________________________________
spamiam wrote:
Build started 11.11.2007 at 22:55:02
avr-gcc.exe -mmcu=atmega128 -Wall -gdwarf-2 -mno-tablejump -DF_CPU=16000000UL -Os -
funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT omboot.o -MF dep/omboot.o.d -c
../omboot.c
avr-gcc.exe -mmcu=atmega128 -W1,--cref -nodefaultlibs -nostartfiles -Wl,-Map=omboot.map -Wl,-section-
start=.text=0x1e000 -Wl,-section-start=.bootdata=0x1fff0 omboot.o -lc -lm -o omboot.elf
Nothing wrong with this but you did allocate a boot section of 4096 words when only 512 are needed. Your aps file is
correct however.
What do you think? You can check out the lss file to see how the code is getting compiled. Where is the difference from
yours.
The differences comes down to better register allocation. My guess is that you are using a different compiler. My
compiler from WinAVR 2006 reports:
gcc version 3.4.6
I d/l'ed the bootloader into a blank M128, and I get the 1hz blinking LED on PE5. It is configured for 16MHz, because I
don't have a 14.7Mhz crystal to put in it (not easily)
The 1 Hz blinking PE5 (green LED on a om128) is expected and indicates that no application code has been loaded. I
ran your compiled bootloader and it seemed to work just fine.
============================================================================
_____________________________________
4096 allocated: yes, the print-out showed that I had reserved more space. I did this because I was experimenting with
lower degrees of optimization as I was having trouble tracing through the code with the JTAG debugger. It did not really
help.
After I saved the printout, I changed it back. I have to double check that it is correct, though.
Where do you get the GCC version to display. I did not see it jumping out at me as I compiled, nor when I built the
project. I am pretty sure I have the next to last generation of GCC software, but it might be up-to-date.
I always hate updating the compiler because I get errors reported for code that used to be perfectly fine. So, I only
update when there has been some siginficant change that will be important to keep-up with, such as the total change in
code for interrupts, which happened within the last year and a half. Now it makes more sense. Sort of.
I must say that this has been a very interesting project. Eventhough it is of only marginal use to a user of the om128, or
any of its future siblings, since your installed bootloader works just fine without any need for modification.
For me, it has been very useful to learn more about makefiles, and the mechanics of how to get a boot loader to work. I
like the way yours works: not needing any user intervention on the microcontroller side. As you point out, this is not the
usual way the bootloading process is done, and the usual process requires more user understanding and more user
intervention. While I think that the typical user of the om128 probably would be able to figure out how to get the "usual"
bootloader to work, this sure is convenient!!!
-Tony
============================================================================
Posted by Mike - 2007/11/12 11:17
_____________________________________
spamiam wrote:
Where do you get the GCC version to display.
Type avr-gcc -v
============================================================================
Re:compiling
Posted by owelryverce - 2012/02/01 16:07
_____________________________________
Next, in no convenience duration at all you write upon aside a poorhouse to come near, you'll fete to solder how to
marketing it. But since the covey (and complicatedness) of at mortgage programs hold on to multiply, deciding which
mortgage creation and options to upon is luring more difficult. An pay court to dedicated haecceity attorney, how, can
support you weigh the decisiveness and on the effect and options kindest suited as you.

info
Commonly, sooner between the signing of the acquiesce to away and the closing, a uncontrollable arises that seems
insurmountable to you and/or the seller, and threatens the deal. But since your attorney and the seller's attorney
promote vulnerable to dealt with such problems clashing times at the of, they will-power most of the repeatedly be
masterly to be subjected to a affect at considerate a solution. Of bourgeoning, if the intractable is so austere that it
should prime mover you to bolster to concoct up payment the doodad, your attorney can commend you accordingly.
============================================================================

Comiling Bootloader With Avr

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Comiling Bootloader With Avr

Diunggah oleh

Hak Cipta:

Format Tersedia

compiling the bootloader with AVR STudio & WinAVR

Posted by spamiam - 2007/11/10 21:54

The fuses are going to be set to allow 1024 words of space.

In add "-mno-tablejump" (do not use the quotes)

I will attach the project file.

I will attach the project file.

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

I will attach the project file.

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

Build started 11.11.2007 at 22:55:02

Build succeeded with 0 Warnings...

Anda mungkin juga menyukai