• Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 549 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.

Problem with C6000 7.3.X compiler compared to previous versions

Franck
Intellectual 685 points

Hi,

We have a pretty stable application on a DM6437 that we have built over several compiler major revisions (6.0.X, 7.0.X, 7.2.X) and we now face a brand new issue with version 7.3.X.

The problem comes with the CPU load evaluation of our application. For CPU load evaluation, we both check at the CPU load built-in feature on Code Composer (through RTA) and we also have a custom CPU load evaluation function that runs inside the bios (v5.42) idle loop by making use of the IDL_busyObj global variable.

Since version 7.3.X, the CPU load is incredibly high (around 50% with almost nothing running in the application). Both the built-in tool and our custom tool give approximately the same result. Under previous versions, the load was around 1% in similar conditions.

Surprisingly, I don't feel like the actual CPU load is really higher with version 7.3.X since our app can run as usual, and we see that as we load the CPU, it tends toward 100% as it would usually do with previous releases.

I am not so sure about how to find the root cause of this problem, but I could figure out that if I disable RTDX (by commenting bios.enableRtdx(prog) in the TCF file), the CPU load is correct (gets back to 1%). I also noticed that the problem looks not present when I compile in debug mode with no optimization.

I would appreciate having your thoughts about that behavior.

Thanks

Franck

  • TI__Guru**** 249830 points

    My guess is that you have some subtle bug in your source that is finally uncovered by v7.3.x.  Perhaps you are failing to use volatile somewhere.

    Consider disabling optimization for one source file at a time.  I suspect you would find that it is the optimization of one source file that causes the problem.  Is it practical for you to try this approach?

    Thanks and regards,

    -George

  • in reply to George Mock
    Intellectual 685 points

    Hi George,

    Thanks for the reply. I could figure out what source file is causing the problem by disabling optimization on it as you suggested.

    Unfortunately, I could not find yet what is wrong with the code. I will try to investigate more in depth and let you know what I find.

    By the way, we are using Bios 5.41 in our application. We need to access some global bios objects pointers in our application (for making use of LOG_printf() or TSK_setpri()  for instance). For accessing them, we used to include the header file automatically generated by the XDCTools at compile time which is located under /release/configPkg/package/cfg/*_x64Pcfg.h. Content of this file looks like:

    (...)
    extern far TSK_Obj TSK_acq;
    extern far TSK_Obj TSK_algo;
    extern far TSK_Obj TSK_fan;
    extern far TSK_Obj TSK_img;
    extern far TSK_Obj TSK_pan;
    extern far TSK_Obj TSK_diag;
    extern far TSK_Obj TSK_cam;
    extern far TSK_Obj TSK_IdSrv;
    extern far TSK_Obj TSK_ConfigSrv;
    extern far TSK_Obj TSK_DataSrv;
    extern far TSK_Obj TSK_DetectClient;
    extern far TSK_Obj TSK_Network;
    extern far LOG_Obj LOG_system;
    extern far LOG_Obj trace;
    extern far LOG_Obj slowTrace;
    extern far LOG_Obj DVTEvent_Log;
    extern far STS_Obj IDL_busyObj;
    (...)

    What is your opinion for the need for the volatile keyword when using them? Should we re-declare them inside our application and add the volatile keyword to them?

    Thanks

    Franck

  • in reply to Franck
    TI__Guru**** 249830 points

    Franck said:
    Unfortunately, I could not find yet what is wrong with the code. I will try to investigate more in depth and let you know what I find.

    I have another technique to suggest.  It is similar to the last one, but applied to functions instead of files.  Build the problem file with the usual optimization level.  But apply this pragma to one function at a time.  

    #pragma FUNCTION_OPTIONS(func_name, "-o0");

    This lowers the optimization for that function to the lowest level.  Hopefully, this technique will show you which function is the source of your problem.  Then, the real detective work starts.  Build with -s to see compiler generated comments in the assembly.  Inspect the function in the .asm file generated by the compiler.  I'm confident you will find the issue then.

    Don't worry with whether to apply volatile to any global variable, BIOS or not.  At this point, there is no evidence that is the source of the problem.

    Thanks and regards,

    -George