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.

XDS100v3 debug issues with optimization off in SimplelinkBLEPeripheral on CC2640

Other Parts Discussed in Thread: CC2640

Hi there,

using the SmartRF06 board for programming our custom board is causing weird behavior when I try to switch optimization off for debug purposes.


This happens with an light modified SimplelinkBLEPeripheral project which compiles and runs error free when optimization is set to full.

It compiles error free with optimization off as well

If optimization is off the debugger starts loading the image onto the board, but hangs then and  even if the download is ended with the following message "Cortex_M3_0: Error occurred during flash operation: Timed out waiting for target to halt" the red LED on the debugger board keeps on.

If that happened once, the cc2640 can not be programmed any more using debug process in CCS.

I have to use flash programmer and program an entire working image onto the CC2640. After I can use CCS again to program any image on the chip using the XDS100 debugger.

I was thinking that this might have to do with the stack, as it is compiled with full optimization ON. However, if I try to compile the stack with optimization off I get the message that the image doesn't fit into the memory and some references are missing.

Hence I would like to know the hints about using optimization off and using a correct debug environment.

  • Hello Ralph,
    When you change the optimization level you will nee to rebuild and download the application image again. It might not be enough room for the application for a low optimization level to fit on the device. In that case you should either reduce the size of your application or chose a medium optimiztion level instead. If you wan to debug specific functions you can reduce the optimzation level explicitly on those functions only by setting the following pragma right above/before the function.
    #pragma optimize=none

    Also read more about the boundary tool in the software developers guide. In some cases you have to build twice to allow the boundary tool to adjust the boundary between stack and image correctly.
  • Hi Erik,

    thank you very much for the quick reply, however that does not answer the question do I have to compile both stack and app for using optimization off for debugging? I wouldn't expect so.

    And second, what could cause the problem with the debugger ? Optimization on it works optimization off, debugger stalls.

    Thanks
    Ralph
  • Hello Ralph,
    No it should not be necessary to compile both again. Remember to rebuild the application properly and download before you start the debug session. I will test it tomorrow myself to see if it works as expected.
  • Hi Erik,

    HA! your tip with the pragma guided me to the root cause of the debugger problem.

    The XDS100, I use, has that behavior if you define TI RTOS task variable as static in the module ( taskStack and Task_Struct ), once I managed to debug the relevant functions I could see that the Task_Struct was not initialized at all.

    Correcting this and making the variables global fixed as well the XDS100 issue.

    However regarding using the #pragma for functions in CCS refer to this thread

    e2e.ti.com/.../125869

    Thanks again and best wishes

    Ralph
  • Ralph,
    Great. You are right. I was thinking in IAR instead of CCS.