TMS320F28377D: sys/bios is running abnormally in CPU2 on dual-core 28377D

Ben Qin said:

if I power on again, CPU1 can run normally, and CPU2 can only complete initialization, and cannot enter the Hwi, Clock task.

What initialization is CPU2 completing? Is it making it into main()? Is it making it to BIOS_start()? Can you tell where it gets stuck?

Ben Qin said:

In debug mode, if I run CPU2 first and then CPU1, the report is wrong, and the initialization of CPU2 cannot be completed.

What IPC functions are you using at initialization to boot CPU2? When you run CPU2 in CCS, are you running from main() or are you letting it run through boot ROM? If it's running from main, is there anywhere in the code wait it waits for a sync with CPU1? If you're running CPU2 from main before CPU1 has completed initialization of resources CPU2 needs, CPU2 might not be able to work properly.

Whitney

Hi Whitney,

I ran CPU1 in Debug mode first, everything worked fine when I ran CPU2, but after powering on and restarting, CPU2 ran abnormally, and I lit it before the last BIOSstart of the MAIN function, and it lit up (it can also light up after restarting).

In addition, I recently did an experiment and found that if the IPC module in CPU1 is commented out, it can still run normally after powering off, so I suspect that there is some incompatibility between IPC communication and sys/bios, and the library function used by my IPC communication is IPC_lite, will the application of this library function conflict with the startup of SYSbios?

Best Regards,

Ben

As far as I can tell, the only IPC code SYS/BIOS contains is the function call that gets added to the SYS/BIOS CPU1 init function. I'll post a snippet here for reference:

Void Boot_bootCPU2(Void)
{
    /* wait for C28 boot ROM to indicate ready ... */
    while ((REG(C2TOC1IPCBOOTSTS_REG) & 0xF) != C2TOC1_BOOT_SYSTEM_READY) {
    }

    while ((REG(C1TOC2IPCFLG_REG) & (INTR_SET1 | INTR_SET2)) != 0) {
    }

    /* specify the boot mode */
    REG(C1TOC2IPCBOOTMODE_REG) = C1TOC2_BOOTMODE_BOOT_FROM_FLASH;

    /* write IPC command code to execute boot mode */
    REG(C1TOC2IPCCOM_REG) = C1TOC2_EXECUTE_BOOTMODE_CMD;

    /* generate interrupt to C28 */
    REG(C1TOC2IPCSET_REG) |= (INTR_SET1 | INTR_SET2);
}

If the regular application code already handles these steps, then you can uncheck the "Initiate boot of the CPU2 processor" setting from the CPU1 SYSBIOS cfg file.

Whitney

Hi Whitney,

Thank you for your reply. I checked the boot settings in CPU1.

As shown in the picture, it is no different from the code you provided.

In addition, I will encounter such a problem. In debug mode, if I run CPU2 alone (my sys/bios is in CPU2 and CPU1 is bare metal), the following error will be reported.

but if I run CPU1 first and then CPU2, this problem will not occur.

Best Regards,

Ben

Ben,

Interrupt 19 is an illegal instruction trap. You could single step through the CPU2 code to confirm, but my guess is that CPU2 is trying to run before CPU1 has granted it access to shared resources. For example CPU2 could be trying to call a ramfunc function before CPU1 has granted CPU2 access to the RAM where that function resides.

Whitney

Hi Whitney,

As you guessed, I commented out all the Delay_us (this function needs to be copied to RAM) and there was no problem. Thank you for your answer. Will there be any conflict between the IPC module and sys/bios? I found that as long as I know how to use IPC0, there will be no problems during the running of the program.

Best Regards,

Ben

Hi Whitney,

I read the program itself carefully, I personally think that there is no problem with my program, and at the same time I turned the SYS/bios program in CPU2 into a bare-metal program, this problem miraculously disappeared, I was thinking about whether there was some invisible problem in the running process of the compiler or assembler, have you encountered a similar phenomenon in the past, is there any solution idea, or what debugging idea?

Best Regards,

Ben

I'm not aware of any known issue. I think you would need to do a more detailed debug to figure out the cause, like connecting to the device after a POR with your debug config/gel file configured to connect without causing a reset, so you can see the state of the device when it gets stuck.

I'm not sure if your post is in reference to a new project or supporting an existing SYS/BIOS project, but note that we are no longer recommending SYS/BIOS use for new projects. Customers who want to use an RTOS should use FreeRTOS or a third party option.

Whitney

Hi Whitney,

When I checked online information, I found that similar problems seemed to have occurred during automatic code generation in Matlab. Do you know how to solve it at that time?

Best Regards,

Ben

Ben,

Unfortunately I'm not familiar with that issue or the code involved and don't know the details. I think you'd have to contact Mathworks.

Whitney