How does the map file work?

[Ricardo Hassan]

Greetings! I am writing a small bootloader application on an STM32L496 that will copy an image from one location in flash to another. I have reserved a 256KB chunk of flash to hold the image. I created a region and section in the .icf file, and declare a global array, located at the section, using a #pragma location tag and using the __no_init and __root keywords. When I build the app, I get the following result in the .map file:

  7 969 bytes of readonly code memory

   171 bytes of readonly data memory

 327 776 bytes of readwrite data memory

I thought, I guess incorrectly, that the readonly code and data memory sections would be in flash, and the readwrite data memory would be in RAM. However, clearly the linker thinks that the 256KB chunk is in readwrite data memory, which I explicitly put in the upper pages of flash, which I can confirm in the debugger. How should I interpret these numbers?

Thanks,

Ric

[Tesla DeLorean]

Using IAR?

Guess you're going to need to show me the .ICF and the code for the section in question.

In Keil the RAM gets initialized from two source, either a copy of statics from FLASH, or zeroed. A table in FLASH describes how the Load Region gets unpacked. There are secondary symbols that scope the memory usage, including the table, etc.

The .MAP file here should decompose various sections, and provide the addresses of assorted symbols in the final loaded product.

I don't use IAR, but expect it export symbols, and also has tools to pack and CRC firmware images. I tend to manage that as a post-link step in Keil, as I'm comfortable managing ELF and HEX files.