• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 520 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.

C6701 Code Optimization breaks the code

willshad
Intellectual 405 points

I am using CCS 5.3 with BIOS V5.42.0.7 to compile code for our TMS320C6701 DSP. Due to our RAD-HARD requirement, I cannot use any external memory. So far, we have managed to fit within the 64K code/data space of the DSP but just barely (6.8K of unused code memory).

I turned on file optimizations (Opt = 1, now 15.5K of unused code memory) and the code no longer worked...a lot of stack variables got optimized out of the code. Some of these variables were used to poll the hardware for a change. I changed a few variables to be volatile and got most of the code to work.

To verify that the emulator was not affecting code execution, I created a ROM image and placed the code in our EEPROM. Tried to run from EEPROM and the DSP did not report itself as running, it should set a bit in an FPGA if it's sane and running.

I added an infinite loop at the beginning of main and loaded only the symbols via the emulator when connecting. I can successfully step out of the infinite loop and run the code from EEPROM...at least I think I'm running from eeprom. So, now I'm out of ideas on how to debug the issue of running from EEPROM since that same image runs when the emulator is connected.

1. Any ideas what I should try next?

2. Should I change all stack variables to be volatile or only those used to poll h/w?

3. Does optimizations also remove stack variables that are pointers to h/w?

The current compiler/linker settings are:

-mv6700 --abi=coffabi -O1 -ms3 -g --define="CHIP_6701"

I have also tried dropping to Opt=0 and no improvement.

I added the directive "--call_assumptions=0" to a file via the CCS menu. The directive is in the compiler command line but did not seem to take affect. The local variables in a routine within this file are still being optimized out.

Regards, Bill.

  • 0
    TI__Guru* 84110 points

    Bill,

    You may want to add the --opt_for_space option to help the compiler understand your preference for code size optimization.

    The emulator is not going to affect your code execution unless you are specifically doing things that use the CCS debugger while the code is running. For example, if you start the program running and then refresh a CCS window or write to a variable through CCS, the program may be temporarily halted to allow CCS to gain access to the area being accessed. I doubt you are doing this or it would have been part of your discussion.

    1. Go back to using CCS to figure this out. You can control the use of optimization on a file-by-file basis in CCS. In the Project window, right-click on a file name and select Properties. This will let you set the optimization level for that file to 'off' which will let you figure out which file or files are being affected by the compiler's optimization. Then you can narrow down the portion that is being altered and figure out which variable(s) need to be modified as 'volatile'.

    2. 'volatile' is needed for any variable that will be modified outside the scope of a function. This would include anything in your FPGA that is not simply a memory storage location, and it includes any flag variables that may be changed in an ISR or another thread.

    3. Nothing gets removed arbitrarily by the compiler, but that is based on the compiler's definition of "arbitrarily". It assumes that every variable and pointer-referenced location is a RAM memory location - the compiler does not natively know about hardware or 'external effects'. So anything that does not match that definition of RAM memory needs to be handled by applying the 'volatile' keyword.

    Common cases are delay loops like for (i=0;i<1000;i++) being optimized to i=1000, which is mathematically correct - make i volatile or better use another variable that is volatile so you can use i elsewhere as a non-volatile. Making something volatile when it does not need to be volatile will cause undue limitation on the optimizer, so try to only use it when needed.

    Please supply an example of a local variable being optimized out.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 405 points

    Hi RandP,

    Thanks for your response. I'm gaining some confidence with the software now that I've determined that some of my issues were due to flaky hardware. The hardware problems were causing the system to lose packets, until I determined this I thought the software was behaving oddly when running from EEPROM.

    1. My "--opt_for_space" option is set to level 3 (-ms3).

    2. I placed the attribute "volatile" on all pointers to external hardware and now all the software is working with Opt1 level optimization. I've got 16K of unused code memory.

    3. When I thoight that stack variables were just being arbitrary removed, it was because the DSP did not boot up properly. I found the sub-routine that was causing a problem, it did not account for another h/w quirck and so caused the s/w to hang. I've corrected the issue and now the system boots everytime. Another red heron.

    Thanks again for your help on clearing up some of my confusion.

    Regards, Bill.