• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 2596 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.

TMS320F28377D: Boot problem after watchdog reset of CPU2

vesgine
Expert 1315 points
Part Number: TMS320F28377D

I am debugging 28377D with CCS. In my application, I want to reset CPU1 and CPU2 separately. The F2837xD peripheral driver library offers a function named SysCtl_resetDevice() to perform a watchdog reset.

It works well for CPU1, that is after CPU1 watchdog reset, the PC of CPU1 will go to main() again. However, it works failed for CPU2. After watchdog reset of CPU2, the PC will go to 0x3fe44e which is a ESTOP0. At the meantime, CPU1 runs normally. Then I reset and restart CPU2 using CCS, the CPU2 can run again.

Question 1: what's the difference between CCS reset and watchdog reset for CPU2?

According to the TRM, the CCS reset and watchdog reset for CPU2 are the same shown below.

After watchdog reset of CPU2, why CPU2 doesn't go to main() again?

Question 2: what's the boot sequence for CPU2  in emulation mode?

In my project, the CPU1 doesn't send IPC command to boot CPU2. Does this mean that CPU2 can boot itself without CPU1's control in emulation mode?

When CPU2 enters wait boot mode, it keeps in reset and waits for the boot command from CPU1. Is this true for CPU2 in emulation mode?

Question 3: Is there any method for CPU1 to reset CPU2 without interrupting CPU1?

  • 0
    TI__Guru** 115271 points

    Hi Vesgine,

    Question 1: what's the difference between CCS reset and watchdog reset for CPU2?

    Though functionally both reset look same the behavior will be a bit different. After debug reset CPU remains halted and when you restart, CCS will run the Gel file and force the PC with entry point so BOOT ROM may not run where as in case of WD reset, CPU will always run through BOOTROM.

    Question 2: what's the boot sequence for CPU2  in emulation mode?

    This is provided in "Figure 3-5. CPU2 Emulation Boot Flow" in BOOTROM section of TRM. You need to have correct value at 0xD00 location to boot properly via emulation boot. And yes, if the value at this location is not proper then it'll be in wait boot.

    Question 3: Is there any method for CPU1 to reset CPU2 without interrupting CPU1?

    If one need to execute code from CPU1 to reset CPU2, CPU1 has to be interrupted.  Whenever CPU2 watchdog is triggered, it generates an NMI on CPU1 (check NMIFLG section) and CPU1 NMI handler of user application should take care of rebooting CPU2 again (by sending proper IPC command).

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Expert 1315 points
    Hi, Vivek

    I add the following codes in CPU1's main() function:

    while (1)
    {
    ....
    if ((SysCtl_getNMIFlagStatus() & SYSCTL_NMI_CPU2WDRSN) == SYSCTL_NMI_CPU2WDRSN)
    {
    IPCBootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH);
    SysCtl_clearAllNMIFlags();
    }
    ....
    }
    When CPU2 watchdog reset occurs, CPU1 executes above code successfully. But CPU2 still goes to 0x3fe44e which is a ESTOP0. The value at 0xD00 of CPU2 is 0x025A which means CPU2 will be in wait mode.
    I think the PC of CPU2 should never go to 0x3fe44e even in wait mode. So is there something wrong in my project?
  • 0 in reply to vesgine
    TI__Guru** 115271 points
    Code you have written for CPU1 helps for standalone application. With debugger connected, you need to initialize 0xD00 with boot to flash setting. In my opinion if debugger is connected and CPU2 boots in waitboot then it'll go to ESTOP but I'll double check this and confirm.

    Vivek Singh
  • 0 in reply to Vivek Singh
    TI__Guru** 115271 points

    Hi,

    On following -

    In my opinion if debugger is connected and CPU2 boots in waitboot then it'll go to ESTOP but I'll double check this and confirm.

    I have confirmed that this is expected behavior. If debuger is connected then CPU will stop at ESTOP if no valid BOOT mode setting (or it's WAITBOOT) is there.

    Regards,

    Vivek Singh