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.

Memorymap question - .text section is modified during the program running?

Hello,

I'm working with a multicore program on EVMC6678L using IPC, and met a strange behavior.

My understanding is ".text" section contains 'executable code and constants' only according to 5.3.5 of SPRU187T document.

So, if the same program runs on all the core, the contents of ".text" section for each core are the same.

Then I mapped ".text" section to MSMCSRAM to share code/data.

But the program behaves strangely.


You can re-produce using IPC message example.

1. Comment out 'BIOS_start()' in main() function in message_multicore.c to simplify the problem.

2. Add 'Program.sectMap[".text"] = "MSMCSRAM";' to message_multicore.cfg.

3. Build the project

4. In debug perspective, group all the 8 cores and load the program on the group.

5. 'Resume (F8)' on the group.

6. All cores aborts, and produce messages like below in Console window.

[C66xx_6] Exiting program (6)
[C66xx_0] Exiting program (0)
[C66xx_1] Exiting program (1)
[C66xx_2] Exiting program (2)
[C66xx_3] Exiting program (3)
[C66xx_4] Exiting program (4)
[C66xx_5] Exiting program (5)
[C66xx_7] Exiting program (7)

7. 'Restart' on the group.

8. 'Resume (F8)' on the group.

9. Some core(s) are in 'Running' state, but others are in 'Suspended' state.


Why?

If the contents of the ".text" section are the same among all cores, and is not modified,

The program might run like the step 6.  Is ".text" section modified during the program running?


PS. I found the example (image_processing) shares ".text" section among slave cores (7 cores).

 

  • You may be hitting breakpoint corruption due to the behavior of CCS during debug.

    In the TI Wiki Pages, there is an article that discusses different ways to use and partition memory for multicore devices Using DSP/BIOS on Multi-Core DSP Devices. The first page shows an overview of different ways to allocate memory and to share memory. About 40% down the page is a link to the section for Single Application on Multiple Cores. That section describes the easiest way to share the same program image without physically sharing the program code, and then it discusses problems with alternate methods such as moving the loaded program image to Shared Memory, including breakpoint corruption.

    This article is written for CCSv4 and DSP/BIOS 5.41 and the C6472, but some of the issues will be identical to what you will face on your project. Please reply back with any comments on the article, or reply back with further questions if this does not help.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • Thanks, RandyP!

    I must be hitting breakpoint corruption.

    Then, what sections should be mapped to Local/Shared section, in practice?

    When I use XDC Tools 3.22.02.27, and C6678 and create a single-image for multicore, all sections which are automatically created may be below
    according to XDCTools help (C66.sectMap) and 5.3.5 of SPRU187T.

    Is this correct?

    Sections mapped to Local Memory Segment

    .text    (for debugging)
    .stack
    .bss
    .neardata
    .fardata
    .system
    .far
    .args
    .cio
    .ppdata
    .ppinfo

    Sections mapped to Shared Memory Segment

    .cinit
    .pinit
    .init_array
    .const
    .rodata
    .switch
    .c6xabi.exidx
    .c6xabi.extab

    Sections which memory segment I cannot know mapped to...

    .ti.decompress
    .data
    .switch
    .ti.handler_table
    .binit

    TIA,
    Hideo NORO

  • Hideo,

    When running a single image on multiple cores the general rule should be that any code or constant data should be placed into shared memory.  Any data that may change should be placed into Local memory.

    Typically .text should be in shared memory but I understand that for debugging you need it in local memory so that setting breakpoints in 1 core does not affect the other cores.

    Judah