• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1569 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/TM4C1294KCPDT: Map file shows static const in RAM section (.bss)

Abhijit Acharekar
Intellectual 650 points

Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Dear SupportTeam,

I have below declaration in my Test.c

static const int myHelp[100];

In map file, it appears inside .bss section

.bss 0 20000360 00000f7c UNINITIALIZED

20000360 00000400 (.common:ti_sysbios_heaps_HeapMem_Instance_State_0_buf__A)
20000760 00000360 (.common:ti_sysbios_family_arm_m3_Hwi_dispatchTable)
20000ac0 00000200 empty_pem4f.oem4f (.bss:taskStackSection)
20000cc0 00000200 (.common:task0Stack)
20000ec0 00000190 Test.obj (.bss:myHelp)

 

I thought it would consume FLASH memory. Why not?

Thanks & Regards

Abhijit

  • 0
    TI__Guru 72500 points
    What version of the compiler are you using? When I tried with version 18.1.4, it put the array in the .const section where it would be in flash.
  • 0 in reply to Bob Crosby
    Intellectual 650 points
    Hi Bob,
    Thank you for your response. I am using "ti-cgt-arm_18.1.4.LTS"; I believe it is same as yours.
    Do we need to do any other configuration?
    Thanks & Regards
    Abhijit
  • 0 in reply to Abhijit Acharekar
    Intellectual 650 points

    Hi Bob,

    Today, I initialized static const and then found it in .const section. I don't understand this constraint.

    I also see some issues in .map file.

    1)

    in attached map file (event_EK_TM4C1294XL_TI_global_array.map), I have global array; int myTest[4] = {100, 101, 102, 103};

    The bold # don't match

    From event_EK_TM4C1294XL_TI_global_array.map -->

    MEMORY CONFIGURATION

           name            origin    length      used     unused   attr    fill

    ----------------------  --------  ---------  --------  --------  ----  --------

    FLASH                 00000000   00100000  00007087  000f8f79  R  X

    SRAM                  20000000   00040000  00001c9c  0003e364  RW X

    SEGMENT ALLOCATION MAP

    run origin  load origin   length   init length attrs members

    ----------  ----------- ---------- ----------- ----- -------

    00000000    00000000    00007090   00007090    r-x

    00000000    00000000    0000003c   0000003c    r-- .resetVecs

    00000040    00000040    00004dca   00004dca    r-x .text

    00004e0c    00004e0c    00002071   00002071    r-- .const

    00006e80    00006e80    00000210   00000210    r-- .cinit

    20000000    20000000    00001ca0   00000000    rw-

    20000000    20000000    00000360   00000000    rw- .vecs

    20000360    20000360    00001220   00000000    rw- .bss

    20001580    20001580    0000041c   00000000    rw- .data

    200019a0    200019a0    00000300   00000000    rw- .stack

    --------------------------------------------------------------------------

    Now I made my array const

    MEMORY CONFIGURATION

    name origin length used unused attr fill

    ---------------------- -------- --------- -------- -------- ---- --------

    FLASH 00000000 00100000 00007087 000f8f79 R X

    SRAM 20000000 00040000 00001c8c 0003e374 RW X

    SEGMENT ALLOCATION MAP

    run origin load origin length init length attrs members

    ---------- ----------- ---------- ----------- ----- -------

    00000000 00000000 00007090 00007090 r-x

    00000000 00000000 0000003c 0000003c r-- .resetVecs

    00000040 00000040 00004dca 00004dca r-x .text

    00004e0c 00004e0c 00002081 00002081 r-- .const ----> This is correct; if I compare to previous map

    00006e90 00006e90 00000200 00000200 r-- .cinit

    20000000 20000000 00001c90 00000000 rw-

    20000000 20000000 00000360 00000000 rw- .vecs

    20000360 20000360 00001220 00000000 rw- .bss

    20001580 20001580 0000040c 00000000 rw- .data ---> This is correct; if I compare to previous map

    20001990 20001990 00000300 00000000 rw- .stack

    2) if you check the map file; why .data has "UNINITIALIZED" label?

    .data      0    20001580    0000040c     UNINITIALIZED

    Somehow, I could not attach map files. Please let me know if you find similar issues.

    Thanks & Regards

    Abhijit

  • 0 in reply to Abhijit Acharekar
    TI__Guru 72500 points
    Yes, to be put in the .const section, and then subsequently programmed into flash, the const array must be initialized. Why would you not initialize a const array? An uninitialized const array does not make sense to me.
  • 0 in reply to Bob Crosby
    Intellectual 650 points
    Hi Bob, yes, you are right. it makes no sense not to initialize const array.
    BTW, did you happen to see the discrepancy in map file that I observed.
    Thanks & Regards
    Abhijit
  • 0 in reply to Abhijit Acharekar
    TI__Guru 72500 points
    Sorry, what discrepancy in the map file? Are you asking why the .data section is uninitialized? In the ROM model, the static and global variables are initialized by code that runs before calling main using the values stored in the .cinit section. They are not initialized by the loader. In other words, in the ROM based model all sections that point to RAM should be uninitialized sections because on power-on, the RAM comes up random.
  • 0 in reply to Bob Crosby
    Intellectual 650 points

    Hi Bob,

    Thank you for your response.

    W.r.t. my question  - "why .data has "UNINITIALIZED" label?", if you see everywhere, data segment is also referred as "Initialized data segment".  That's the confusion when I see "UNINITIALIZED" word next to .data in map file.

    Regarding discrepancy in the map file; I understood your clarification. Now we just focus on memory calculation irrespective of the code.

    name            origin    length      used     unused   attr    fill

    ----------------------  --------  ---------  --------  --------  ----  --------

    FLASH                 00000000   00100000  00007087  000f8f79  R  X

    SRAM                  20000000   00040000  00001c9c  0003e364  RW X

    SEGMENT ALLOCATION MAP

    run origin  load origin   length   init length attrs members

    ----------  ----------- ---------- ----------- ----- -------

    00000000    00000000    00007090   00007090    r-x

    00000000    00000000    0000003c   0000003c    r-- .resetVecs

    00000040    00000040    00004dca   00004dca    r-x .text

    00004e0c    00004e0c    00002071   00002071    r-- .const

    00006e80    00006e80    00000210   00000210    r-- .cinit

     

     

    20000000    20000000    00001ca0   00000000    rw-

    20000000    20000000    00000360   00000000    rw- .vecs

    20000360    20000360    00001220   00000000    rw- .bss

    20001580    20001580    0000041c   00000000    rw- .data

    200019a0    200019a0    00000300   00000000    rw- .stack

     

    --------------------------------------------------------------------------------------

    FLASH memory calculation

    3c+4dca+2071+210 = 7087 - This # matches to summary(FLASH) table and doesn't match to table below it.

     

    similarly for SRAM

    360+1220+41c+300 = 1c9c

    Do you see what I saw? Is this expected?

    Thanks & Regards

    Abhijit

     

     

     

  • 0 in reply to Abhijit Acharekar
    TI__Guru 72500 points
    The .data section is listed as "uninitialized" in the .map file because it is composed only of uninitialized input sections.

    The difference between the amount of memory used at the top of the .map file and the length of the segment allocation map is due to holes in the space. The holes are created by the alignment of each section. (The default is 4 bytes.) Also a hole is created by binding the .text section to address 0x40. That leaves a 4 byte hole after the 0x3C of the .resetVecs section.
  • 0 in reply to Bob Crosby
    Intellectual 650 points

    Thank you for your clarification.