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.

CCS does not stop at desired breakpoihnt

Other Parts Discussed in Thread: MSP430F67791A, MSP-FET

Dear CCS Team

One of my customer is working on MSP430F67791A. They have close to 400KB software size and have a issue with the breakpoint. They are able to run the software without any issue, but when they place a breakpoint to anywhere in the code, CCS does not stop at the breakpoint and goes to different location. The issue is that they are not able to put a breakpoint to the desired point. Please note that they disabled the optimization and see the same issue.

Could you please help?

Best Regards

Yunus

  • Hello Yunus,

    Yunus Karaborek said:
    Please note that they disabled the optimization and see the same issue.

    Thanks for confirming this. This was my first thought.

    Yunus Karaborek said:
    but when they place a breakpoint to anywhere in the code, CCS does not stop at the breakpoint and goes to different location.

    If they are setting the breakpoint via double-click in the editor margin of the source code, it could be there is some source code correlation issue - that the source file open in the editor is a different revision than what was used to build the loaded debug symbols. This can happen if you have multiple versions of the same source file around and the debugger is picking up the wrong one.

    Yunus Karaborek said:
    CCS does not stop at the breakpoint and goes to different location.

    Can you clarify exactly what happens here? Does the breakpoint appear to get set in the correct location in the source but when the code halts, it is in some other part of the source?

    Also what happens if they set a breakpoint on an address via the Breakpoints view? Does it halt at the correct address?

    Thanks

    ki

  • Hi Ki

    Please see below their feedback:

    firstl i don't use multiple version of the same sour code. i am just using one version for the sour code and there is a only one file with the same name. Therefore its not possible picking up the wrong one.

    secondly, yes it does. the breakpoint appear the correct location in the source code but when the code halts, the step location is wrong. this step location is some times our sour code and some times TI library source code.

     

    This point needs to be clarified. i have just only one version of the source code and there is only one file with the same name in working directory. event I sent one video file via whatsapp to clarify. you can see what happens.

     

    Could you please comment?

    Best Regards

    Yunus

  • Hi Yunus,

    Yunus Karaborek said:
    "event I sent one video file via whatsapp to clarify. you can see what happens."

    I would like to see this video also. Can you provide a link to me? If you wish to share it privately, send me a private message.

    Thanks

    ki

  • Hi Ki
    I send it to you directly
    Many thanks
    Yunus
  • Hello Yunus,

    Check to see if your customer is setting a breakpoint in code that was copied to RAM at startup? If so, they will first have to run to a point immediately after RAM copy function (i.e. memcpy(..)).

    Stephen

  • Hello CCS Team

    Please see below the video to see the issue. Could you please help?

    https://www.dropbox.com/s/ephhdr0023ihlih/VID_20161212_095951.3gp?dl=0

    Best Regards

    Yunus

  • Hi Yunus,
    I took a look at the video. I was trying at the office but it kept complaining about the link. Then I realized that dropbox is blocked at work so I was able to access it at home. Just for future reference, dropbox is not the best way to provide files to us.

    This was my observation from watching the video:
    -I do not see any evidence of a breakpoint set. The Breakpoint view is empty and there is no breakpoint icon in the editor margin. The menu item to remove all breakpoints is disabled.
    -The target appears to halt on its own at source line 16684
    -Customer ran the target a few times and it kept halting at the above location
    -The debug view shows the target halted at a "HW Breakpoint"

    What I don't see is the customer setting a breakpoint on his own. I assume he skipped that in the video. Where and how does he set the breakpoint? And when he sets it, is there any response confirming that one was set (i.e. breakpoint icon appears in the editor margin)? And if they don't set this breakpoint, then there is no halting of the code at 16684?

    Thanks
    ki
  • Hi Ki

    I will send a seperate videos by e-mail using BOX. Could you please check and let me know the feedback?

    Best Regards

    Yunus

  • Hi Yunus,
    Thank you for the video. This shows the behavior as you described. Enabling the breakpoint halts the target at a different location. And since optimization is disabled and they are sure that the correct source files are being referenced, it is a very strange behavior indeed. I will likely need a test case for further investigation. Can the customer provide one? Executable and source files? I don't have the target myself so I will need to acquire one from the MSP team. Or perhaps they can help me reproduce the issue. I will also ask the debugger team if they can think of any scenarios where such issue can occur.

    Thanks
    ki
  • Hi Ki

    My customer told me that they see this issue when they run the entire project which is about 400K Byte and they can not share the compete code unfortunately. What I can do is to work with them to debug the issue. Could you please let me know which point do you want me to try? Or you can connect to their PC via Webex to debug the issue.

    Please let me know

    Best Regards

    Yunus

  • Ki-Soo Lee said:
    Enabling the breakpoint halts the target at a different location. And since optimization is disabled and they are sure that the correct source files are being referenced, it is a very strange behavior indeed.

    Maybe performing the following would help to identify what is going wrong during the debug session:

    1) Running the following command in the scripting console to dump a list of known breakpoints:

    js:> eval("DEBUG_DumpBreakpoints()")

    2) Enabling Debug Server Logging

    Not sure if the problem is CCS setting an incorrect breakpoint, or the device is halting at the wrong breakpoint. The problem might be in the debug probe, so:

    - Which debug probe is the customer using (e.g. new MSP-FET or old MSP-FET430UIF)?

    - What exact version of CCS is being used?

    - What version of the MSP430 Emulators and Device Support Files and TI Emulators are installed?

  • Hi Ki

    The issue is related to CCS revision. They tested V6.1.2 and have not seen any issue, but they will have to continue with the latest version of CCS even if they see the breakpoint issue. I think that we need to identify the issue and fix on the latest CCS. Regarding to the register content, they found a workaround. Could you please work with CCS team if we can fix this issue on the latest version?

    Best Regards

    Yunus