How to control whether program is placed into BOOT, APPCODE, or APPDATA section

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

I'm working on a firmware for AVR128DA. This MCU has 3 flash memory sections: BOOT, APPCODE and APPDATA. I understand that these sections have user-defined size through fuses.

I don't really understand though, how do I control where the program or my progmem data is placed (inside a C/C++ project). Also, how does the compiler know where to place (or upload) the machine code if the size is variable (defined in fuse)?

To explain my end goal, I want to add a bootloader to support re-programming either the APPCODE section, where the main program is stored, or just the APPDATA section (leaving APPCODE intact), which contains (does it by default? Again, how does AVR-GCC treat this?) my PROGMEM variables (strings, bitmaps, and other misc data). Assuming that all the PROGMEM data should be already inside .data section, does it just place the .data section inside the APPDATA memory section automatically? If so, again, how does it know where it starts? Same question stands for the BOOT/APPCODE boundary. How does the compiler know where BOOT ends and APPCODE starts and how do I control what gets placed inside which section?

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

With a Harvard architecture that AVR RISC CPUs have, the APPDATA is static RAM and the APPCODE is flash memory.  BOOT is also flash, but it is above the APPCODE in a reserved section that contains the bootloader for this AVR varient.  PROGMEM has constants that are stored in the flash memory.

 

This is confusing because C and C++ were developed for computers (initially mainframes, then PCs) that do everything in static RAM.  The C compiled program would have sections defined in C parlance as .data and .code and .heap, but these would all be in the RAM of the main computer.

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

Simonetta wrote:
BOOT is also flash, but it is above the APPCODE in a reserved section

IIRC, on the Dx AVR's, the boot section is first, followed by the APPCODE, followed by APPDATA.

As for how the compiler knows where to place things, I believe that info is on the device specific headers, but you will need to wait for a freak with more GCC know how for specifics.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

APPDATA is static RAM

This is not true, APPDATA is a section in flash in AVR128 (see page 72 in datasheet or here).

I understand the basics about Harvard architecture and how it does not map to the C/C++ programming style, or how PROGMEM variables work. What I'm asking is how do I control it in a C/C++ project - how do I choose which part is placed in which section and how the sections actually map to the physical addresses in flash.

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


Fuse settings and linker settings are required.

I've only done it at Microchip studio.

 

#include <avr/io.h>

////////////////////////////////////////////////////////////////
// Fuses
////////////////////////////////////////////////////////////////
FUSES = {
    .WDTCFG     = FUSE_WDTCFG_DEFAULT,
    .BODCFG     = FUSE_BODCFG_DEFAULT,
    .OSCCFG     = FUSE_OSCCFG_DEFAULT,
    .SYSCFG0    = FUSE_SYSCFG0_DEFAULT,
    .SYSCFG1    = FUSE_SYSCFG1_DEFAULT,
    .CODESIZE   = 0x10, /* 8KB */
    .BOOTSIZE   = 0
};

#ifdef Release
LOCKBITS = LOCK_KEY_RWLOCK_gc;      // Program access lock
#endif

////////////////////////////////////////////////////////////////
// APPDATA
////////////////////////////////////////////////////////////////
static const uint8_t __attribute__ ((section (".my_appdata"))) my_data[] = {
    0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
};

////////////////////////////////////////////////////////////////
// APPCODE
////////////////////////////////////////////////////////////////
int main(void){
    while (1)
    {
    }
}

I'm in trouble.

Recently, there is a problem that images cannot be pasted here.

 

[Moderator: this is curious - I just opened your attachment in another tab, right clicked and used "copy image" and then paste to get:]

[I'm using Chrome on Win10]

Attachment(s): 

Last Edited: Fri. May 7, 2021 - 09:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, this is very helpful.

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

Do note the comment in that Memory Settings dialog if you are using Studio 7. Basically it says that if you enter anything under "FLASH segment" the value you use should be a "WORD" not a "BYTE address". So if you want to set a section start for .foo to byte address 0xBC00 you would actually enter ".foo=0x5E00" as you divide a byte address by two to make it into a word address. Rather curiously Studio 7 then takes what you enters here and doubles it so during the build you will see "-Wl,-section-start=.foo=0xBC00" in the output which is back to where you wanted to be in the first place!

 

(this is historical and stems from the fact that the finest granularity in AVR code flash are 16 bit word locations so they count the locations 0, 1, 2, 3 even though the actual byte addresses are 0, 2, 4, 6 ... - very confusing. The world works better if everyone just addresses all memory as bytes (which is what the GCC toolchain chooses to do)).