• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 655 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.

Code Composer V5.5.0 Breakpoint Issue

Erik D
Prodigy 20 points


Greetings,

First, thank you for your help.


We are doing embedded design with the MSP430FR series. We are using the Code Composer 5.5.0 IDE to develop and debug our code.


We are having a problem setting breakpoints where we want them. Sometimes we are able to set breakpoints exactly where we want, and when we compile and download the program to debug, the breakpoint is where we put it. Other times when we set a breakpoint and download to debug, it moves location to the end of a function (e.g. we set a breakpoint somewhere in main(), and when we compile and download, the breakpoint is moved to the end of main()). Also, it seems that when this is happening, we are initially setting a S/W breakpoint, but after we click the debug button and it downloads, when we look at the breakpoint in the Breakpoint window, the S/W breakpoint has turned into a H/W breakpoint. We are not sure what we are doing to cause this. We have tried turning  the optimizations of in the MSP430 compiler, but this does not help. Lastly, after battling with this, something will happen and we will again be able to put breakpoints where we want them.

Any help/guidance would be greatly appreciated. Thank you.


Cheers,

Erik

  • 0
    TI__Guru**** 472291 points

    Hi Erik,

    Erik D said:
    Other times when we set a breakpoint and download to debug, it moves location to the end of a function (e.g. we set a breakpoint somewhere in main(), and when we compile and download, the breakpoint is moved to the end of main()).

    It sounds like the program was built with optimization enabled (probably at least function level since it moves the breakpoint to the end of the function). As optimization level increases, source level debug capability decreases. Now you mentioned:

    Erik D said:
    . We have tried turning  the optimizations of in the MSP430 compiler, but this does not help.

    How exactly are you disabling them? Are you setting optimization explicitly to "off"? Note that setting it blank is not the same as "off".

    Erik D said:
    reakpoint somewhere in main(), and when we compile and download, the breakpoint is moved to the end of main()). Also, it seems that when this is happening, we are initially setting a S/W breakpoint, but after we click the debug button and it downloads, when we look at the breakpoint in the Breakpoint window, the S/W breakpoint has turned into a H/W breakpoint. We are not sure what we are doing to cause this.

    If the debugger memory map is enabled and the address where you are setting the breakpoint is specified by the memory map as read-only, then the debugger will automatically use a hardware breakpoint. Check the memory map.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 20 points

    Ki,


    Thank you for your prompt reply. We appreciate your reply and help. It seems what was happening was as follows:

    We would be able to set breakpoints at certain points in the code and they would work as expected. We would make some changes, click on the little bug icon to recompile and download, and run the program again to check behavior and utilize breakpoints. If we removed breakpoints from certain parts of the code, and made changes, it seems that what was happening was that the compiler was optimizing away certain parts of the code (keep in mind, this is code that was doing stuff). When we would try to set a breakpoint in the same place in the program as before, if it had been optimized away, there is no code to break and thus no place to put a breakpoint; the breakpoint would then immediately go to the next location that is saw. What we were not doing (which we assumed is the reason this was happening) was cleaning the project every time we made a change and recompiled/downloaded/clicked on the bug icon. Upon cleaning the project, the code that had been optimized away was back and we were able to put breakpoints there.

    Our question now, assuming this is in fact what was happening (which makes sense when examining the assembly code) is: why was the compiler optimizing away things that were being used?


    Thanks again for your help!

    Cheers,

    E

  • 0 in reply to Erik D
    TI__Guru**** 472291 points

    Without a reproducible test case, it is hard to provide any concrete suggestions. Would it be possible to provide one? It doesn't have to be the actual project, just some stripped down example that can still reproduce the problem.

    Thanks

    ki