TC377 Shared variables across the cores

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

cross mob
gotthard
Level 1
Level 1
10 sign-ins 5 questions asked 5 sign-ins

Hello,

I have two questions regarding the shared variables across the cores. I am using TC377 with safeRTOS and Hightec compiler. There are two tasks running in the privileged mode on core0 and core1 and there is one global variable defined. One task should increment that variable, second task should read it. Unfortunately, they are not shared. First core is incrementing the variable but the second core sees only zero. If I take a look at map file, this is what I see:

0xd000fc18 0xd000fc1b 4 g sharedAcc0 dsram0_local .bss .bss

I assume that this should not be stored inside dsram0_local. If I add this variable to the section shared_data that goes to dsram0

__attribute__( ( section( "shared_data" ) ) ) int sharedAcc0;

Snippet from the linker script:

.SharedData : ALIGN(8) FLAGS(awl)
{
. = ALIGN( 8 );
lnkStreamBufferTestDataStart_Common = . ;
*( stream_buffer_test_data_common );
. = ALIGN( 8 );
lnkStreamBufferTestDataEnd_Common = . ;
*( shared_data );
} > dsram0

now core0 reads this variable and increments but core1 can't access it and the task is blocked. Map file shows the following:

0x70001634 0x70001637 4 g sharedAcc0 dsram0 .SharedData shared_data

What do I have to do to share the variable across the cores? I assumed dsram0 can be accessible from all cores but it does not seem like that. 

Second question is, if I am able to share the variables across the cores and all cores are writing to it and reading from it, can I use mutex (IfxCpu_acquireMutex) provided by the iLLD  to lock the resource?

Thank you in advance.

Greetings

 

0 Likes
1 Solution
µC_Wrangler
Employee
Employee
50 solutions authored 100 sign-ins 25 likes received

Hi @gotthard .  The first address was 0xd000fc18; that is local addressing, which always refers to a core's own DSPR.  That causes trouble in a multicore environment, because each CPU is referring to its own copy.

By default, the Memory Protection Unit allows access to all memories from all CPUs.  I don't know much about safeRTOS, but you probably need to change the MPU configuration to allow access to 0x70001634 from CPU1.

IfxCpu_acquireMutex uses the __cmpAndSwap atomic instruction, which should be fine for a multicore environment.  Make sure the semaphore doesn't get linked into dLMU memory (segment 9), which could end up getting cached.

View solution in original post

0 Likes
1 Reply