This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PM: .map file and RAM/ROM management

Part Number: TM4C123GH6PM

Hello!

So I was working on a project and I want to use the remained chunk of ram as backup storage for data representing electrical behavior in an IOT device I'm making. 

following the next part is just to illustrate my question : 

Stack_Size      EQU     0x00007830

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   Stack_Size
__initial_sp


; <h> Heap Configuration
;   <o>  Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
; </h>

Heap_Size       EQU     0x000007D0

                AREA    HEAP, NOINIT, READWRITE, ALIGN=3
__heap_base

#include <stdio.h>
 int x=5; 
void SystemInit(void)
 { } 
int main(void) 
{ 
char d=5;
 } 

Program Size: Code=532 RO-data=636 RW-data=0 ZI-data=32864

so I wanted to use everything available with the ram so in start up file I allocat3d ( 30768 byte in stack (0x7830) ... 2000 byte in Heap (0x7D0) ) 
1- first question is this the way to tell the compiler that I can use the 32k ram??


2-then why is the RW-data =0? I already defined and initiated a local and a global variables here which is supposed to be saved in the stack right? and RW-data represents the data in RAM right? 


3- if I allocate 0 stack and 0 heap in startup file i still see +500 byte ZI data where do they come from? and how could ZI data in the example exceed the vaslue of 32768 which is the total capacity of RAM ? maybe the compiler Zero initialize some data in the Flash ROM? 
basically how to know what data represents the RAM and what data represents the ROM? I know that Code is saved in ROM, RO-data is also saved in ROM, RW-data all saved in RAM, ZI-data could be saved in both I think. also in the map file I saw this

<strong>" Total RW  Size (RW Data + ZI Data)             32864 (  32.09kB)" </strong>


4-so it means maybe RW data could be saved in the flash? and how could RW data exceed 32kB when I declared only 2 variables and didn't allocate extra ram in startup file? 


in the next figure : 

<strong>Memory Map of the image

  Image Entry point : 0x000002ed

  Load Region LR_1 (Base: 0x00000000, Size: 0x00000490, Max: 0xffffffff, ABSOLUTE)

    Execution Region ER_RO (Base: 0x00000000, Size: 0x00000490, Max: 0xffffffff, ABSOLUTE)

    Base Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x00000000   0x0000026c   Data   RO            3    RESET               startup_tm4c123.o
    0x0000026c   0x00000008   Code   RO           34  * !!!main             c_w.l(__main.o)
    0x00000274   0x00000034   Code   RO          188    !!!scatter          c_w.l(__scatter.o)
    0x000002a8   0x0000001c   Code   RO          190    !!handler_zi        c_w.l(__scatter_zi.o)
    0x000002c4   0x00000002   Code   RO           61    .ARM.Collect$$libinit$$00000000  c_w.l(libinit.o)
    0x000002c6   0x00000000   Code   RO           68    .ARM.Collect$$libinit$$00000002  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           71    .ARM.Collect$$libinit$$00000008  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           73    .ARM.Collect$$libinit$$0000000A  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           75    .ARM.Collect$$libinit$$0000000C  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           78    .ARM.Collect$$libinit$$0000000F  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           80    .ARM.Collect$$libinit$$00000011  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           82    .ARM.Collect$$libinit$$00000013  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           84    .ARM.Collect$$libinit$$00000015  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           86    .ARM.Collect$$libinit$$00000017  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           88    .ARM.Collect$$libinit$$00000019  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           90    .ARM.Collect$$libinit$$0000001B  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           92    .ARM.Collect$$libinit$$0000001D  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           94    .ARM.Collect$$libinit$$0000001F  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           96    .ARM.Collect$$libinit$$00000021  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO           98    .ARM.Collect$$libinit$$00000023  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO          102    .ARM.Collect$$libinit$$0000002A  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO          104    .ARM.Collect$$libinit$$0000002C  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO          106    .ARM.Collect$$libinit$$0000002E  c_w.l(libinit2.o)
    0x000002c6   0x00000000   Code   RO          108    .ARM.Collect$$libinit$$00000030  c_w.l(libinit2.o)
    0x000002c6   0x00000002   Code   RO          109    .ARM.Collect$$libinit$$00000031  c_w.l(libinit2.o)
    0x000002c8   0x00000002   Code   RO          129    .ARM.Collect$$libshutdown$$00000000  c_w.l(libshutdown.o)
    0x000002ca   0x00000000   Code   RO          143    .ARM.Collect$$libshutdown$$00000003  c_w.l(libshutdown2.o)
    0x000002ca   0x00000000   Code   RO          146    .ARM.Collect$$libshutdown$$00000006  c_w.l(libshutdown2.o)
    0x000002ca   0x00000000   Code   RO          149    .ARM.Collect$$libshutdown$$00000009  c_w.l(libshutdown2.o)
    0x000002ca   0x00000000   Code   RO          151    .ARM.Collect$$libshutdown$$0000000B  c_w.l(libshutdown2.o)
    0x000002ca   0x00000000   Code   RO          154    .ARM.Collect$$libshutdown$$0000000E  c_w.l(libshutdown2.o)
    0x000002ca   0x00000002   Code   RO          155    .ARM.Collect$$libshutdown$$0000000F  c_w.l(libshutdown2.o)
    0x000002cc   0x00000000   Code   RO           36    .ARM.Collect$$rtentry$$00000000  c_w.l(rtentry.o)
    0x000002cc   0x00000000   Code   RO           38    .ARM.Collect$$rtentry$$00000002  c_w.l(rtentry2.o)
    0x000002cc   0x00000006   Code   RO           50    .ARM.Collect$$rtentry$$00000004  c_w.l(rtentry4.o)
    0x000002d2   0x00000000   Code   RO           40    .ARM.Collect$$rtentry$$00000009  c_w.l(rtentry2.o)
    0x000002d2   0x00000004   Code   RO           41    .ARM.Collect$$rtentry$$0000000A  c_w.l(rtentry2.o)
    0x000002d6   0x00000000   Code   RO           43    .ARM.Collect$$rtentry$$0000000C  c_w.l(rtentry2.o)
    0x000002d6   0x00000008   Code   RO           44    .ARM.Collect$$rtentry$$0000000D  c_w.l(rtentry2.o)
    0x000002de   0x00000002   Code   RO           65    .ARM.Collect$$rtexit$$00000000  c_w.l(rtexit.o)
    0x000002e0   0x00000000   Code   RO          111    .ARM.Collect$$rtexit$$00000002  c_w.l(rtexit2.o)
    0x000002e0   0x00000004   Code   RO          112    .ARM.Collect$$rtexit$$00000003  c_w.l(rtexit2.o)
    0x000002e4   0x00000006   Code   RO          113    .ARM.Collect$$rtexit$$00000004  c_w.l(rtexit2.o)
    0x000002ea   0x00000002   PAD
    0x000002ec   0x00000118   Code   RO            4  * .text               startup_tm4c123.o
    0x00000404   0x00000008   Code   RO           10    .text               main.o
    0x0000040c   0x00000006   Code   RO           32    .text               c_w.l(heapauxi.o)
    0x00000412   0x0000004a   Code   RO           52    .text               c_w.l(sys_stackheap_outer.o)
    0x0000045c   0x0000000c   Code   RO           54    .text               c_w.l(exit.o)
    0x00000468   0x00000008   Code   RO           62    .text               c_w.l(libspace.o)
    0x00000470   0x0000000c   Code   RO          121    .text               c_w.l(sys_exit.o)
    0x0000047c   0x00000002   Code   RO          132    .text               c_w.l(use_no_semi.o)
    0x0000047e   0x00000000   Code   RO          134    .text               c_w.l(indicate_semi.o)
    0x0000047e   0x00000002   PAD
    0x00000480   0x00000010   Data   RO          186    Region$$Table       anon$$obj.o</strong>

As far I know, the ROM starts with 0x0 and here last used address is 0x480  and size is (0x490= 1168 bytes) which confirms the size of ROM mentioned in the last section of .map file 

so if we follow same concept here 


 
Execution Region ER_RW (Base: 0x20000000, Size: 0x00000000, Max: 0xffffffff, ABSOLUTE)

    **** No section assigned to this execution region ****


    Execution Region ER_ZI (Base: 0x20000000, Size: 0x00008060, Max: 0xffffffff, ABSOLUTE)

    Base Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x20000000   0x00000060   Zero   RW           63    .bss                c_w.l(libspace.o)
    0x20000060   0x000007d0   Zero   RW            2    HEAP                startup_tm4c123.o
    0x20000830   0x00007830   Zero   RW            1    STACK               startup_tm4c123.o

5-if RW is the size of RAM why it has 0 size even though I declared variables? and where does ER_ZI data located? they basically took bigger chunk than the available RAM as I explained above. 

6- once someone explain the RAM size here, does the total RAM size here will include those functions nested in the main functions or even if there is a function calling 5 other functions does this RAM size include all the data could possible used statically in RAM? (not talking about dynamic allocation now) because as far I know when function is over it frees the space in RAM but how will this be illustrated in the .map file?

Please I need answers for all these doubts because I can't find then online. and thanks

  • No one can help me in this?
  • Please mention which compiler and linker you are using. The output does not look like it came from the TI compiler/linker.
  • I'm using Keil man, but I think .map file has the same concept everywhere 

  • Looking at your initial post:

    You ask, "Why does RAM have (0 size)" - yet does not your paste (above) reveal a size of 0x0000.0060?        You do know/realize that MCU's SRAM starts @ 0x2000.0000 - do you not?

    To your question 6 - that's surely a valid concern - but cannot you devise a small, simple program - and develop the answer yourself?

    You note, "Inability to find online" - yet the, "How & Where online" you've searched is withheld.       Might Keil's forum prove a worthwhile site for such review - even questions?

    MAP files - among different vendors - may not prove as identical & consistent as you may hope...

  • The concept of the .map file is indeed the same, but I cannot comment on why the Keil tools report RW-data=0. I built the same simple program using the TI tools and got the following memory usage:

             name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
      FLASH                 00000000   00040000  00000538  0003fac8  R  X
      SRAM                  20000000   00008000  00000218  00007de8  RW X
    

    Of the 0x218 bytes of RAM, 0x200 is the stack and the other 0x18 bytes are from the run-time support library that supports device initialization and registration of any functions for execution upon exit. None of the RAM was allocated for the simple code you presented.

  • user5175619 said:
    I'm using Keil man, but I think .map file has the same concept everywhere 

    The concept is the same, the actual output format and terminology used is not necessarily the same.

    More to the point, the map file is an output, it does not control the link and locate process. That will be done by a different file and varies from vendor to vendor with formats that can vary widely. Locate files in particular vary a lot in their complexity and capability. Link files vary as well but not quite as widely.

    Robert