Breakpoint Cannot Be Hit

0 views

Skip to first unread message

Claudio Davey

unread,

Aug 4, 2024, 7:34:57 PM8/4/24

to neouwestsunring

Iget this message "Breakpoint Manager: Error enabling this function: This task cannot be accomplished with the existing AET resources." when I try to set a breakpoint in CCS V6.1.0, and I've never seen it before.

Hi Geoff,

Breakpoints can be the most efficient way of debugging certain issues and having only 2 can be a limitation.

In some situations, utilizing the real-time debug capability of the device can remove the need for hardware breakpoints. It is a different approach to debugging, but is sometimes applicable.

Outputting signals via GPIO outputs can also help during debug.

We are investigating and looking to increase the amount of hardware breakpoints available on future C2000 products.

Thank you,

Brett

Geoff,

Some thoughts:

-Can you toggle a GPIO or change a variable inside the ISR to definitively prove that the CPU is entering the ISR?

-Can you set breakpoints elsewhere? Do they work as expected?

-Have you made code changes, but have not compiled/reloaded your program? (when I run into what you're seeing, this is often my problem)

Thank you,

Brett

When I startup the debugger often I got this error message. With only the stop button active. So I have to stop the debugger, disable the breakpoint(1) and start the debugger again. Then the debugger start properly, I enable the breakpoints and continue.

The reason why it all works when you shut down the debugger and disable your breakpoint and start the debugger again is because there is one breakpoint available for the autorun step. So it will use the breakpoint to autorun to 'main' and then free up the breakpoint resource for you to use to re-enable your manual breakpoint.

Another thing you can do is to not have the debugger re-enable manual breakpoints set from the last session. That way, when you start a debug session, it will automatically disable your manual breakpoint so that it can run to 'main'. Then you can enable it after it is at main and all will work:

I had this same issue when I had the project open in two instances of Visual Studio. The project which I was not debugging had a lock on the file and notifying me "This file has been modified outside of the source editor." After accepting the changes in my non-debugging solution, I no longer received the error and my breakpoints were hit in my solution I was debugging.

I got this problem when I created a breakpoint using the Ctrl+B shortcut (see image attached), and I entered a name of a function which doesn't exist, so the breakpoint was added but caused an error. then each time I started the project it appeared that error.

Further to your update about the DLL being optimised the lines you have indicated where breakpoints don't work will likely be optimised away as your entire switch statement does not do anything other decide whether or not to assign a value to a variable that is never used and does not live beyond the scope of the switch statement. As such the compiler will simply not generate any code for the switch statement as it does not do anything at all or the jit just gets rid of it at run time for the same reason.

I just had a similar experience and the way I worked through it was to put a breakpoint at the spot where the routine was called and then single-stepped into the routine until I saw exactly what it thought it was doing. In my case, there was a return that was preventing all the code in the routine from running, so the optimizer tossed it all out. Sometimes it's the stupid things, right? Anyway, if you start at a level higher in the call stack and step into the routine where the problem is, the reason for the problem might become more obvious.

Another cause of this issue I have just found if you are debugging against CRM is not updating the plugin registration points. Even if you copy the new DLLs to the target machine and attach remotely to that process that is not the DLL CRM will use. CRM will try to take a copy of an old version from its database until you rerun the plugin registrations.

If the line number (where is the breakpoint set) is greater then 512, than you can't debug. I simply reorganized my code, to be earlier that part with breakpoint and magically debugging is working again...

I recently had the same problem, in my case it was because I had the wrong file extension on the file(s). It was added to the project and was compiling correctly, but I was unable to set a breakpoint.

Breakpoints do not work when using VS Code Debug this method feature on a ClassMethod. Debug runs like normal and I can sometimes see 'running' on the CALL STACK menu. In the BREAKPOINTS menu, the breakpoints will start red, like normal, but eventually turn gray. On-hover for a grey breakpoint is the message "Breakpoint Cannot Be Mapped". After the method finishes, the breakpoint turns red again. No error messages appear. This is an intermittent issue, as sometimes it runs fine. So far, I have not been able to figure out the conditions to re-create this issue.

1: ^IRIS.Temp.Atelier("debug") = 1

2: ^IRIS.Temp.Atelier("debug",127434) = 1

3: ^IRIS.Temp.Atelier("debug",127434,1,0) = 42

5: ^IRIS.Temp.Atelier("debug",127434,1,2) = "Received:feature_set -i 1 -n max_data -v 8192"

6: ^IRIS.Temp.Atelier("debug",127434,1,3) = "Calling state feature_set"

7: ^IRIS.Temp.Atelier("debug",127434,1,4) = "Event:feature_set"

8: ^IRIS.Temp.Atelier("debug",127434,1,5) = "Received:feature_set -i 2 -n max_children -v 32"

9: ^IRIS.Temp.Atelier("debug",127434,1,6) = "Calling state feature_set"

10: ^IRIS.Temp.Atelier("debug",127434,1,7) = "Event:feature_set"

11: ^IRIS.Temp.Atelier("debug",127434,1,8) = "Received:feature_set -i 3 -n max_depth -v 2"

12: ^IRIS.Temp.Atelier("debug",127434,1,9) = "Calling state feature_set"

13: ^IRIS.Temp.Atelier("debug",127434,1,10) = "Event:feature_set"

14: ^IRIS.Temp.Atelier("debug",127434,1,11) = "Received:feature_set -i 4 -n notify_ok -v 1"

15: ^IRIS.Temp.Atelier("debug",127434,1,12) = "Calling state feature_set"

16: ^IRIS.Temp.Atelier("debug",127434,1,13) = "Event:feature_set"

17: ^IRIS.Temp.Atelier("debug",127434,1,14) = "Received:feature_set -i 5 -n debug_target -v_base64 VlVNQ1BSSU1BUlk6IyNjbGFzcyhWVU1DLlV0aWxpdHkuQ2VybmVyTGFiRnVuY3Rpb25zKS5WVU1DU2VsZWN0UGVyZm9ybWluZ0xhYkFyZWEoIk9SRDAwMDAzMTQiLCJFRFAiLCJTVCIp"

18: ^IRIS.Temp.Atelier("debug",127434,1,15) = "Calling state feature_set"

19: ^IRIS.Temp.Atelier("debug",127434,1,16) = "Launching: ##class(Custom.Utility.Functions).SelectArea(""arg1"",""arg2"",""arg3"")"

20: ^IRIS.Temp.Atelier("debug",127434,1,17) = "PID 130498"

21: ^IRIS.Temp.Atelier("debug",127434,1,18) = "Debug Device Name:TCP34811"

22: ^IRIS.Temp.Atelier("debug",127434,1,19) = "Event:feature_set"

23: ^IRIS.Temp.Atelier("debug",127434,1,20) = "Received:breakpoint_list -i 6"

24: ^IRIS.Temp.Atelier("debug",127434,1,21) = "Calling state breakpoint_list"

25: ^IRIS.Temp.Atelier("debug",127434,1,22) = "Event:breakpoint_list"

26: ^IRIS.Temp.Atelier("debug",127434,1,23) = "Received:breakpoint_set -i 7 -t line -s enabled -f dbgp://PRIMARYCustom.Utility.Functions.cls -m SelectArea -n 1"

27: ^IRIS.Temp.Atelier("debug",127434,1,24) = "Calling state breakpoint_set"

28: ^IRIS.Temp.Atelier("debug",127434,1,25) = "mapping: PRIMARY:Custom.Utility.Functions.cls:SelectArea:1 -> :-1"

29: ^IRIS.Temp.Atelier("debug",127434,1,26) = "Event:errorBreakpoint Cannot Be Mapped"

30: ^IRIS.Temp.Atelier("debug",127434,1,27) = "Received:breakpoint_list -i 8"

31: ^IRIS.Temp.Atelier("debug",127434,1,28) = "Calling state breakpoint_list"

32: ^IRIS.Temp.Atelier("debug",127434,1,29) = "Event:breakpoint_list"

33: ^IRIS.Temp.Atelier("debug",127434,1,30) = "Received:run -i 9"

34: ^IRIS.Temp.Atelier("debug",127434,1,31) = "Calling state run"

35: ^IRIS.Temp.Atelier("debug",127434,1,32) = "IsStopped"

36: ^IRIS.Temp.Atelier("debug",127434,1,33) = "Location zDebugStub+40:%Debugger.System.1:0:0:0:0:6:0:0:0:0:0:PRIMARY"

37: ^IRIS.Temp.Atelier("debug",127434,1,34) = "Stack 3^zDebugStub+40^%Debugger.System.1"

38: ^IRIS.Temp.Atelier("debug",127434,1,35) = "Ran Off End"

39: ^IRIS.Temp.Atelier("debug",127434,1,36) = "FlushOut"

40: ^IRIS.Temp.Atelier("debug",127434,1,37) = "Timed out"

41: ^IRIS.Temp.Atelier("debug",127434,1,38) = "IsStopped"

42: ^IRIS.Temp.Atelier("debug",127434,1,39) = "Event:stop"

43: ^IRIS.Temp.Atelier("debug",127434,1,40) = "TidyUp: 1"

44: ^IRIS.Temp.Atelier("debug",127434,1,41) = "Exiting"

45: ^IRIS.Temp.Atelier("debug",127434,1,42) = "OnClose"

@Zach McKinney

Thanks for log output. Have you compiled that class? The "Breakpoint Cannot Be Mapped" error means that the debugger couldn't map that location in that class to the generated INT routine.

This may seem trivial, but after a lot of headscratching with the same issues as you mention, I found out that my build was set to "release" instead of "debug" when I tried debugging.. re-building the solution for "debug" fixed it, and I could set breakpoints as normal

I had a similar issue with breakpoints failing to bind, as well as certain local variables not evaluating in the Locals window. What finally fixed it was enabling the "Suppress JIT optimization on module load (Managed only)" option in the Options->Debug->General tab. Once I set that it was able to bind without issue.

I know this is an old post but in case all the other tricks above don't work for you make sure the image you are trying to debug is current. For some reason after publishing and transferring a .NET Core project to my Raspberry Pi 'unzip' on the RPi was not copying and overwriting some DLLs in the working directory. When I attached the debugger thinking everything was OK some breakpoints were getting hit, others were not and some others were giving me the "can't bind" error. Once I resolved the unzip issue all my breakpoints and symbols came back. I hope this helps.