This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CPU2.CLA1 of F28377D won't start up without emulator

Other Parts Discussed in Thread: CONTROLSUITE, SYSBIOS

Hello,

I have a custum board with Delfino including 2 CPU (each core has a CLA). My software uses these 2 CPU and 2 CLA.

When I flash my board through the JTAG in Debug Session, processors and co-processors run without problem.

Here is approximately the process:

  1. CPU1 init
  2. CPU1.CLA1 init
  3. CPU1 sends boot command to the CPU2
  4. CPU2 init
  5. CPU2 sends boot OK to the CPU1, so CPU1 continues its process
  6. CPU2.CLA1 init
  7. CPU2 continues its process

However, after a power down, so standalone witout debug session, the CPU2.CLA1 won't start up (CPU1.CLA1 is ok). Thanks to a maintenance tool, I see that I can't write in the registers of the CLA. Init functions are called but no action is done.

Example:   Cla1Regs.MCTL.bit.IACKE = 1 has no effect in the register MCTL

According to the topic "CLA of 28069 won't start up without emulator - ", I checked if I had the following functions in my code

  • memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize)
  • memcpy((INT32U *)&ClafuncsRunStart, (INT32U *)&ClafuncsLoadStart, (INT32U)&ClafuncsLoadSize)

..they are called during the initialisation.

Could you help me please ? I don't understand why I can't set the CLA after a power down while in Debug Session everything is ok...

Regards,

Kevin

Tools: C2800 Compiler 6.4.6, Code Composer Studio v6

Hardware: custom board with F28377D

  • Hi,

    Did you try the dual core examples for the CLA. There is one C:\ti\controlSUITE\device_support\F2837xD\v170\F2837xD_examples_Dual\cla_iir2p2z. If you look at the cpu01 project it has a project configuration for standalone which basically causes cpu1 to send cpu2 an IPC message to boot from flash instead of ram

  • Hi,

    I didn't try this example but I followed its processing.

    The CPU1 inits the system (clocks, memories...), components (PWM, CLA...), sends a boot command to the CPU2 (boot from flash), inits again others components and starts SYSBIOS.
    As far the CPU2, it begins also to init the system, interruptions, its CLA and starts the applicative program.
    Furthermore, I use IPC to perform a synchronisation mechanism between the both CPU.

    Moreover, each CPU has a cmd file inspired by 2837xD_FLASH_CLA_lnk_cpu1.cmd.
    CPU1 has the file F2837xD_Headers_BIOS_cpu1.cmd and the following predefined symbols: CPU1 and _FLASH.
    CPU2 has the file F2837xD_nonHeaders_BIOS_cpu2.cmd and the following predefined symbols: CPU2 and _FLASH.
    Finally, each CPU has also the pre-define preprocessor macro CLA_C=1.

    So, I don't understand why the second CLA is not set in standalone processing.

    Thank you for your answer

    Kevin
  • Ok the only other difference in the CLA configuration between the cores in that example is the clocking and copying the CLA code from FLASH to RAM.

    void CLA_configClaMemory(void)

    {

    ...

    IpcSync(5);

    EALLOW;

    #ifdef _FLASH

    // Copy over code from FLASH to RAM

    memcpy((uint32_t *)&Cla1funcsRunStart, (uint32_t *)&Cla1funcsLoadStart,

    (uint32_t)&Cla1funcsLoadSize);

    #endif //_FLASH

    #ifdef CPU2

    // Enable CPU2 clocking at the sys clock level

    CpuSysRegs.PCLKCR0.bit.CLA1 = 1;

    #endif //CPU2

    ....

    }

    I would encourage you to try this example, and perhaps replace the contents of the .cla file for CPU02 with what you have written and then see if it still fails. 

  • Hi,

    I read once again this example and I finally found the error !

    I had forgotten instructions EALLOW/EDIS around CpuSysRegs.PCLKCR0.bit.CLA1 = 1 in order to turn-on the CLA clock.

    In my code, EALLOW/EDIS were put just after this writing in the CpuSysRegs register.

    Furthermore, I just noticed that the EALLOW bit is overridden via the JTAG (according to the datasheet).
    That is why I had not seen that the problem could come from here.

    Thank you for your help,

    Kevin