Configuring internal SRAM for shared use in MPC5777CEVB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Configuring internal SRAM for shared use in MPC5777CEVB

Jump to solution
473 Views
ricardofranca
Contributor III

Hello,

I was playing with the MPC5777C using the NXP MPC5777CEVB and I wanted to develop some basic application that would make the two cores interact. I used the Green Hills toolset (compiler, debugger and probe) and followed AN5191 to initialize the board, integrating the code provided there with the Green Hills start files.

My application is:

====

#include <stdio.h>
 
__asmleaf unsigned int get_pid(void)
{
    mfspr r3, 286
}
 
 
extern void __start();
volatile unsigned int edited_by_core1 = 0xbadu;
volatile unsigned int *SIU_RSTVEC1 = (unsigned int *)0xc3f909b0u;
 
int main(int argc, char *argv[])
{
    if (get_pid())
    {
while(edited_by_core1 != 0x1000000)
{
}
    edited_by_core1 = 0x6000000du;
while(1)
{
}
    }
    else
    {
edited_by_core1 = 0x1337u;
    *SIU_RSTVEC1 = (unsigned int)__start + 1u; 
    while (edited_by_core1 != 0x6000000du)
    {
if (edited_by_core1 < 0x1000000)
{
edited_by_core1 += 1u;
}
    }    
    printf("Hello world.\n");
    return 0;
    }
}
====
 
Thus, "Hello world" is displayed if both cores alter a shared variable when they are supposed to. However, my code worked only when I modified the TLB entry corresponding to the internal SRAM to make it non-cacheable. When it was configured as cacheable, even if I set WIMGE to 0x16. In other boards (e.g. the T1040D4-RDB), it was sufficient to set the shared variables as volatile and I could make the cores communicate even with write-back data cache.
 
I suppose I am making some big mistake, but I cannot figure it out. Any insights?
 
Thanks,
Ricardo
0 Kudos
Reply
1 Solution
448 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

You can two options:

- either you use cache inhibited attribute for shared RAM memory region

- or you will configure cache coherency unit, on this device called Platform Coherency Unit (PCU) (Chapter 7), only in this case MMU TLB attribute M is applied.

If the issue is related to coherency. Another point is that SRAM is accessed over XBAR one port, and one core has priority over another. Easiest way to test it is to use round robing for all slaves as following:

/* set round robin for all slaves */
XBAR.PORT[0].CRS.B.ARB = 1;
XBAR.PORT[1].CRS.B.ARB = 1;
XBAR.PORT[2].CRS.B.ARB = 1;
XBAR.PORT[3].CRS.B.ARB = 1;
XBAR.PORT[4].CRS.B.ARB = 1;
XBAR.PORT[6].CRS.B.ARB = 1;
XBAR.PORT[7].CRS.B.ARB = 1;

View solution in original post

2 Replies
449 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

You can two options:

- either you use cache inhibited attribute for shared RAM memory region

- or you will configure cache coherency unit, on this device called Platform Coherency Unit (PCU) (Chapter 7), only in this case MMU TLB attribute M is applied.

If the issue is related to coherency. Another point is that SRAM is accessed over XBAR one port, and one core has priority over another. Easiest way to test it is to use round robing for all slaves as following:

/* set round robin for all slaves */
XBAR.PORT[0].CRS.B.ARB = 1;
XBAR.PORT[1].CRS.B.ARB = 1;
XBAR.PORT[2].CRS.B.ARB = 1;
XBAR.PORT[3].CRS.B.ARB = 1;
XBAR.PORT[4].CRS.B.ARB = 1;
XBAR.PORT[6].CRS.B.ARB = 1;
XBAR.PORT[7].CRS.B.ARB = 1;

433 Views
ricardofranca
Contributor III

Hello David,

Thanks for your help! In my case, all I needed (at least, things look like they are working...) was some code to enable the PCU. I set PCU_CESR to 0x0000_3001 so that it would be active and monitoring global writes by both cores. Is that correct?

As for the XBAR, does it manage access over the internal Flash, too?

 

Thanks,

Ricardo

 

 

0 Kudos
Reply