The following address can be routed to the Cortex-R5F processors slave port:
•If 0xFFE6_0000 > ReqAddr[31:0] ³ 0xFFE0_0000, then route request to R5_0
•If 0xFFEE_0000 > ReqAddr[31:0] ³ 0xFFE9_0000, then route request to R5_1
This Figure shows the address map views of the RPU and APU CPUs. The TCMs are mapped into a global address space that is accessible (via RPU slave port) by an APU or any other master that can access a global address space. In addition, TCMs are aliased in the local view of the RPU starting at address 0x0000-0000.
A TCM cannot be accessed when the Cortex-R5F processor is in reset. The R5F processor must be in active or halt state to allow another master to access the TCM. The Cortex-R5F processor connection to TCM is a direct low-latency path that does not go through the SMMU. There is no protection to stop the Cortex-R5F processor from accessing the TCM.
The RPU exception vectors can be configured to be HIVEC (0xFFFF-0000) or LOVEC (0x0000-0000). Because the OCM is mapped at HIVEC, and for the RPU to be able to execute interrupt handlers directly from TCMs, the TCMs must be mapped starting at address 0x0000-0000 (=LOVEC). Also, to configure the APU with LOVEC in DRAM, the APU cannot access TCMs at LOVEC. Consequently, TCMs are aliased into a local address map of the RPU for the Cortex-R5F processor to access them starting at address 0x0000-0000.
There are cases where the CCI-400 will generate transactions using the same master ID as that of the R5_0. If that region is coherent and protected by an XMPU it will generate an error, unless the R5_0 is added to the allowed master ID list of the XMPU. If access to that region by the R5_0 is not compatible with the safety or security goal of the system, the user can either run the R5F application using only R5_1 (leaving R5_0 unused) or skip the use of coherency and not add R5_0 to the XMPU allowed list.