• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 377 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: dual-CPU debug

David M. Alter
Guru 61235 points
Part Number: TMS320F28377D
Other Parts Discussed in Thread: C2000WARE

C2000 Team,

I am looking at dual-CPU debug on F28377D launchpad.  I am using the blinky program from C2000Ware v1.0.6.0.

1) For CPU1, there are two flash configurations of the project: STANDALONE, and DEBUG.  What is the difference between these two and why?  All I see as a difference is that STANDALONE calls

IPCBootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH);

to have CPU2 proceed through its bootROM whereas DEBUG does not.  But if so, how does the DEBUG version get CPU2 running?

2) I've noticed in CCSv8.3 that if I have both CPUs connected to the emulator, and execute a CPU reset on CPU1, CCS throws a timeout error and both CPUs immediately become disconnected.  Why?

3) Given (2) above, after a debug sequence, how do I cleanly reset (start over again with debug)?

Thanks and regards,

David

  • 0
    TI__Guru** 113855 points

    Hi David,

    As you know in debug if user loads the code on CPU then CCS force the PC to entry point and run from there. In that case IPC boot command from CPU1 is not needed and if used, it'll not work because there will be no acknowledgement from CPU2 code in BOOTROM (PC already points to application so BOOTROM will not run).

    2) I've noticed in CCSv8.3 that if I have both CPUs connected to the emulator, and execute a CPU reset on CPU1, CCS throws a timeout error and both CPUs immediately become disconnected.  Why?

    This is a CCS issue and has been fixed in a patch. Please see below note.

    "For CCS8.x, you can check for updates in CCS and install the “CCSv8 Service Release Windows 8.3.1.00004” package."

     

    Please try this and let us know if you still see this issue.

     

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    TI__Guru* 87105 points
    David,

    FYI (for any others that may come across the disconnect issue on CCSv9): For CCSv9.x, you need to check for updates in CCS and install the “TI Emulators 8.1.0.00012” package. This will fix the CPU2 disconnect issue.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vivek Singh
    TI__Guru 61235 points

    Hi Vivek,

    The reset issue with CPU1 was fixed with the CCSv8.3.1.00004 update package.  Thank you.

    On the first question, I would expect to be able to use the same flash code whether I am running with the debugger or not.  With the debugger connected and using jump-to-flash bootmode, wouldn't the following procedure work where CPU1 is sending the IPC command to CPU2 to direct the bootmode:

    CCS reset CPU2

    CCS reset CPU1

    Run CPU2.  CPU2 stops at ESTOP0 in bootROM.  Hit Run again.  CPU2 enters IDLE waiting for IPC interrupt.

    Run CPU1.  CPU1 releases CPU2 to complete bootROM.

    The above seems to work OK with the Blinky example STANDALONE configuration flashed.

    Regards,

    David

  • 0 in reply to David M. Alter
    TI__Guru** 113855 points
    David,

    Yes, as you confirmed that method will work but most of the user while debugging the code does not want to do that and were facing the issues hence this option was added.

    Regards,

    Vivek Singh