• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 207 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28379D: Standalone CPU2 Boot Procedure

Lance Hummel
Intellectual 970 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

I have a project that that is using CPU1, CPU2 and both associated CLAs. Through the debugger, I have the project working as expected. I've been trying to get the code in CPU2 running standalone, but I'm having some issues.

I looked at some of the examples and I've tried using the IPCBootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH) function. I read through the code and noticed that the function is looking for a value of C2_BOOTROM_BOOTSTS_SYSTEM_READY in the BOOTSTS register. I put a corresponding line of code in the my CPU2 executable to set value in the register appropriately. Next the function looks for the return of the IPCLtoRFlagBusy function of IPC_FLAG0 and IPC_FLAG31 to return a value of 0. 

My first question is, do I need to programmatically clear those flags in the second CPU, or is it supposed to happen automatically? I see none of the example projects with anything explicit in their CPU2 projects. 

I notice that if it is possible to get beyond that point in the code in CPU1, the IPCBOOTMODE, IPCSENDCOM, and IPCSET registers are set with particular values. Based on the IPCSET value, it looks like CPU2 will need to acknowledge flags 0 and 31. Is that correct? Is there anything else that must be done programmatically in the CPU2 program in response to the IPCSENDCOM and IPCBOOTMODE register values? Do I also need to have CPU2 wait for CPU1 to set flags 0 and 31 moving forward as well? A fully functional standalone example would be a big help.

I also have questions about the InitIpc function. I was planning on adding InitIpc before running any IPC boot functions in both CPUS to clear up all of the flags to cleanly handle a reset in the micrcontroller, I don't think there is any downside, unless it can cause other issues. I'm not sure if there is anything else I'm missing that is required for a clean and reliable standalone boot up procedure. Any advice would be greatly appreciated.

 

  • 0
    TI__Expert 3130 points

    Hi Lance,

    I have looped in a Boot expert to also give their input on this but I believe that:

    The CPU2 Boot ROM clears Flags 0 - 31 automatically and nothing else is needed for CPU2 to do in response to IPCSENDCOM and IPCBOOTMODE during startup 

    Additionally I would recommend addining InitIPC function after Boot

    Kind regards,
    AJ Favela 

  • 0 in reply to AJ Favela
    TI__Mastermind 21600 points

    Hi Lance,

    Lance Hummel said:
    I looked at some of the examples and I've tried using the IPCBootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH) function. I read through the code and noticed that the function is looking for a value of C2_BOOTROM_BOOTSTS_SYSTEM_READY in the BOOTSTS register. I put a corresponding line of code in the my CPU2 executable to set value in the register appropriately. Next the function looks for the return of the IPCLtoRFlagBusy function of IPC_FLAG0 and IPC_FLAG31 to return a value of 0. 

    IPCBootCPU2() should NOT be called when a debugger is connected, as it causes system hangs. The solution is to use preprocessor directives to conditionally compile the IPC boot function only for standalone builds, while letting CCS handle CPU2 boot during debug sessions. 

    The root cause of your standalone boot issues is that the IPCBootCPU2() function must not be called when a debugger is connected [1]. When debugging with Code Composer Studio (CCS), the debugger automatically handles the booting of CPU2, making the manual IPC boot call redundant and the direct cause of system hangs [1].

    Below is code that can be used to encapsulate this function. The _STANDALONE macro should be defined only in your standalone build configuration, not in debug configurations. See the multicore LED examples provided in C2000Ware. [1]

    #ifdef _STANDALONE
IPCBootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH);
#endif

    Regarding IPC flags being cleared, You do not need to manually clear these flags in CPU2 - the boot ROM and IPC mechanism handle this automatically. 

    When IPCBootCPU2() executes successfully, it sets the IPCBOOTMODE, IPCSENDCOM, and IPCSET registers with specific values. Based on the IPCSET value, CPU2 does need to acknowledge flags 0 and 31.this acknowledgment is handled by the CPU2 boot ROM code.

    Regarding the InitIPC(), calling it in both CPU1 and CPU2 before IPC operations is useful for clean reset handling. InitIpc() function can be used to clear all IPC flags to cleanly handle a reset in the microcontroller, which is useful for standalone boot procedures

    Links to additional references:

    [1]  TMS320F28379D: Dual core debug session boot issue 

    Hope these help.

    Regards,

    Ozino