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.

Compiler/LINUXSDK-OMAPL138: functions using switch…case & Memory map

Part Number: LINUXSDK-OMAPL138


Tool/software: TI C/C++ Compiler

Hello, 

We have a product based on the dual core OMAP L138 System-on-Chip (SoC) part from Texas Instruments 10 years ago. Now we found a problem seems related to the compiler and link.

 

We have some functions using switch…case, in the link command file,

It defined the memory map:

/* Memory map */

MEMORY

{

    VECTORS    o = 000800000h          l = 00000500h

    PCONSTACK: o = 000800500h          l = 00002000h

    RAM:       o = 000802500h          l = 0003db00h

    BBRAM:     o = PSM_BBRAM_ADDRESS   l = PSM_BBRAM_SIZE

    FLASH:     o = PSM_FLASH_ADDRESS   l = PSM_FLASH_SIZE

    BMEM:      o = PSM_DSP_RAM_ADDRESS l = PSM_DSP_RAM_SIZE

}

And .fastcode, .fastdata, they should be in RAM, but the space is not enough, so some switch will stay at BMEM

 

  .switch: >> RAM | BMEM

 

Then it defined the BMEM other sections:

 

   GROUP

   {

    sect_im: {}

    im_hisr: {}

    .data:   {}

    sect_str:{}

    sect_att:{}

………………….

        .sysmem:  palign(8)

        {

            _HEAP_START = . ;

            *(.sysmem)

        }

        .sysmemend: palign(8)

        {

            _HEAP_END = . ;

        }

      } > BMEM

 

But when we look at the generated map file, we can find that most part of the switch is in RAM, some part of the switch is behind .sysmemend

.switch.1   (RAM)

*          0    0083f5a0    00000a5c    

                  0083f5a0    0000013c     courier.lib : route.obj (.switch:_route_InterpretCourierCommand)

                  0083f6dc    000000fc     uix.obj (.switch:_uiX_MultiPageFaultDisplay)

                  0083f7d8    000000a4     courier.lib : cr_snprintf.obj (.switch:_courier_snprintf) 

 

 

.sysmem    0    c2b24b68    0000c000    

                  c2b24b68    00000008     rts6740.lib : memory.obj (.sysmem) [fill = 00000000]

                  c2b24b70    0000bff8     --HOLE-- [fill = 00000000]

 

.sysmemend

*          0    c2b30b68    00000000     UNINITIALIZED

 

.switch.2  (BMEM)

*          0    c2b30b80    000000e0    

                  c2b30b80    00000010     curmfnx.obj (.switch:_curmf_SETTING_vis_Range_OR)

                  c2b30b90    00000010     curmfnx.obj (.switch:_curmf_SETTING_vis_Range_OR_AND)

                  c2b30ba0    00000010     modbus.lib : event.obj (.switch:_modbus_BuildTxEvent)

                  c2b30bb0    00000010     smmx.obj (.switch:_msfX_DownloadComplete)

 

During the test, the area after c2b30b80 is inaccessible!  I did some change to put all switch in BMEM but before sysmem and sysmemend. All functions work fine!

But since the switch section has to be divided in to two parts, how to set only one part in BMEM before the sysmem?

 

I am not very clear about the compiler, link and the meaning of sysmem and sysmemend. Can you help to advise please?

Many thanks 

Linda

  • This line ...

    Linda Igboanugo said:
      .switch: >> RAM | BMEM

    ... means the .switch section may be split into pieces.  And any of those pieces may appear anywhere in the memory range RAM or BMEM.  Thus, the linker has worked correctly.

    Linda Igboanugo said:
    During the test, the area after c2b30b80 is inaccessible!

    I lack the expertise to explain why that occurs.

    Linda Igboanugo said:
    But since the switch section has to be divided in to two parts, how to set only one part in BMEM before the sysmem?

    I cannot test this idea to be sure it works.  But it is easy enough for you to try this experiment.  Please search the C6000 assembly tools manual for the sub-chapter titled Controlling Placement Using The HIGH Location Specifier.  Apply the high specifier to the GROUP.  Please let me know if this idea resolves the problem.

    Thanks and regards,

    -George