• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1902 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

What do Shared and Common Memory Represent in an IAR for MSP430 MAP File?

Samuel
Intellectual 2360 points
Other Parts Discussed in Thread: MSP430F5229

Note this question is related to, but more specific than:

IAR Map File

IAR Map file Interpretation

In the Module Summary section of my MAP file I see the following:

MOD1                    338      1     16
  + shared              116             2
  + common
MOD2                    898     14              2
MOD3                 20 264      8              8
MOD4                  2 062    125     73      76
  + shared              108             6
  + common
MOD5                  1 586    230      6       2
  + common              114

My question is, what do the shared and common designations represent? I can see from the Module Map above the Module Summary section that these sections represent ISR functions, and that each function has the same start address of FF80. However, and oddly, each function has a different size despite having the same start address. From the MAP file:

INTVEC
  Common segment, address: FF80 - FFF3 (0x74 bytes), align: 1 // 116 bytes in MOD1

INTVEC
  Common segment, address: FF80 - FFF1 (0x72 bytes), align: 1 // 114 bytes in MOD5

How is it possible for these ISRs to share the same address space and have different sizes?

I'm using an MSP430F5229.

  • 0
    Expert 2070 points

    The "shared" parts refers to located variables. For all practical purposes, this is the peripheral units (also known as special function registers (sfr:s)). Typically, you can ignore these as they don't occupy any space in normal data areas.

    The "common" part refers to entries in an interrupt vector table. When you compile a function like:

    #pragma vector=10
__interrupt void f(void)
{
}

    The IAR compiler will generate code for the function and it will generate an entry in the interrupt vector table. The entry looks like the following:

            COMMON INTVEC:CONST:ROOT(1)
        ORG 10
`??f::??INTVEC 10`:
        DC16    f

    The above mean that on offset 10, in the "common" segment INTVEC, two bytes of data is inserted. "common" segments are used for things like the interrupt vector table, as the linker is allowed to join small parts that comes from different object files (as long as they don't overlap).

    The linker map file, however, reports the full size of this segment, counting from the beginning (offset 0) to the end of the data (in this case 10+2). Hence, it will report this as having the size 12. Of course, once you have linked the different modules together, the size of the interrupt vector table will be the combined size, in your case 0x74 bytes. Again, this does not steal any space from your flash, as you can typically not place generic data or code in the interrupt vector table anyway.

    (Note that the RESET vector is handled differently, to allow the same cstartup code to be used together with devices with interrupt vector tables of different sizes.)

        -- Anders Lindgren, IAR Systems, Author of the IAR compiler for MSP430

  • 0 in reply to Anders Lindgren
    TI__Intellectual 2360 points

    Anders,

    Thank you for the detailed explanation. I understand the common area now, but I'm still missing something on the shared area.

    You said that, "The "shared" parts refers to located variables. For all practical purposes, this is the peripheral units (also known as special function registers (sfr:s))." The shared part is occupying a code segment, however, not a data segment.

    Here is the extended snippet of my module summary:

    Module                 CODE      DATA       CONST
    ------                 ----      ----       -----
                          (Rel)  (Rel)  (Abs)   (Rel)
    ...
    MOD1                    338      1     16
      + shared              116             2
      + common
    MOD2                    898     14              2
    MOD3                 20 264      8              8
    MOD4                  2 062    125     73      76
      + shared              108             6
      + common
    MOD5                  1 586    230      6       2
      + common              114
    ...
    ----------          -------  -----    ---  ------
    Total:              119 352  8 190    103  11 408
      + common              116

    I thought that using an SFR added to the data absolute area, for example 16, 2, 73, 6, and 6 above. Is that not correct?

    Thanks,
    Samuel

  • 0 in reply to Samuel
    Guru 14640 points

    Samuel:

    One very useful feature in the IAR Tools is checking "Module summary" in the Linker--> List (and of course, "Generate linker listing" which I am sure you have already done).

    Module summary gives 3 lines of very useful info: #of bytes of CODE, # of bytes of DATA, # of bytes of CONST.

  • 0 in reply to Samuel
    Expert 2070 points

    Samuel said:


    Thank you for the detailed explanation. I understand the common area now, but I'm still missing something on the shared area.

    You said that, "The "shared" parts refers to located variables. For all practical purposes, this is the peripheral units (also known as special function registers (sfr:s))." The shared part is occupying a code segment, however, not a data segment.

    Here is the extended snippet of my module summary:

    Module                 CODE      DATA       CONST
    ------                 ----      ----       -----
                          (Rel)  (Rel)  (Abs)   (Rel)
    ...
    MOD1                    338      1     16
      + shared              116             2
      + common
    MOD2                    898     14              2
    MOD3                 20 264      8              8
    MOD4                  2 062    125     73      76
      + shared              108             6
      + common
    MOD5                  1 586    230      6       2
      + common              114
    ...
    ----------          -------  -----    ---  ------
    Total:              119 352  8 190    103  11 408
      + common              116

    I thought that using an SFR added to the data absolute area, for example 16, 2, 73, 6, and 6 above. Is that not correct?

    After digging into this a little bit more I realized that "shared" is also used for (C++-style) inlined functions. Whenever a module sees an inlined function it generates code for it, the linker includes one of the generated versions in the final application.

    I haven't seen "common" being used by code, though.

        -- Anders Lindgren, IAR Systems

  • 0 in reply to Anders Lindgren
    TI__Intellectual 2360 points

    Anders,


    I don't have any explicit inline functions and the compiler is configured for C. The "C++ inline semantics" option is unchecked. I looked at the specific ISRs that are allocated for the shared and common memory. Here are my findings:

    1. MOD1, 116 bytes shared, watchdog timer interrupt at offset WDT_VECTOR (114) in INTVEC.

    2. MOD4, 108 bytes shared, timer interrupt at offset TIMER0_A0_VECTOR (106). Note that there are other interrupts in MOD4 but this interrupt has a higher offset in the interrupt vector table than the other interrupts in the module. The summary only shows the max, as it should.

    3. MOD5, 114 bytes common, UART interrupt at offset USCI_A0_VECTOR (112) in INTVEC.

    Your first explanation of the common section makes sense for both the shared and common sections from what I'm seeing. Not sure what the differences are still.

    Can you confirm my question about the SFR accesses using absolute data memory? "I thought that using an SFR added to the data absolute area, for example 16, 2, 73, 6, and 6 above. Is that not correct?" This has been asked in another thread and there is no definite answer there (IAR Map File).

    My IAR compiler version is 6.10.5.

    These numbers are from an MSP430F5229.

    Samuel

  • 0 in reply to Samuel
    Expert 2070 points

    Congratulations, it looks like you found a (minor) bug in XLINK -- whenever a module contains both shared and common objects, they are both printed in the "shared" column in the module summary. (Our XLINK guy said that if you ever happened to find yourself in Uppsala, Sweden, he would buy you a soft drink.)

    The correct output should be that MOD1, MOD4, and MOD5 their interrupt vectors in the common segment and place peripheral units in shared segments.

    Samuel said:

    Can you confirm my question about the SFR accesses using absolute data memory? "I thought that using an SFR added to the data absolute area, for example 16, 2, 73, 6, and 6 above. Is that not correct?" This has been asked in another thread and there is no definite answer there (IAR Map File).

    Yes, I can confirm this. Whenever you access a memory-mapped peripheral unit, this is reported as an absolutely placed data object by XLINK.

        -- Anders Lindgren, IAR Systems

  • 0 in reply to Anders Lindgren
    TI__Intellectual 2360 points

    Anders,

    Thanks for confirming!

    Glad I could help with the XLINK testing. Looks like I might have to make a trip to Sweden!

    Thanks,
    Samuel

**Attention** This is a public forum