program hex file size - I am confused :(

Go To Last Post
42 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I am really confused with this stuff. After compiling my program on avrstudio 5 for UC3A1256 device I get th following:

AVR Memory Usage
----------------
text data bss dec hex filename
76414 12628 5476 94518 17136 myProg.elf

where as on my harddrive the file myProg.hex takes up 245KB.

How does that work?? Shouldnt it be 17.136KB?

I am trying to understand what actually needs to be programmed when doing loading from bootloader...which part of the hex file must be passed to the bootloader so it can flash the program region?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also noticed getting rid of sprintf from my code mades a huge difference to the size of the hex file! For the first use of sprintf in the code it takes up about 60KB of additional hex. Subsequent use of sprintf in the code doesnt take much space...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The memory usage report tells you about the actual binary sizes of the code, constant data etc.

The hex file contains this data but coded in a different format: To start with every binary byte is coded into two characters in hexadecimal notation. So if you have the binary 11000101 (one byte), this would be encoded as the two characters (i.e. two bytes) C5. Thus the hex file is at least double the size of the binary app. Then you have checksums, and the hex file is also divided into lines (adding line termination characters). Each line also starts with some address information and stuff. Yes hex files are much larger than the binary app. Perhaps 2.5 times the size - this fits well with your binary app being 94518 bytes and the hex file being 245KB.

For more info on the "Intel hex" file format, look no further than Wikipedia. Or do a search here - the subject comes up with remarkable periodicity.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
 text  data  bss   dec   hex filename
76414 12628 5476 94518 17136 myProg.elf 

The 'hex' entry should really say 0x17136.
It is exactly the same number as the 'dec' entry.

Wikipedia articles are generally very well written. Look up bss. You should get text and data explained in the same article.

Note that text and data are the only real bytes that need to be written to a HEX file. (76414+12628)*2.5 = 222605. Note that the '2.5' is very much a rule of thumb for Intel Hex format encoding.

The bss does not need to go in the HEX file. It is a contiguous series of zeros. It gets cleared at runtime.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note also that avr-size works on .hex files to tell you how much binary they contain ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok so how do i convert this hex file into real binary that I need to write onto the avrflash? I need to save this bin part only in my SPI flash from there I can let bootloader to grab and flash the onchip flash...

Also does anyone know why the first usage of sprintf in the code takes up about 60kB of hex? well that would be more like 20KB+ of real bin?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

ok so how do i convert this hex file into real binary that I need to write onto the avrflash?

Did you care to read the Wikipedia article that explains how the format works?

Quote:

Also does anyone know why the first usage of sprintf in the code takes up about 60kB of hex?

Are you using floats? Are you linking with libm.a? Aprt from that it is not strange that the first call to some complex library function increases the size of the app a lot, while the consequent calls adds only a small amount. For the first call the linker will bring in the pre-compiled code in the library and make the call per se. For the consequent calls only code for the calls per se will need to be generated.

I have no experience with AVR-32 devices, so can't say anything specific about if 20K for adding sprintf support is reasonable or not.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lol no I didnt read up wiki...but the explanation provided here about hex file was adequate for my understanding :)

Atmel should provided us a tool to convert this hex file to bin file :(

I had a feeling it is it to do with library stuff being included...no I am not using floats in sprintf not am I using libm.a...should I be?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but the explanation provided here about hex file was adequate for my understanding

Then there should be no further questions, eh.. :wink:

Quote:

Atmel should provided us a tool to convert this hex file to bin file Sad

Why? You're just coming through as spoiled and demanding spoon-feeding right now. Normally, this is a job done by the different flash programming software thingies (like STK500.exe, AVRdude and many others). If I where you, I'd start looking at some complete bootloader projects, which should include such code.
Quote:

I had a feeling it is it to do with library stuff being included...

Of course it does. The sprintf implementation does not appear out of thin air.

Let me ask you this: Are you attempting to write a bootloader from scratch? Why not take an existing one and modify it to your needs? There must be many bootloaders available that has a ready-to-use implementation of the conversion of a Intel Hex file to binary flash contents.

Did you try a Google for "convert intel hex to binary" and similar. I have a feeling that the srecord utility will show up, and that it can help you, but I have not been using it myself so you'd have to study and try it out yourself.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lol thanks for that :)
yes I have been looking at the atmels MSU and DFU bootloader...still notmaking sense to me. I think there might be a dos shell provided with one of the atmels bootloader sample codes..that converts intel hex to bin type...but last time I ran it, didnt seem to work. Just gave me a few windows warning.

The thing is I want to be able to load boot codes from an SPI flash...and the atmel codes seem to refer to usb or isp stuff... a lil tifferent to my need. Also I am having trouble understanding how to load this bootloader code...in another thread I am getting the impression that I need a different hardware? I only have stk600 and avrstdio5. :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The thing is I want to be able to load boot codes from an SPI flash...and the atmel codes seem to refer to usb or isp stuff...

I fail to see that the medium that serves the Intel Hex file has anything to do with how this Hex should be converted to a binary. You must try to divide your project into several small modules, as indepenent from one another as possible. You write the Hex-to-binary converter so that it does not care about where the Hex comes from. You write the flash programming part so that it does not care about where the binary comes from. Etc. Then you glue those together with some controlling logic. If you are trying to take this on as one monolithic piece of code you are in for guaranteed failure.

Quote:
Also I am having trouble understanding how to load this bootloader code...

You should be able to get a bootloader onto your AVR with the STK600 and AVR Studio 5, and nothing else.

Have you read the bootloader tutorial?

Did you investigate the srecord utility, and if it can help you?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know that... yes I will have to write my own hex to bin converter if I cant get the atmels dos shell thing to work properly... I was not planning to have the converter be run on the micro at all :)

according to avr app notes for bootloaders I can see it says I need "AVR ONE!, JTAGICE mkII". Doesnt say anything about STK600 even though it has JTAG. Also I do not see in AvrStudio5 any options for us to be able to change the programming location? It must be fixed to 0x80008000??

ah yeah thats the program I was taking about...srec...its added in the atmel appnote codes...but it gave me some windows warning when I ran..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I was playing with it just now...it seems the warning is about some options the cmd shell uses "Maximum" options, which it now says deprecated and advises to use maximum-address.
so once I appended that "-address" to the code in cmd shell it worked without a warning...either way it generates the avr32fwupgrade.uc3 file which I understand is the final binary I need!
:D

so now I have to find a way to actually load a bootloader first... :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

so now I have to find a way to actually load a bootloader first...

Luvocean1: You've ignored advice and questions so many times now I can only resort to screaming:

DID YOU READ THE BOOTLOADER FAQ IN THE TUTORIALS FORUM?!?

And with that I'm out.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Atmel should provided us a tool to convert this hex file to bin file

They do (though it actually comes from GCC binutils in fact). It's called avr-objcopy and it will happily convert a .hex to a .bin though I know a lot of people just download hex2bin.exe and bin2hex.exe to do the same thing. To use avr-objcopy use:

avr-objcopy -I ihex -O binary input.hex output.bin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan I just read the pdf there...have a better understanding now..but question still remains..when avrstudio5 programs the uc3 chip can it only program from 0x80008000 section? That would be the application section.

Claws on thatks for that use windows..I think I saw a section in avrstudio where u can place those commands post compilation...will try nextime I m on my desk..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are only interested in .bin and don't care about .hex see if you can modify the default avr-objcopy that usually extracts .hex from .elf and have it create .bin instead. When using Mfile this is as simple as:

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

when avrstudio5 programs the uc3 chip can it only program from 0x80008000 section?

1. When you build the application you specify that the code will go into the bootloder section.
2. The hex file contains the addresses (so when you build for the bootloader section the hex will have bootloader section addresses).
3. The programming software reads the hex, including the addresses, and programs the correct flash pages.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah Clawson I put your command line in the Build Events tab...and it seemed to work and generated the .bin file. Please see the attached image. So I am thinking this is the same file that would have been generated with srec_cat as well? And this is the file that actually is put into the flash of the avr/uc3a?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:

when avrstudio5 programs the uc3 chip can it only program from 0x80008000 section?

1. When you build the application you specify that the code will go into the bootloder section.
2. The hex file contains the addresses (so when you build for the bootloader section the hex will have bootloader section addresses).
3. The programming software reads the hex, including the addresses, and programs the correct flash pages.

Hmm... I see. But please dont scream at me :( how do you make sure or find out what address it is set to for your program in avrstudio5? Where do I go to change it? I am not so bright in these things like you guys are...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

how do you

Read the datasheet.

[I've never read a UC3 datasheet but I've no reason to believe that the information will not be fundamentally similar to tiny/mega/xmega]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I think I am getting it now....had to do some good digging around in avrstudio... I need to edit some assembly files for booting. I am looking at an example boot file.... there are instructions like mov.w which if I use in my code I get errors like "unrecognised instruction mov.w r8, 0".....any idea why?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why don't you ask this in one of the AVR32 fora - you surely cannot be the first person wanting to write a bootloader for a UC3. To be honest (though I don't know AVR Studio 32) I don't know why you'd think it necessary to mess around in the Asm code of the C runtime. In AVR8 land you use -Ttext=0xNNNN to the linker to move .text (and everything else) to position the B/L code at the bootloader address.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ah yes the AVR32 forum is like waiting for lightyears to get an answer.... you guys are much more helpful even if its not right to the point sometimes.... I found out that you can do the same with avrstudio5 in the linker flags and put "-e,_trampoline" for example and the booting will occur from where the _trampoilne function is defined....or similarly any other function that is defined in the linker flags area...

and in regards to the mov.w looks like the code there uses mov.w as a macro... so I am going to copy the macro mov.w.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I found out that you can do the same with avrstudio5 in the linker flags and put "-e,_trampoline" for example and the booting will occur from where the _trampoilne function is defined....or similarly any other function that is defined in the linker flags area...

I completely fail to see why that option would be of any use for a bootloader. You want a bootloader (assuming written in C) to be entered at main() just like any other C program. The only difference for a bootloader is that the whole thing is not linked to load at 0x0000.

Again I have no idea why you'd need to be messing with mov.w asm macros.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well with the UC3A flash sections... you have the bootloader starting from 0x8000 0000 and the main program starting from 0x8000 2000, given that the boot section is set to 8Kb. So I from what I understand I need to flash the chip with my main program, trampolined from 0x8000 2000, but the execution starts from 0x8000 0000.

After programming the main app hex I can then program the boot code which basically starts at 0x8000 0000 and does some tests to see wheather the main program should be started, if yes then does a "lddpc pc, prog_start" where prog_start is 0x8000 2000.

Do you know how to embed that "lddpc pc, prog_start" assembly instruction inside C code? because then I would be able to write my Boot code using C instead of assembly..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So I from what I understand I need to flash the chip with my main program, trampolined from 0x8000 2000, but the execution starts from 0x8000 0000.

Then you've almost certainly misunderstood how a bootloader works. Did you read the FAQ that Brad and I wrote in the Tutorial Forum? Bottom line the AVR contains two completely separate programs built in isloation. The only difference with the B/L is it's location.

When the bootloader finally decides it's ready to launch the application it does something like:

typedef void (*f_ptr)(void);

f_ptr foo = (f_ptr)0x80002000;

foo();

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

luvocean1, I am not sure what do you exactly want. Do you want:

1) Write a AVR32 application and use an Atmel JTAG programmer?
2) Write a AVR32 application and use it with the pre-installed USB DFU bootloader?
3) Write your own bootloader?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(3) it would appear.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Did you read the FAQ that Brad and I wrote in the Tutorial Forum?

Cliff! Ive asked him that two or three time in this thread, and the closest he has come to an answer of that is that i) "he understands everything now" (but continues to ask questions) and perhaps ii) that we are so good at answering his questions (implies that he does not need to read it as long as we do that).

I'm out.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lol ok come on guys :(
PeteAVR... I have an application program (trampolined at 0x8000 2000) which has the ability to download a firmware over the air....it dumps the firmware as it receives to a SPI flash memory and then sets the flash user page (a flag used for identifying if boot loading should be done after restart) recommended for the UC3 series. So after this the application program sets the watchdog and hence causes a restart..

after restart the PC goes to 0x8000 0000 and finds the bootloader. It is here I need to make a decision after reading the "user flash page" flag if I need to start reading from the SPI flash and writing my App program memory area or plain just do a trampoline jump to my existing App program memory area.

Its simple! But I cant get my Avrstudio5 to program my bootloader without doing a chip erase first. I dont want to do chip erase as that will wipe my existing App program. If I try to program the bootloader without an erase first I get an error like "Verifying Flash...Failed! address=0x80000000 expected=0x48 actual=0xe0". Here the 0x48 is the first byte of the binary for Bootloader code and 0xe0 is the first byte of the trampoline for exiting App program". So obviously flashing with bootloader at 0x8000 0000 was not successful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see what is going on.... flash writing is only possible when writing from 1 to 0. And a state of 1 is a state of erased. Hence the complaining from avrstudio when it wasnt erased... sounds like I have to combine bootloader binary and program binary using srec_cat then....

unless avrstudio5 (avrprogram) allows, erasing only the first 8kb and then reprograming it with the bootloader....is that possible, I wonder.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please read http://www.atmel.com/dyn/resourc... to under stand the concept of the trampoline sections. It is only useful when you want to use the Atmel USB DFU bootloader.

When you want to program your own bootloader and application you should strip the trampoline files from the project and remove the "-e,_trampoline" linker flags. You can choose for yourself how long the bootloader is and where your application should start.

These parameter are given in the .lds files of the project. So choose 0x80000000 as start for your bootloader and 0x80000000 + bootloader_length as start for your application.

When you have bootloader and application ready you should unselect "erase device before programming" in the AVR programming Tool. Then make a manually Chip erase and then program bootloader and your application.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well i am not sure what you say about trampoline is correct... i have been following the http://www.atmel.com/dyn/resourc... and have arranged the boot and app codes according to Section 6.2.2.2. My problem was that this Avrstudio5 didnt have avr32program.exe. So I downloaded AVR32Studio in zip and then stripped the avr32program.exe from its utilities folder. Now ran it according to the above section 6.2.2.2

Its programmed the chip fine except that my bootloader keeps repeating itself (reboot)...I am printing a line on hyperterminal. My bootloader code currently only prints a string and calls they 0x80002000 location (app code) using the method recommended by clawson in earlier post.

hhm... wonder why its just rebooting!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But I cant get my Avrstudio5 to program my bootloader without doing a chip erase first. I dont want to do chip erase as that will wipe my existing App program.

You still haven't read the bootloader FAQ have you? This is the classic "problem" that affects tiny/mega/xmega bootloaders just as much as it does UC3s. The fact is that you write two completely separate programs (one bootloader (B/L) and one application (app)) but any attempt to ISP one of them and then the other fails because ISP always involves a chip erase. There are two obvious solutions:

(1) for initial programming you build bl.hex and app.hex as two separate programs then you join the two .hex files using srec_cat or even just using Notedpad and hand editing the files to remove the end of hex record at the start of the first. You now have one composite all.hex that you can program without issue.

(2) perhaps the obvious one (as you want to test that B/L as much as possible. You use ISP to put teh B/L in the chip then you use the B/L mechanism to load the app.hex (or .bin) into the application section of the flash.

Again I don't understand all this talk of trampolines (which are presumably the mechanism to make a long CALL/JMP for UC3?) Is this simply to do the:

typedef void (*f_ptr)(void);

f_ptr foo = (f_ptr)0x80002000;

foo(); 

I mentioned above? Surely the UC3 compiler uses 32bit pointers and that code just works? Why would the C programmer need to worry about constructing "trampolines"? If they are needed the C compiler would generate them "in the background". So why do you think you need to set them up yourself to get from 0x8000000 to 0x80002000. (anyway that's only 8K away - why does this even need a "long" jump?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read the FAQ :( that night....while I was trying to keep my eyes shut and hold the motorola xoom! I understood your (1) method but also wondered why couldnt we just only erase the section we want to load and not the whole chips thats all.

when I write the application prog for uc3A there is a trampoline template that comes with the framework codes....it is by default not active. I have to link it by calling the trampoline function in the linker flags. basically this allows the app prog to be compiled with the first 8KB of Zero bytes prepended. This 8KB is assumed to be bootloader section. Trampoline function therefore in theory allows you to have any jump space you want to have preprended to the app code...

so then I do the srec_cat thing using atmels cmd shell file which basically swaps in that prepended section full of zeros with the bootloader hex file and finally combines the two to come up with one file. And so far I have programmed this concatenated file...unfortunately my bootload keeps rebooting without calling my app code...

my bootloader code for now is as follows:

int main(void)
sysclk_init();
	delay_init(sysclk_get_cpu_hz());							//init the delay steps
	INTC_init_interrupts();										//Initialize interrupt vectors.
	
	Disable_global_interrupt();		// Disable all interrupts.	
	UsartInit(USART0, USART0_BAUD, PBA_FREQ, USART0_RX_PIN, USART0_TX_PIN, USART0_RX_TX_PIN_FUNC);	
	Enable_global_interrupt();		// Enable all interrupts.
	
	UsartSendString0("Boot loader Ready...\r\n");
	
	//BootFromApp();
	
	typedef void (*f_ptr)(void); 

	f_ptr foo = (f_ptr)0x80002000; 

	foo();
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeeeehhhh bootloader here I come!!!!
I got it I got it I got it!!!
So for now I get the string from bootloader main printed and then the string from the app prog main gets printed :D which means both are running!!!

I just had the end region of cropping in the cmd shell incorrect when I was cropping the app program... I had it set to 0x80008000 which is only 24KB away from...it should go till all the way of 256Kb of the chip space...and so after I corrected it, seems to be working now! Hope to get back to you guys with a summary afterwards so that other ppl working on it does it with ease...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Again I don't understand all this talk of trampolines (which are presumably the mechanism to make a long CALL/JMP for UC3?)

No the Trampoline concept is a different thing. I will explain it here, perhaps luvocean1 is reading, I have the feeling that he will not get the whole picture.

The Trampoline is some assembler code that starts at 0x80000000, makes a jmp to 0x80002000 and then a "org. 0x80002000". The idea behind it is, that when you compile your application, the resulting hex file can be used to program directly to flash (and wasting 8kb flash) or to use it with the USB DFU bootloader, that is 8kb long. When you use the USB DFU bootloader all the code before 0x80002000 (aka the small trampoline code) is skipped during the transmission.

So when you are not using the USB DFU bootloader you can simply strip off this code from your project. In fact it handicaps you when you want to freely edit the .lds file to change the start of your code. On top of it the "Select drivers from ASF" function tries to put the trampoline code back in your project every time you add a ASF driver.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok guys I now have a fully functional device!!! with remote (3G) over the air firmware upgrade facility!!! clever :D

As promised I shall give you some thing in return to all the help you guys give me...so here are some findings, in addition to what Pete said above.

Write your normal application for UC3A as you please in a new project...debug and finish this project to your hearts content first. Make sure ASF codes had added the files asf/avr32/utils/startup/trampoline_uc3.h and startup_uc3.S (assembly) to your project.

Edit the trampoline header file and make sure PROGRAM_START_OFFSET is where you want it to be. For example if you want to leave about 8K room for your bootloader then make PROGRAM_START_OFFSET 0x00002000.

No need to do anything with startup_uc3.S at this state. Go to your Project->Properties->Toolchain TAB->AVR32/GNU C Linker->Miscellaneous: here make sure you add the entry to _trampoline function ie: -Wl,-e,_trampoline,--relax. This will make sure that the when the application program runs, it jumps to the application program start location as determined above using the trampoline.

Inside your application program, where you want to load from bootloader (following a received file from 3G internet for instance) you shoul include a function call to watchdog (to reboot), e.g:

wdt_opt_t opt;
		opt.us_timeout_period = 17777;
		wdt_enable(&opt);
		while (1);

Now write you bootloader. I have used a code like bellow for my bootloader...you can make it more complex if you wish...

int main (void)
{
	//board_init();
	
	//if the cause of reset was watchdog, disable the watchdog
	if((&AVR32_PM)->rcause & AVR32_PM_RCAUSE_WDT_MASK)
	{
		wdt_disable();
	}	
	
	//initialize the system
	sysclk_init();
	INTC_init_interrupts();										//Initialize interrupt vectors.

	Disable_global_interrupt();		// Disable all interrupts.	
	UsartInit(USART0, USART0_BAUD, PBA_FREQ, USART0_RX_PIN, USART0_TX_PIN, USART0_RX_TX_PIN_FUNC);	
	Enable_global_interrupt();		// Enable all interrupts.
	
	UsartSendString0("Loading Bootloader...\r\n");
	//flashc_memset32(AVR32_FLASHC_USER_PAGE + BOOT_FORCE_OFFSET1, BOOT_FORCE_VALUE1, 4, TRUE);
	//return 0;
	
	//Test the flash user page 1, see if it was flagged by the application code
	//requesting a boot from bootloader.
	
	if(!BootFromExistingFlash())
	{
		UsartSendString0("Updating onchip flash, please wait...\r\n");
		DataFlashInit();										//enable the SPI data flash
		
		if(ExternalFlashFileOK() == OK && UpdateOnChipFlash() == OK)
			UsartSendString0("Updated onchip flash! Rebooting...\r\n");
		else
			UsartSendString0("Flash Update FAILED!\r\n");
		//reset the user page to defaults
		ResetUserFlashPage(USER_FLASH_CONFIG);
	
		//turn on the gp fuse locks?
		//SetGP_FuseLocks();
		
		//now perform a reboot. Following that application code should load.
		wdt_opt_t opt;
		opt.us_timeout_period = 17777;
		wdt_enable(&opt);
		while (1);
	}
	else
	{
		//start now from the application code	
		typedef void (*appPointer)(void); 
		appPointer app = (appPointer)PROGRAM_START_ADDRESS; 
		app();		
	}
}

For bootloader to start from the 0x80000000, the very start of the micro flash area you need to make sure that the Project->Properties->.....->Miscellenous: Has "-Wl,-e,_strart,--relax. This means that when the bootloader starts, it will not use the trampoline but instead the _start routine that comes with the ASF.

Well thats it I think...how far you want to take the rest is up to you. :)

Now we need to combine the application binary and the bootloader binary to a single file so you can program the chip first time. For this you need to have the executable avr32program (can be obtained from avrstudio32 package, for some reason not included with avrstudio5).

The command shell was modified to suit my project needs. But the original came from atmels bootloader application notes. So the copyright goes to them.

echo Performing a JTAG Chip Erase command
avr32program chiperase

echo Programming MCU memory with 'Bootloader', 'User application'
srec_cat ^
  ../BootLoader/BootLoader/Debug/BootLoader.hex -intel ^
  -crop 0x80000000 0x80002000 ^
  -offset -0x80000000 ^
  ../MyApp/MyApp/Debug/MyApp.hex -intel ^
  -crop 0x80002000 0x80040000 ^
  -offset -0x80000000 ^
  -o my_flash.bin -binary
avr32program program -finternal@0x80000000,256Kb -cxtal -v -O0x80000000 -Fbin my_flash.bin
:rm -f my_flash.bin
	
echo Programming FIRST bootloader configuration word
avr32program program -finternal@0x80000000,256Kb -cxtal -e -v -O0x808001FC -Fbin at32uc3a_boot_cfg_user_page.bin

echo Programming general-purpose fuse bits
avr32program writefuses -finternal@0x80000000,256Kb gp=0x7C07FFFF

echo Executing application
avr32program run -R

Run this script to program the chip for the first time so you can actually run the application software on chip before being able to get any future files via internet or serial or whatever means you have ready.

Goodluck and thanks soooo much to the people who have helped me (and screamed at me).[/code]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello.
I am trying to make a bootloader similar to yours.
I have done an application with a trampoline, it starts in 0x80002000.
I have done a bootloader that starts at 0x80000000.

First I program the bootloader. Then I protect the memory of the bootloader and i program the application. Everything looks right if I read the flash memory with the JTAG.

My problem is when i want to jump from the bootloader to the application. I try to do it as you say:

      //start now from the application code    
      typedef void (*appPointer)(void); 
      appPointer app = (appPointer)PROGRAM_START_ADDRESS; 
      app();      

but it doesn't work.

Could anybody help me?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It has to work. I did it exactly that way. YOu need to combine the bootload bin with your trampolined application bin into one single bin file. Use ser_cat for this. Then flash your micro with this single bin file.
You need to have the code shown above in your bootloader.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to note that you may be better off asking about this in an AVR32 forum if you cannot resolve the issue as not all AVR32 users will necessarily see an AS5/6 thread.