8. Frequently Asked Questions

  • How to enable standalone boot of different cores?

    • CPU1 is booted as per the boot pin configuration.

    • CPU2 and CM needs to be booted by CPU1. This can be done by using the driverlib functions Device_bootCPU2 and Device_bootCM

    • CLA does not need explicit boot. Once the CLA clocks are enabled, the CLA tasks will get executed on receiving the respective triggers.

    Please refer to the device TRM chapter ROM Code and Peripheral Booting for more details.

  • Does having a breakpoint in CM halt CPU1?

    No, the breakpoints are separately available in different cores (CPUx, CPUx.CLA and CM). If any core hits a breakpoint, none of the other cores will be halted.

  • CPU2 is unable to write to a particular register or memory location. What could be the reason?

    Some of the memories and peripherals are shared across multiple cores. Make sure the ownership of the memory / peripheral is correctly assigned before accessing them.

    There are certain register blocks which are only accessible by the CPU1 core. Please refer to the TRM register descriptions to know the accessibility of registers from different cores.

  • Why am I unable to get CM to toggle a GPIO pin?

    The GPIOs are shared across cores. Make sure the ownership of the GPIO is correctly assigned before accessing them. The basic GPIO configuration such as direction, pull-up, polarity, open-drain and so on must be done by the CPU1 core.

  • Can I use GSRAM as stack memory or for storing global variables?

    Yes, GSRAM can be used as stack memory and also for storing global variables. This can be done by updating the linker command files. But note that these are shared by CPU1 and CPU2 and be careful not to use the same memories by both the cores. In case of CPU2, CPU1 needs to assign the ownership of the GSRAM to CPU2.

    On contrast, the LSRAMs are not shared and are physically different memories even though the addresses used by CPU1 and CPU2 are the same.

  • Can I use GSRAM to store CLA data /program?

    No, only LSRAMs are accessible by CLA.

  • Getting the error “Program will not fit into available memory” for Cla1Prog section.

    This means the the CLA program size is more than the assigned memory block. You can map multiple memory blocks to the Cla1Prog section. For example, if the original configuration was :

    RAMLS4   : origin = 0x00A000, length = 0x000800
RAMLS5   : origin = 0x00A800, length = 0x000800

Cla1Prog : > RAMLS4

    There are 2 ways to map RAMLS5 as well to Cla1Prog section.

    Option 1:

    RAMLS4   : origin = 0x00A000, length = 0x000800
RAMLS5   : origin = 0x00A800, length = 0x000800

Cla1Prog : >> RAMLS4 | RAMLS5

    Option 2:

    /* RAMLS4   : origin = 0x00A000, length = 0x000800 */
/* RAMLS5   : origin = 0x00A800, length = 0x000800 */
RAMLS4_5   : origin = 0x00A000, length = 0x001000

Cla1Prog : > RAMLS4_5

    In Option 1, Cla1Prog section will be split into 2 subsections and mapped to LS4 and LS5 memories. In option 2, the LS4 and LS5 are combined to form a bigger memory block which is used to map the Cla1Prog section.

    Note that in both cases, both RAMLS4 and RAMLS5 should be configured as CLA program memory.

  • Why is “Load Symbols” needed for the CLA core?

    The CLA code is actually embedded in the respective C28x application. When the .out is loaded to the C28x core, the CLA application as well gets loaded. To add the debug information on the CLA core, you need to load the symbols of the .out. This step does not load the actual .out file. This will just load the debug symbols available in the .out file to the CLA core. Even if this step is skipped, the CLA will run the tasks as expected. But when you connect to the CLA core, the source code and variables/expression will not be visible.