infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 2 of 2

Thread: Tricore 275C Memory allocation&Read question

  1. #1
    New Member New Member mnais88 is on a distinguished road
    Join Date
    Apr 2018
    Posts
    1
    Points
    15

    Tricore 275C Memory allocation&Read question

    Hi. I am having troble with memory control with my microcontroller.
    I am using
    - Microcontroller : Infineon AurixTC275C, Tricore
    - Compiler : Tasking
    Trying to figure out how to implement multi-core programming on vehicle power-train project
    So we tried to use both local memory and shared memory space for each CPU on this microcontroller
    (it has total 3cpu, each cpus stand for cpu0, cpu1, cpu2)

    In terms of memory handling, the problem is that memory is not controlled as i expect.
    for example,
    whenever I allocate space for global variable in the specific core element,
    , let me say i use below code in the cpu 1,
    the result showing that some of memory spaces are also mirror-copied other than the specific memory i initially targeted. this is extremly weird.

    #pragma data_core_association private1 // this pragma option is for coping, and accessing data from the local scratchpad memory of one particular core.

    INT8U g_u1_Cpu1_Variable;
    void core1_main(void)
    {
    g_u1_Cpu1_Variable = 0x15;
    ...
    ..
    }

    and i see these result through Trace32 debugger.
    Click image for larger version

Name:	1.jpg
Views:	0
Size:	49.0 KB
ID:	3421

    we are seeing the allocated variable and it seems ok

    Click image for larger version

Name:	C00.jpg
Views:	0
Size:	201.7 KB
ID:	3423



    it's memory address is showing that it is allocated at 0xC000 0000.
    which is fine and it is how it's supposed to be allocated since i request private allocation through TASKING Compiler pragma option. so it will allocate on local area which is 0xC000 0000

    Click image for larger version

Name:	map2.jpg
Views:	0
Size:	115.5 KB
ID:	3428
    (request allocation on private local memory space - 0xC000 0000)

    Click image for larger version

Name:	3333333.jpg
Views:	0
Size:	248.2 KB
ID:	3431
    but other memory address (0x6010 0000 / 0xC010 0000 / 0xD010 0000) is also allocated in exactly same value.
    they are also showing the same result which i guess some what weird (or is there something i am missing?)


    ※additional reference.
    =====
    Each CPU has access to its own
    1) Code Scratch memory at local address 0xC000 0000
    2) Data Scratch memory at local address 0xD000 0000
    and

    Each CPU has access to its own memory via its global segment (0x0000 0000 - 0x7000 0000),
    Data Scratch at offset 0 and Code Scratch Pad Memory at offset 0x0010 0000 (1MB).
    So if i take that global segment to each CPU, it would look like,
    0x7 CPU0 Code+Data Scratch
    0x6 CPU1 Code+Data Scratch
    0x5 CPU2 Code+Data Scratch
    ...
    0x0 CPU7 Code+Data Scratch
    (global segment is designed to use up-to 8 CPU)



    =====

    Click image for larger version

Name:	linker1.jpg
Views:	6
Size:	300.0 KB
ID:	3430
    and this is some of information on linker script file & map file


    Anyone have idea about what's wrong behind my thinking?
    Sorry my enlish is not good but i tried to make it as simple and understandable as possible.

    Thanks.

    Best Regards,
    Dongah Electric Componenet R&D Center Research Engineer, Korea
    SIHUN, LEE
    lsh9640@dongah.biz
    82-10-4902-9640
    Last edited by mnais88; Apr 15th, 2018 at 11:41 PM.

  2. #2
    Advanced Advanced HIGHTEC.henk-piet.glas is on a distinguished road
    Join Date
    May 2017
    Posts
    51
    Points
    902.5
    Hi Sihun,

    My best guess is that your memory windows for 0xC010.0000 and 0xD010.0000 are giving you a false reading, because these map to core global addresses that do no exist. If I reverse-map core global addresses to their core local equivalent, then this is the table you get:

    PSPR0: 0x7010.0000-0x7010.6000 => 0xC000.0000-0xC000.6000 (24k)
    PSPR1: 0x6010.0000-0x6010.6000 => 0xC000.0000-0xC000.6000 (24k)
    PSPR2: 0x5010.0000-0x5010.6000 => 0xC000.0000-0xC000.6000 (24k)

    DSPR0: 0x7000.0000-0x7001.C000 => 0xD000.0000-0xD001.C000 (112k)
    DSPR1: 0x6000.0000-0x6001.E000 => 0xD000.0000-0xD001.E000 (120k)
    DSPR2: 0x5000.0000-0x5001.E000 => 0xD000.0000-0xD001.E000 (120k)

    If you cross-reference your memory windows for 0xC010.0000 and 0xD010.0000 against these then I conclude you're looking at non-existent memory. Could be a glitch of the memory window therefore.

    You may strengthen your findings by widening your scope of the map-file and see if it reports any data/code at local addresses 0xC010.000 and 0xD010.0000. Since these don't exist, it's unlikely that the locator will have allotted them.

    Best regards,

    Henk-Piet Glas
    Principal Technical Specialist
    HighTec EDV-Systeme GmbH
    Last edited by HIGHTEC.henk-piet.glas; Apr 16th, 2018 at 08:40 AM.

+ Reply to Thread

Tags for this Thread

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.