7.1. Run a Application from DDR on R5 Cores

7.1.1. Overview

Once the R5 core is out of reset, the R5 defaults to no execute permissions for the DDR memory space. The side effect of this is, that all code, from entry point till the code that sets up the MPU (Memory Protection Unit), has to be run from internal memory.

7.1.2. Run BIOS Applications from DDR on R5

In BIOS, the application sets up the MPU as per the memory configuration specified in the *.xs file (that is referred to in the applications bios config file). Once the MPU is setup by the app, the rest of the code can run from DDR.

To ensure that all code from entry point to MPU setup is run from internal memory, the text sections of the following libs must be placed in internal memory using the application’s linker command file.

* *sysbios.aer5f(.text) * *boot.aer5f(.text) * *auto_init.aer5f(.text) * *<app>_per5f.oer5f(.text)

Refer emac_linker_r5.lds for an example.

Note

Please note that you need to replace *<app>_per5f.oer5f with the corresponding file for your application. For eg, if the application’s .cfg file is emacUnitTest_r5.cfg, then the .oer5f file will be named emacUnitTest_r5_per5f.oer5f

You also need to update the *.xs file referred to by the applications .cfg file to make sure that the DDR has execute privileges. Please refer r5_mpu.xs for an example memory configuration. You could also make the applications .cfg file refer to the common .xs file, as shown in the example emacUnitTest_r5.cfg.

Warning

Once you update the .xs file, please note remember to delete *<app>_per5f.oer5f from the applications *configuro directory, so that it is autogenerated again. If you simply do a clean build, *<app>_per5f.oer5f will not be updated to reflect the changes in the *.xs file.

7.1.3. Run Baremetal Applications from DDR on R5

Baremetal applications have similar restrictions on running code from internal memory till the MPU is configured, just like BIOS applications. For best comaptibility, however, make sure that the entry point is always the reset vector, and that the code that sets up the DDR access permissions in the MPU resides completely within 0x100 bytes of the entry point.

For applications that find the default R5 configuration setup by the CSL sufficient, there is another method that can be used to execute an application from DDR. If the bootloader (SBL) is re-built using the SBL_SKIP_MCU_RESET compile option (by enabling the corresponding line in sbl_component.mk, then SBL will branch to the application entry point without resetting the R5 core.

In this scenario, as the R5 core was already setup when the SBL invoked CSL init, the app can execute directly from DDR, right from its entry point. However, the app must take care not to redo the R5 initialization using CSL init, as the CSL initialization code assumes that the R5 registers are at their reset default values. This can be done by simply defining an empty __mpu_init function in the baremetal application. Refer sbl_smp_r5.asm for an example.