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.

Migration CCS 3.3 running on Windows XP to CCS v5.3 running on Window 7 64 bit

Other Parts Discussed in Thread: TMS320DM642

Hi

I am working with TMS320DM642 DSP, with DSP BIOS 5.31.02

I am trying to migrate with my code from CCS 3.3 running on Windows XP to CCS v5.3 running on Window 7 64 bit , and stay with the old version of code generation tools  CGT v6.0.18.

I  succeed to compile my project , and I see that the all compilation and linker flags are ok .  But my code behaves different from original version compiled on  ccs 3.3.

Its seems like the optimization , does not work,. the code runs much slower than original version.

 

There is some known  problem with using the old code generation tools (CGT v6.0.18) with CCS5.3 running on Window 7 64 bit ?

 

Thanks

  • Hello,

    Did you import the old project into 5.3 or did you create a new project?

    Genady Kagan said:
    There is some known  problem with using the old code generation tools (CGT v6.0.18) with CCS5.3 running on Window 7 64 bit ?

    That version should be fine with 5.3.

    Genady Kagan said:

    But my code behaves different from original version compiled on  ccs 3.3.

    Its seems like the optimization , does not work,. the code runs much slower than original version.

    Please provide some more details on how you came to this conclusion.

    Thanks

    ki

  • Now its start working ..i notice , that its depends on linkage order , that chaged with chossing different "Builder type"

     

    I change the “Builder type” from external (with settings CCS_BUILD_UTILS/gmake) to internal  , and this case to different linkage order . For example , my *.cmd files , when the “Builder type” was external , the cmd files, was linked last , after all  objects. When the “Builder type” was external , the cmd file was first in the linkage order .

     Can you explain  please , what the difference between “internal” and external “Builder type” , and why the linkage order is important? Probably I have some bug in my code .., that the different linkage order prevent memory corruption .

     

    Thanks

  • Genady Kagan said:
     Can you explain  please , what the difference between “internal” and external “Builder type”

    internal builder will use CDT's built in functionality to built projects. The external builder will allow an external utility (like gmake) to be used. You should always be using the external builder option for CCS projects

    Genady Kagan said:
    and why the linkage order is important?

    This is more of a general question and there is a lot of information regarding link order:

    http://chrisoldwood.blogspot.com/2012/09/from-visual-c-to-gcc-linker-order.html

    In any case, you can specify the link order regardless of the builder type. There is a tab called 'Link Order' under the 'Build' or 'CCS Build' (depending on if you show advanced settings) where you can do this.

    Thanks

    ki

  • Hi

    Thanks for reply

     

    The only difference between link order with external and internal builder, that the place of the cmd  file, that is generated from TCF file automatically

     

    The internal builder puts this  cmd file  last , in link order

    The external builder puts this cmd file  first in link order

    I did not see any more difference .

     

    May be , you have  idea , why it important ?

  • Please do not use the internal builder. Use the default external builder.

    You can still control the link order manually when using the external builder

    The order of when things are linked can have a great impact. Please refer to the url I mentioned for more details.

    Thanks

    ki

  • Hi I found the problem ! In EMAC driver from NDK and CSL library , was object with the same name , I need the object from the NDK and not from CSL .When I change the link order between two libraries, everything start working. Thanks

  • Yep, that makes sense. That is why the link order is important. The linker will use the first one it finds. Hence it is important to have that the correct one first in the order.

  • Can I prevent such kind of bugs , with some compiler /linker settings ? I think , that another  linkers , Visual studio for example , alert me , if I have to objects  for linker with the same name .