TMS320F28379D: F28379D - grouping of CPU1 and CPU2 during debug

Lenio Cacula

Part Number: TMS320F28379D

I have worked on this issue with the CCS group, reaching the conclusion that the problem is more likely to be related to the boot firmware in the F28379D.

This is the original post, which demonstrates the steps on how to reproduce the issue. In summary, when the cores are grouped, CCS is unable to resume and suspend execution without generating an error on the first attempt. https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/559771

Here are some of the conclusions and questions directly from the customer, who is well versed in the bootloader process of the C2000 devices:

Running both cores causes them to stop because of an ESTOP0 in the boot ROM. Why is this in the code? Why stop the code execution when the debugger is connected? We just want the code to read the hardware jumpers at startup to determine the boot mode. This is what the boot ROM source code states:

void WaitBoot(void)
{
//    sysctl_wdog_enable(); //- for debug
	if(((OTP_BOOT_CONFIGURE_WORD & 0xFF000000) >> 24) == 0x5A) //CHECK if key match fails
	{
		if(((OTP_BOOT_CONFIGURE_WORD >> 8) & 3) == 0x1)
		{
			c1brom_enable_pie_in_boot(1);
		}
	}
	else
	{
        sysctl_wdog_enable();
	}

    // If the emulator stops here
    // a) change EMU_KEY to 0x55AA
    // b) write the appropriate boot mode to EMU_BMODE
    // c) perform a debugger reset, and run
    asm("   ESTOP0");

	for(;;)
	{
	}
}

Thank you!

over 8 years ago

0 Christopher Chiarella over 8 years ago

TI__Mastermind 30255 points

Hello,

This is to assist in identifying (when debugging), that the boot code is in wait boot. At this point, write the emulation boot settings in the key and EmuBMode location for each core, then reset and it will run the requested boot mode which won't have the emulator stop.

Best Regards
Chris

0 Lenio Cacula over 8 years ago in reply to Christopher Chiarella

TI__Genius 16410 points

Hi Chris,

can you offer some more details on how to setup the Emu BMode? I tried using the scripts, and setting each CPU to boot from flash. I could not see a difference with the problem.

I will borrow the following text from Ki-Soo Lee to better explain on how to reproduce the issue:

I first started a debug session, grouped the cores and then loaded the programs to their respective cores (CPU1 first and then CPU2). Then I ran the cores as a group. Works fine. I can run and suspend multiple times and no problems. I can halt individual cores and resume execution and there are no problems. Then run as a group again. All worked fine.

The issue began when I halted the target and did a CPU reset and restart (R&R). I can reproduce the issue when:

I R&R CPU2 before CPU1. Then no matter how I resume execution (whether run the group, or run CPU1 first, or run CPU2, etc…) I get the issue where one of the cores does not run correctly.

I R&R CPU1 before CPU2 and then run as a group OR I run CPU2 before CPU1. CPU2 does not run correctly (abort).

The only time it works fine is when I R&R CPU1 before CPU2 AND then I run CPU1 first before CPU2. Then it works fine again and afterwards I can then run and halt as a group or individual cores with no issue.

It is an odd issue, some delicate dependency between the 2 cores. It would be good to have C2000 experts insight on…

0 Santosh Athuru over 8 years ago in reply to Lenio Cacula

TI__Mastermind 19810 points

Lenio,

whenever CPU1 is reset, CPU2 is also reset. So the correct way to debug this is do a debug Reset and restart on CPU1, and while CPU1 is waiting at main() in application, do a debug reset and restart on CPU2 so now both the CPUs are at respective main()s and now you can run both of them.

So the debug Reset of CPU1 has to happen before CPU2 always. You cannot expect CPU2 to be still running while CPU1 goes into reset.

Now for running one core after other it depends on the application. CPU2 application cannot run before CPU1 application has configured the system resources as needed, so as long as there is a ready to run signal from CPU1 application to CPU2 application and as long as CPU2 application waits for this signal from CPU1 application you can run the cores in any order. But if not then CPU1 application has to run before CPU2 application.

Hope this helps.

Best Regards

Santosh Athuru

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28379D: F28379D - grouping of CPU1 and CPU2 during debug