Tricore 275C Memory allocation&Read question

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
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.
3082.attach

we are seeing the allocated variable and it seems ok

3084.attach



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

3088.attach
(request allocation on private local memory space - 0xC000 0000)

3091.attach
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)



=====

3090.attach
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
0 Likes
1 Reply
User13290
Level 5
Level 5
First like received First solution authored
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
0 Likes