• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 911 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.

CCSv5 breakpoints don't work after code reload

Eddie3909
Guru 10385 points
Other Parts Discussed in Thread: SYSBIOS

CCSv5.5, Windows 7, XDS560v2 Spectrum Digital, Spectrum Digital Emulators 5.2.0.12, C6472, CGT 7.2.6, SYSBIOS 6.35.4.50, XDCtools 3.25.3.72, IPC 1.24.3.32

Hi

After setting breakpoints in my code, I can select run and CCS stops at the breakpoint. But after reload, its seems random whether or not the breakpoints will be hit. 

The little blue icon on the left column is still present when I view the code.

I've ensured I'm using the HW breakpoints.

Deselecting and then re-selecting the breakpoint in the view->breakpoints tab does not appear to consistently work.

The only solution I've found is to manually toggle the breakpoint by double clicking on the left hand column in the edit window.

The breakpoints worked fine in CCSv4.

I've built my code to run on only two cores. I've "grouped" the two cores and select the "Group 1" to do the reload.

Optimizations are disabled for the file containing breakpoints.

Any thoughts, suggestions, fixes, patches, ideas on how to get this working like CCSv4?

(my colleagues also see the same issue)

Cheers2u

Eddie

  • 0
    TI__Guru**** 467491 points

    Hi Eddie,

    Here is my environment I used when trying to reproduce your issue:

    CCSv5.5, Windows 7, XDS560v2 Spectrum Digital, Spectrum Digital Emulators 5.2.0.12, TI Emulators 5.1.507.1, C6472, CGT 7.4.4 & 7.2.3, SYSBIOS 6.35.4.50, XDCtools 3.25.3.72, IPC 1.24.3.32

    The only difference is the CGT versions where I tried both 7.4.4 and 7.2.3 w(which behaved the same) but i don't think this is the reason for the issue. I mentioned the TI Emulator version because the XDS560v2 uses TI drivers (regardless of the vendor).

    I was not able to reproduce the issue as you reported, the only issue I see is sometimes after reload, one of the breakpoints will get disabled in the breakpoints view. So I have to re-enable it. Once that is done, the breakpoints are always reached.

    This is what I did to reproduce the issue.

    1) SYS/BIOS program is loaded on to only the first two cores.

    2) These first two cores are grouped together into a single debug group "Group 1"

    3) A hardware breakpoint is set for each core in the group and the program is run. Execution for each core stops at the breakpoint that applies to it

    4) programs are reloaded by selecting the group and doing 'Load-> Reload Program"

    5) sometimes the breakpoint for one of the cores (usually the first) gets disabled and I need to re-enable it in the Breakpoints view

    6) I run the group again and both cores correctly reach the breakpoint that applies to them

    I repeated steps 4-6 many times. Everytime the breakpoints were reached as long as I made sure the breakpoints were enabled.

    Is there something in my steps that is missing in yours or does it look similar?

    Thanks

    ki

  • 0 in reply to Ki
    Guru 10385 points

    Hi Ki-Soo

    Ki-Soo Lee said:
    5) sometimes the breakpoint for one of the cores (usually the first) gets disabled and I need to re-enable it in the Breakpoints view

    That doesn't seem to work for me. I have to toggle (remove) the breakpoint and then set it again. That said, this doesn't happen to me a lot, so I'm going to live with it.

    What I found out from my co-workers is that they use double click for setting the breakpoint (this is how they did it on CCSv4). I've switched 100% to HW breakpoints by first selecting the core and then right clicking on the column adjacent to the code where I want the breakpoint, then selecting the HW breakpoint option.

    I think the issue is that we're used to simply double clicking in the column. That method creates a software breakpoint??

    Hardware breakpoints definitely work better. It there a way to configure CCS so that is sets a HW breakpoint when double clicking?

    Another thing I noticed that is different in CCSv5 compared to CCSv4 is that the editor doesn't open the file at the place you've hit the breakpoint. In CCSv5 you have to select the line of code in the debug window.

    Cheers

    Eddie

  • 0 in reply to Eddie3909
    TI__Guru**** 467491 points

    Eddie3909 said:
    I've switched 100% to first selecting the core and then right clicking on the column adjacent to the code where I want the breakpoint, then selecting the HW breakpoint option.

    This is what I do too.

    Eddie3909 said:
    I think the issue is that we're used to simply double clicking in the column. That creates a software breakpoint??

    It depends... if the debugger memory map specifies that program memory location as writable, then it will default to a software breakpoint. If the debugger memory map says that it is read-only, then it will automatically use a hardware breakpoint. If no debugger memory map is used (or that region is not defined in the map), then it will assume the memory is writable.

    Eddie3909 said:
    Hardware breakpoints definitely work better. It there a way to configure CCS so that is sets a HW breakpoint when double clicking?

    If the memory is writable, then it will always default to a software breakpoint. I don't think you can change this behavior. Sorry

    Ok, so I'm a bit confused now. You mentioned that you confirmed you are using HW breakpoints but then you mentioned that you have double-clicked in the editor margin to reset breakpoints (which I assume is defaulting to SW) but then also that you right-click on the column and use the option to explicitly set HW breakpoints. Which types of breakpoints is causing the problems?

  • 0 in reply to Ki
    Guru 10385 points

    Hi Ki-Soo

    Sorry for the confusion,

    My co-workers have been using the double click to set the break-point. As you stated, this is creating a SW breakpoint. 

    We will all switch to HW breakpoints now in order to get consistent behavior.

    Thanks for your help!

    Cheers

    Eddie