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.

Moving to CCS 3.1 crashes code

Other Parts Discussed in Thread: CCSTUDIO

I have a simple bit of test code that runs on the DSK5510 evaluation board. It simply transfers DIL switch settings to the LEDs:

#define GET_USER_REG (*(volatile unsigned int*)0x300000)
#define SET_USER_REG(DATA) ((*(volatile unsigned int*)0x300000)=DATA)

void main()
  {     
  for(;;)
     {
     SET_USER_REG(GET_USER_REG>>4);
     }
  } 

This compiles and runs fine in code composer ver 2 but when I move to version 3.1 the code no longer works.

Looking at the assembly generated by the two CCS versions shows that CCS2 uses a BFXTR instruction to do the shift whereas CCS3.1 uses a (more readable) move with shift.

Inserting an asm(" NOP"); in the loop makes it work again which makes me think that this is some kind of pipeline problem.

I would like to understand this problem (it has ramifications beyond the test code). Should I be writing my C code differently to use memory mapped registers or is this a bug in the compiler?

 

  • Dave,
    Can you post the assembly code you are referring to.  It's not exactly clear what instructions the compiler is generating.  Also, can you give me the versions of the CCS2 and CCS3.1 Code Generation Tools you are using.  The compiler should be awware of any pipeline issues, so this is unexpected.

    Regards,

  • I hacked the code down to its basics, generated new projects and found the same results. Here is the full source code complete with the compiler and linker options I used. This should be enough for you to get the same results:

    /* TEST CODE FOR CCS COMPILER */
    /* FOR DSK5510 EVAL BOARD - SET LEDS TO DIL SW */
    /* WORKS IN CCS VER 2 BUT NOT IN VER 3.1 */

    /* COMPILER OPTIONS:
    -g -mg -q -fr"C:\ccstest\Debug" -d"_DEBUG" -ml -v5510:2
    */

    /* LINKER OPTIONS:
    -q -c -o"ccstest.out" -x -l"C:\ti55xx\c5500\cgtools\lib\rts55x.lib"
    OR
    -q -c -o"ccstest.out" -x -l"D:\ccstudio_v3.1\c5500\cgtools\lib\rts55x.lib"
    */

    #define GET_USER_REG (*(volatile unsigned int*)0x300000)
    #define SET_USER_REG(DATA) ((*(volatile unsigned int*)0x300000)=DATA)

    void main()
      {
      for(;;)
         {
         SET_USER_REG(GET_USER_REG>>4);
         //asm(" NOP"); // UNCOMMENTING THIS LINE MAKES THE CODE WORK IN CCS V3.1
         }
      }

    When I build this on code composer studio version 2.12.07 I get the following assembly code generated:

    void main()
      {
      for(;;)
         {
         SET_USER_REG(GET_USER_REG>>4);
        
             AMAR *(#300000h),XAR3
             MOV *AR3,AC0
             BFXTR #665520,AC0,AR1
             MOV AR1,*AR3
        
         }
        
             B main
        
      }

    When I build it on Code Composer Studio Ver 3.1.0 I get:

    void main()
      {
     
            AMAR *(#300000h),XAR3
      
      for(;;)
         {
         SET_USER_REG(GET_USER_REG>>4);
        
         L1:
             MOV uns(*AR3),AC0
             SFTS AC0,#-4,AC0
             MOV AR0,*AR3
        
         }
        
             B L1
        
      }

    [By the way why cant you copy text in mixed C/assembly mode - it would have made the above exercise a little easier?]

    As you can see CCS 3.1 takes setting XAR3 out of the loop. This gives a faster loop, but unfortionately one that doesn't work. The fact that inserting and extra NOP in the loop makes it work again does look like a pipeline issue, we are trying to read and write the same memory location so it is easy to image a pipeline issue that would cause problems (although I must admit to being ignorant of the specifics of 55xx pipelining).

    Any comments?

  • By the way cl55.exe in ccs ver 2 is 2.54.

    It ccs ver 3.1 it is ver 3.2.2

    [I presume that cl55.exe is the relevent code generation tool]

  • Dave,

    I'll need to check with the compiler team on this.  Both compilers are pretty old.  Do you have registered copy of CCS3.1?  It might be worthwhile to upgrade to newer version of the Code Gen Tools and see if the problem still exists.  You can use Update Advisor under CCS -> Help to see what options are available to you.

    Regards.

  • I am trying to update the code gen tools but I need a 16 character service code that should have been supplied with the DSK5510 but was not. I have contacted Spectrum Digital about this.

    In the meantime is there any other way I could get hold of the latest code gen tools?

  • Dave,

    I need to check and see what are your options for updating CCS that comes with the DSK.  I'll have to get back to you on this.  Let me know what Spectrum Digital says.

    I tried the latest tools and see the problem that you reported for CCS3.1.  The assembly code is the same.  So an upgrade won't help in this circumstance.

    I have reported this to the compiler team, but haven't heard anything back yet.

    Regards.

  • Spectrum say:

    "Dave; Thank you for using a Spectrum Digital development tool. The CCS that comes with the DSK is a special DSK version and not upgradable. We have had this DSK version out for several years and not heard of any problems. Can you change you "C" code or data structures/variables to help the compiler ? Are you using the optimizer ? If yes, try turning it off for that module. The only way to get CCS 3.3 is to purchase the full Platinum version or use ther 120 day free download version off the TI web site. Good Luck"

    So it looks as if upgrading is out of the question anyway, unless we purchase code composer. I guess that I will just have to use the workaround of inserting NOP delays. (I do like thier suggestion of using the 120 day trial, obviously they have a more optimistic view of development times than I do.)

  • Dave,
    I got the same answer from my internal CCS licensing contact.  It might be possible to get you a newer version of the Code Gen Tools if we can identify a version that makes sense.

    I'm still waiting for feedback from the compiler team on your issue.  I am of the opinion that if it is a pipeline issue, then the compiler should be smart enough to work around it.

    That said there is definitely some type of timing issue because if I single step through your code built with the newer compiler the switch read / LED write works ok.  Are you using the standard GEL file for C5505 DSK when you configure CCS3.1?

    Regards.

  • Yes I am using the standard startup GEL file.

    By the way I am using a DSK5510, not DSK5505.

    I also found that single stepping the code made it work ok.

  • Dave,

    Sorry for the typo.  I knew you were using 5510.

    First feedback from Code Gen Team is to use the NOP work around you developed.  I am still investigating on whether this is a bug (know or unknown) on the 5510.  I'll come back to you when I have more information.

    Regards.