How to place a bootloader in AVR flash memory?

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

I'm writing a set of bootloaders that we'll use for some boards.  The MCU's used are ATmega128 and AT90PWM316, and the IDE is Atmel Studio 7.

And I'm struggling with placing the flash at the correct place in the memory.

The BL size on ATmega128 will be 4k, while the BL size on AT90PWM316 will be 2k.

I.e. the ATmega128 BL will be placed starting at flash memory address 0x1F000, and the AT90PWM316 BL will be placed starting at flash memory address 0x3800.

How do I configure the toolchain in the projects in AS7 to achieve this, and also have the AS7 check the BL size when building (to keep HEX/ELF file from overflowing)?

 

So far I've been using "-Ttext=0x1F000" in Toolchain>AVR/GNU Linker>Miscellaneous>Other Linker Flags.  And this works for placing the HEX/ELF file in the flash memory.

And it also works for checking flash memory usage on ATmega128.  But when setting "-Ttext=03800" on in the AT90PWM316 project, it *does* set the memory location correctly.

But it's not checking flash memory usage correctly.  Currently my build size is a little above 2k, which will cause an overflow in the flash memory (I can see it from the memory locations in the HEX file).

But it's building fine.  But if I set it to "-Ttext=0x1F800", it fails saying it overflows a hundred bytes or so (indicating the memory size is 128k and not 16k).

And yes, the device is set correctly under Device.

 

How do I do this correctly?

This topic has a solution.
Last Edited: Wed. Mar 8, 2017 - 06:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bassmus wrote:
But when setting "-Ttext=03800"
Unless you simply typed that wrong that's because 03800 is not 0x3800

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

clawson wrote:

Bassmus wrote:
But when setting "-Ttext=03800"
Unless you simply typed that wrong that's because 03800 is not 0x3800

No, I'm afraid that was a typo in my post.  I have used "-Ttext=0x3800" in AS7.

 

But is this the correct way to do this?  I've found references to the FLASH segment section, and people using entries like ".boot=0x3800" or similar.  But that hasn't worked.  Or at least, I can't see any difference in the addressing in the HEX file.

 

The weird thing about using "-Ttext=0x3800" on AT90PWM316 with a code slightly larger than 2k, is that I can see the HEX file overflowing.  I.e. addresses in the range 0x4nnn being written to.  It's only when I set e.g. "-Ttext=0x1F800" that I get errors reported from AS7 about the code not fitting the "text" region.  So AS7 thinks the AT90PMW316 has 128k memory, for some reason.  It *is* possible that this project is based on a project with ATmega128 as the target device.  But I can't find any other references to device or memory size in the project settings that's not set correctly (to my knowledge)..

 

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

he MCU's used are ATmega128

Off topic but if a new product why use an OLD chip?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

he MCU's used are ATmega128

Off topic but if a new product why use an OLD chip?

Heheh..  It's an OLD product made by OLD guys. :-)  Which is now fitted with a bootloader.

But you've got a valid point.  Do you have a more up-to-date MCU in mind, with >=128k flash memory, 2 USART's, and plenty of GPIO's?

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

Bassmus wrote:
Do you have a more up-to-date MCU in mind, with >=128k flash memory, 2 USART's, and plenty of GPIO's?

Mega1284

 

If you need more then look at the MEga2560 as it has 256k Flash,  4 USARTS and PLENTY of GPIO along with a nice collection of peripherals

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Tue. Mar 7, 2017 - 09:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ATmega1281/2561 are pin compatible with the Mega128 and you even get an extra pin (pin1) which was actually never used in the M128.

 

You will need to recompile and maybe do some small changes to the code (ie do something with pin 1, some register names may change etc.)  but it should be quite painless.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

What you are attempting with -Ttext= is exactly the way to go about this. Check the hex to see final addressing generated.

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

clawson wrote:
What you are attempting with -Ttext= is exactly the way to go about this. Check the hex to see final addressing generated.

Thanks for the confirmation.  Setting -Ttext=0x3800 works fine.  The only problem is that I have to keep watch that the build size is not larger than 2048 bytes.

I hoped I could define an upper limit for this.  Or better yet, that AS7 figured out itself that the program was too large by itself, given memory start location at 0x3800 and that the selected device has memory size 16k.

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

jgmdesign wrote:

Mega1284 - If you need more then look at the MEga2560 as it has 256k Flash,  4 USARTS and PLENTY of GPIO along with a nice collection of peripherals

 

js wrote:

The ATmega1281/2561 are pin compatible with the Mega128 and you even get an extra pin (pin1) which was actually never used in the M128.

 

Thanks for the tips!  Will keep them in mind next time the boards gets redesigned. :-)

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

Bassmus wrote:
Setting -Ttext=0x3800 works fine.
Then I'm lost. I thought this whole thread was about the fact that you were already using -Text=0x3800 and it was NOT working. So what changed?

 

As for setting a size limit. You can fake this. When GCC builds it uses a linker script as one of the inputs to the linker to define what goes where in the memory footprint of the device. The AVRs are grouped into 17 categories of "similar architecture" and it then uses one of 17 scripts when building for one of the 300+ models of AVR. For example the pwm316 is in architecture "avr5" (you can tell this by getting the build to create a .map file then see which directory the crtXXX.o file is supplied from). So of all the linker scripts:

 Directory of C:\SysGCC\avr\avr\lib\ldscripts

18/08/2016  09:10             6,984 avr1.x
18/08/2016  09:10             6,989 avr2.x
18/08/2016  09:10             6,990 avr25.x
18/08/2016  09:10             6,991 avr3.x
18/08/2016  09:10             6,992 avr31.x
18/08/2016  09:10             6,991 avr35.x
18/08/2016  09:10             6,989 avr4.x
18/08/2016  09:10             6,991 avr5.x
18/08/2016  09:10             6,992 avr51.x
18/08/2016  09:10             6,992 avr6.x
18/08/2016  09:10             6,284 avrtiny.x
18/08/2016  09:10             6,994 avrxmega1.x
18/08/2016  09:10             6,994 avrxmega2.x
18/08/2016  09:10             6,994 avrxmega3.x
18/08/2016  09:10             6,994 avrxmega4.x
18/08/2016  09:10             6,994 avrxmega5.x
18/08/2016  09:10             6,994 avrxmega6.x
18/08/2016  09:10             6,994 avrxmega7.x

the one that is used from there is avr5.x. Now if you look at the top of that one you see:

C:\SysGCC\avr\avr\lib\ldscripts>head avr5.x -n 20
/* Default linker script, for normal executables */
/* Copyright (C) 2014 Free Software Foundation, Inc.
   Copying and distribution of this script, with or without modification,
   are permitted in any medium without royalty provided the copyright
   notice and this notice are preserved.  */
OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr")
OUTPUT_ARCH(avr:5)
MEMORY
{
  text   (rx)   : ORIGIN = 0, LENGTH = 128K
  data   (rw!x) : ORIGIN = 0x800060, LENGTH = 0xffa0
  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = 1K
  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = 1K
  signature (rw!x) : ORIGIN = 0x840000, LENGTH = 1K
}
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  .hash          : { *(.hash)           }

The key figure in that is the LENGTH=128K. Now you may think "but this chip does not have 128K". However avr5.x is used for about 100 models of AVR:

 Directory of C:\SysGCC\avr\avr\lib\avr5

18/08/2016  09:10            11,000 crtat90can32.o
18/08/2016  09:10            11,000 crtat90can64.o
18/08/2016  09:10             7,320 crtat90pwm161.o
18/08/2016  09:10             8,748 crtat90pwm216.o
18/08/2016  09:10             9,544 crtat90pwm316.o
18/08/2016  09:10             2,948 crtat90scr100.o
18/08/2016  09:10            11,968 crtat90usb646.o
18/08/2016  09:10            11,968 crtat90usb647.o
18/08/2016  09:10             2,852 crtat94k.o
18/08/2016  09:10            24,932 crtata5702m322.o
18/08/2016  09:10            17,884 crtata5782.o
18/08/2016  09:10             9,100 crtata5790.o
18/08/2016  09:10             9,412 crtata5790n.o
18/08/2016  09:10             7,296 crtata5795.o
18/08/2016  09:10            18,816 crtata5831.o
18/08/2016  09:10             7,296 crtata6613c.o
18/08/2016  09:10             7,296 crtata6614q.o
18/08/2016  09:10             6,472 crtatmega16.o
18/08/2016  09:10             2,196 crtatmega161.o
18/08/2016  09:10             7,272 crtatmega162.o
18/08/2016  09:10             2,064 crtatmega163.o
18/08/2016  09:10             8,160 crtatmega164a.o
18/08/2016  09:10             8,160 crtatmega164p.o
18/08/2016  09:10             8,160 crtatmega164pa.o
18/08/2016  09:10             2,240 crtatmega165.o
18/08/2016  09:10             7,384 crtatmega165a.o
18/08/2016  09:10             7,384 crtatmega165p.o
18/08/2016  09:10             7,384 crtatmega165pa.o
18/08/2016  09:10             7,296 crtatmega168.o
18/08/2016  09:10             7,300 crtatmega168a.o
18/08/2016  09:10             7,300 crtatmega168p.o
18/08/2016  09:10             7,300 crtatmega168pa.o
18/08/2016  09:10             2,284 crtatmega169.o
18/08/2016  09:10             8,516 crtatmega169a.o
18/08/2016  09:10             8,516 crtatmega169p.o
18/08/2016  09:10             8,516 crtatmega169pa.o
18/08/2016  09:10             6,472 crtatmega16a.o
18/08/2016  09:10             2,200 crtatmega16hva.o
18/08/2016  09:10             2,244 crtatmega16hva2.o
18/08/2016  09:10             7,984 crtatmega16hvb.o
18/08/2016  09:10             2,556 crtatmega16hvbrevb.o
18/08/2016  09:10            10,836 crtatmega16m1.o
18/08/2016  09:10            10,748 crtatmega16u4.o
18/08/2016  09:10             6,256 crtatmega32.o
18/08/2016  09:10             2,152 crtatmega323.o
18/08/2016  09:10             8,160 crtatmega324a.o
18/08/2016  09:10             8,160 crtatmega324p.o
18/08/2016  09:10             8,160 crtatmega324pa.o
18/08/2016  09:10             7,424 crtatmega325.o
18/08/2016  09:10             7,936 crtatmega3250.o
18/08/2016  09:10             7,936 crtatmega3250a.o
18/08/2016  09:10             7,936 crtatmega3250p.o
18/08/2016  09:10             7,936 crtatmega3250pa.o
18/08/2016  09:10             7,428 crtatmega325a.o
18/08/2016  09:10             7,428 crtatmega325p.o
18/08/2016  09:10             7,384 crtatmega325pa.o
18/08/2016  09:10             7,296 crtatmega328.o
18/08/2016  09:10             7,300 crtatmega328p.o
18/08/2016  09:10             8,512 crtatmega329.o
18/08/2016  09:10             9,244 crtatmega3290.o
18/08/2016  09:10             9,244 crtatmega3290a.o
18/08/2016  09:10             9,244 crtatmega3290p.o
18/08/2016  09:10             9,244 crtatmega3290pa.o
18/08/2016  09:10             8,516 crtatmega329a.o
18/08/2016  09:10             8,516 crtatmega329p.o
18/08/2016  09:10             8,516 crtatmega329pa.o
18/08/2016  09:10             6,256 crtatmega32a.o
18/08/2016  09:10             9,780 crtatmega32c1.o
18/08/2016  09:10             7,984 crtatmega32hvb.o
18/08/2016  09:10             2,556 crtatmega32hvbrevb.o
18/08/2016  09:10            10,836 crtatmega32m1.o
18/08/2016  09:10            11,072 crtatmega32u4.o
18/08/2016  09:10             2,948 crtatmega32u6.o
18/08/2016  09:10             2,284 crtatmega406.o
18/08/2016  09:10             8,844 crtatmega64.o
18/08/2016  09:10            12,924 crtatmega640.o
18/08/2016  09:10             7,756 crtatmega644.o
18/08/2016  09:10             8,160 crtatmega644a.o
18/08/2016  09:10             8,160 crtatmega644p.o
18/08/2016  09:10             8,160 crtatmega644pa.o
18/08/2016  09:10             4,664 crtatmega644rfr2.o
18/08/2016  09:10             7,424 crtatmega645.o
18/08/2016  09:10             7,936 crtatmega6450.o
18/08/2016  09:10             7,936 crtatmega6450a.o
18/08/2016  09:10             7,936 crtatmega6450p.o
18/08/2016  09:10             7,428 crtatmega645a.o
18/08/2016  09:10             7,428 crtatmega645p.o
18/08/2016  09:10             8,512 crtatmega649.o
18/08/2016  09:10             9,244 crtatmega6490.o
18/08/2016  09:10             9,244 crtatmega6490a.o
18/08/2016  09:10             9,244 crtatmega6490p.o
18/08/2016  09:10             8,516 crtatmega649a.o
18/08/2016  09:10             8,516 crtatmega649p.o
18/08/2016  09:10             8,844 crtatmega64a.o
18/08/2016  09:10             9,780 crtatmega64c1.o
18/08/2016  09:10             2,376 crtatmega64hve.o
18/08/2016  09:10             7,716 crtatmega64hve2.o
18/08/2016  09:10            10,836 crtatmega64m1.o
18/08/2016  09:10            20,184 crtatmega64rfr2.o
18/08/2016  09:10             1,304 crtm3000.o
             100 File(s)        799,040 bytes

and these have a range of flash sizes. So the upper limit is set to 128K so it can cater for them all. Now the ATM90PWM316 only has 16KB of flash so in theory you could edit the file and set that LENGTH= to be 16K. When you next build if you created a .text+.data section with >16K you would then get a linker error about "won't fit in section". But you don't really want to edit the "core" copy of avr5.x because now, if you later build for any of those 100 other AVRs in the avr5 group and the code size goes over 16K you would get an error.

 

But what you can do is take a local copy of avr5.x to your project directory and when you next build add "-T name_of_my_local_copy_of_avr5.x" to the linker commands (and yes, isn't it confusing that -T on its own does something entirely different to the -Ttext= you have been using!). When you use -T it says "instead of using the global .x file that is being picked because of my -mmcu= choice instead use this local one with my edits".

 

Of course you can now take this further. If your bootloader section is just 2K then nothing stops you actually editing it to be "LENGTH = 2K". Now when you build your bootloader code if it exceeds 2K the build will end with a linker error.

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

clawson wrote:

Then I'm lost. I thought this whole thread was about the fact that you were already using -Text=0x3800 and it was NOT working. So what changed?

Well, yes, it was working addressing-wise.  To quote myself in the first post:  "But when setting "-Ttext=0x3800" on in the AT90PWM316 project, it *does* set the memory location correctly.

But it's not checking flash memory usage correctly.  Currently my build size is a little above 2k, which will cause an overflow in the flash memory (I can see it from the memory locations in the HEX file).

But it's building fine.  But if I set it to "-Ttext=0x1F800", it fails saying it overflows a hundred bytes or so (indicating the memory size is 128k and not 16k)."

So since it was partly working (placing the data correctly in the flash, but not flagging if the build size was too large), I was very curious if I was doing it correctly.

 

clawson wrote:

(...) The key figure in that is the LENGTH=128K. Now you may think "but this chip does not have 128K". However avr5.x is used for about 100 models of AVR: (...)

Ah, there it is!  Thanks a lot for this information!

 

clawson wrote:

Of course you can now take this further. If your bootloader section is just 2K then nothing stops you actually editing it to be "LENGTH = 2K". Now when you build your bootloader code if it exceeds 2K the build will end with a linker error.

That's not a bad idea.  I see that it does fail to actually program the chip when the build size exceeds (0x3800 +) 2k, but having the build fail would be better, I think.