AM263P4: Multi-core project questions

Hi Jared.

Apologies for a delay in response.

Jared Weyer said:

The 'empty' example in the AM263 MCU+ SDK uses the same source code (main.c and empty.c) for each of the four R5 cores. This is all well and good; however, main.c calls multiple board initialization functions like System_init() and Board_init(). To me, this means that System_init() and Board_init() are called by each R5 core, meaning that System_init would be called four times. Is this intentional?

Yes, all the cores will call the System_init() and Board_init() APIs from their own main.c files. There is no real thread of duplicate re-configurations as Syscfg will mostly block you from using the resources in a duplicated manner. One recommendation is to always open the example.syscfg file from the system project instead of opening it core specifically, so that syscfg can highlight the duplicate resource usage.

For other resources such as MPU configs, they are core specific. The MPU ARMv7 configs that you perform are respective to the R5F core.

Jared Weyer said:

In the multi-core SysConfig view, it seems like there are multiple places where MPPA can be set. The first place is in DPL->MPU ARMv7, where you can create MPU regions and set MPPA for these regions. The second place is in the Memory Configurator->Memory Region, where you can set the attributes (MPPA) within a given memory region. My question is, which of these takes precedence? For example, if I declare a memory region in the memory configurator with start address 0x0, length 0x40, and rwx permissions, and I declare an MPU region in MPU ARMv7 with a start address of 0x0, length 32 B, and 'Supervisor Block, User Block' permissions, which permissions setting takes precedence? Can I write and read to 0x0?

The ARMv7 MPU attributes you set are for the actual R5F configuration and will take precedence, The memory configurator is just a tool to auto-generate your linker.cmd 

Jared Weyer said:

The TRM states that "The granularity of the MPU in this device is 1KB"; however, SysConfig allows granularity down to 32 B. How does TI handle this inconsistency? If I create a 32 B MPU region, am I actually creating a 1KB region under the hood, or am I misinterpreting the TRM?

The MPU that you configure in syscfg is ARM MPU settings for the R5F core. The MPU that TRM is referring to is the AM263Px System MPU that the SoC supports. Both are completely different. For the System MPU, you have minimum granularity of 1KB. The ARM R5F TRM does not mention this about the R5F core (you can read more about the ARM MPU settings in the ARM R5F manual)

Jared Weyer said:

In regards to MPU regions, what happens when different cores create overlapping MPU regions with different permissions? It is my understanding that the MPU distinguishes between different initiators (cores) via the privilege ID of a transfer; does this mean MPU regions in SysConfig are core specific? Also, it seems that it is possible to create overlapping MPU regions in the same core with different permissions. For example, I can create 'CONFIG_MPU_REGION_0' with start address 0x0, length 32B, and user/supervisor rw permissions. I can then create 'CONFIG_MPU_REGION_1' with the same start address and length, but no rw permissions. In this case, which region takes precedence? The TRM states that "In other words, the final

The ARM MPU that is configured from syscfg will allow you to create over-lapping regions, but the last one modifying the overlapping region will take place. For example if you have three MPU configs modifying the same region, the last config will take effect. The MPU configs generated by syscfg are applied by the MpuP_init() function in MppuP_armv7r.c file:

If the question is about System MPU of AM263x, that will use the privilege ID and configure it for the core, so as the TRM mentions, for System MPU if you have overlapping regions, the one with most restricted permissions takes place.

In practice, it's generally best to avoid overlapping regions with conflicting permissions when possible

Regards,
Shaunak