• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 529 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.

TMS320F28388D: Problem in release mode, when access shared ram between C28 cores and CM core

Long Pham Tan
Intellectual 381 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hi,

I am developing my project with MCU F28388D, I used all 3 cores of MCU.

Everything is still ok when I build my 3 projects for 3 cores in debug mode (optimization lever: off. opt_for_speed :level 2).

But the problem occurs when I build them in release mode, detail:

CPU1 core: --opt_lever : o2, opt_for_speed: level2.

CPU2 core: --opt_lever : o2, opt_for_speed: level2.

CM core: --opt_lever : off, opt_for_speed: level2.

My complier for C28x: Ti v 18.12.4.LTS and arm core: Ti v18.12.4.LTS. C2000ware ver 3.02.00.00 inside the C2000ware_motorcontrol_SKD_3_00_01_00. CCS9.3.0.00012

The program is still running but there is a problem, I found that the failure when CPU2 read a variable from shared ram between CM core to CPU2 core (the same happen with CPU1 core).

The reading command i put in back-ground loop (while (1) in main loop:

ex code in CPU2 core

void main()

{

             .......

          while (1)  // back ground loop

            {

                        // reading a variable from share ram CM to CPU2

                          sysmode = ipcCMtoCPU2Data.systemMode;  ===> failed

                            ......
             }

}

Temporary solution, I put the delay DEVICE_DELAY_US(10U) - about 10us before reading command :  "sysmode = ipcCMtoCPU2Data.systemMode" or change the -opt_level -> off or change the opt_for_speed to level 1, the program runs ok.

But I don't know the root core reason, I thinks the problem relates about the accessing the shared ram between the CPU cores and the safety features to protect chip? 

Can you give me the reason or information about this issue on some document like TRM, datasheet...?

  • 0
    Expert 1776 points

    Hi,
    is the systemMode variable member defined as volatile? If not, the compiler might optimize accesses to it.
    The compiler has to know that this variable can be changed by external context at any time.

    Regards,
    Andy

  • 0 in reply to AndyP
    TI__Guru** 115431 points

    Andy has good suggestion. Also what is the meaning of "failed" here ? Does it read wrong value ? If yes then how are you synchronizing the read ? Is it based on IPC interrupt/status ? If not then that can also cause issue like this.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 381 points

    Hi,

    Thanks for reply,

     - "Failed" means that CPU2 can not read the variable, It is not the "read wrong value". I followed the Andy suggestion-> problem solved. The problem may be from volatile variable.

    - But also "Is it based on IPC interrupt/status ?"  -> I am not using IPC interrupt or status, I am simply using shared ram that both cores and access them (the same address that both cores can see together), I followed this type of using shared ram from sample project motor control from C2000Ware_MotorControl_SDK  --> Is it compulsory using IPC interrupt?

  • 0 in reply to AndyP
    Intellectual 381 points

    Thanks for your suggestion, It solved my problem.