*****

Hello Munan, 

As you may already know, the way we can see the HW breakpoints is in the breakpoints tab in the debug section and clearing them from there. However, I have seen an issue similar where the breakpoints issue was resolved by uninstalling and reinstalling the CCS. Can you verify if this works for your scenario?

Also, based on the TRM for MSPM0-C family, it does state in section 3.2 that the number of HW breakpoints, specifically for C, is two hardware breakpoints while the other 4 HW breakpoint references are more of a generalization of the limitations of MSPM0 MCUs. 

Regards, Jojo

Hey Jojo,

So the issue is that you can see the breakpoints that the user has set in code within CCS, but the ones that are set by CCS to enable things like CIO and the breakpoint at program exit are not visible to the user. So on a device like the MSPM0C1104 where there are only 2 hardware breakpoints, this is a pretty big limitation since all or half the breakpoints can be consumed and you wouldn't even know.

Also, the halt at main can take up a breakpoint which becomes an issue if you have 2 breakpoints set in your code and then the program won't halt at main because all the breakpoints will have been consumed. Having a little more visibility into which breakpoints are consumed by system functions could help.

Finally, my last point is for the number of hardware breakpoints we do not specify this in the MSPM0C1104 datasheet anywhere and we should include this if it is different than the number quoted in the TRM.

Munan

Hello Munan, 

Thank you for that information. Let me forward this to the CCS team to verify if, aside the breakpoint section, there is another section or method to know the total hardware breakpoints set at a time for accurate visibility purposes. 

Regarding your last point, I agree that it should be clearer in the TRM regarding the other references but looking at the other datasheets of different MSPM0 devices, it seems hardware breakpoints are not included entirely. I will submit a doc feedback regarding the C family TRM. 

Regards, Jojo

Munan Xu said:

Having a little more visibility into which breakpoints are consumed by system functions could help.

In the Debug Console view, can you run the below command:

DEBUG_DumpBreakpoints()

And check the GEL_Output view, check the output to see the status of breakpoint usage:

Please copy and past the output to a text file and attach the file to this thread.

Thanks

ki

Hey Ki,

I ran the command but it doesn't seem to produce any output:

Munan

That is really odd. Can you provide a full screenshot of the entire IDE? What exact CCS version is being used?

CCS Version:

Details

List of extensions

• @ccs/ccstudio 20.2.0
• @ccs/ccstudio-debug 20.2.0
• @ccs/ccstudio-getting-started 20.2.0
• @ccs/ccstudio-guicomposer 20.2.0
• @ccs/ccstudio-plugin 20.2.0
• @ccs/ccstudio-project 20.2.0
• @ccs/ccstudio-support 20.2.0
• @ccs/ccstudio-trace-config 20.2.0
• @ccs/ccstudio-trace-viewer 20.2.0
• @ccs/ccstudio-updater 20.2.0
• @theia/ai-anthropic 1.58.4
• @theia/ai-chat 1.58.4
• @theia/ai-chat-ui 1.58.4
• @theia/ai-code-completion 1.58.4
• @theia/ai-core 1.58.4
• @theia/ai-history 1.58.4
• @theia/ai-huggingface 1.58.4
• @theia/ai-llamafile 1.58.4
• @theia/ai-mcp 1.58.4
• @theia/ai-ollama 1.58.4
• @theia/ai-openai 1.58.4
• @theia/ai-scanoss 1.58.4
• @theia/ai-terminal 1.58.4
• @theia/ai-workspace-agent 1.58.4
• @theia/bulk-edit 1.58.4
• @theia/callhierarchy 1.58.4
• @theia/collaboration 1.58.4
• @theia/console 1.58.4
• @theia/core 1.58.4
• @theia/debug 1.58.4
• @theia/dev-container 1.58.4
• @theia/editor 1.58.4
• @theia/editor-preview 1.58.4
• @theia/electron 1.58.4
• @theia/external-terminal 1.58.4
• @theia/file-search 1.58.4
• @theia/filesystem 1.58.4
• @theia/keymaps 1.58.4
• @theia/markers 1.58.4
• @theia/messages 1.58.4
• @theia/metrics 1.58.4
• @theia/mini-browser 1.58.4
• @theia/monaco 1.58.4
• @theia/navigator 1.58.4
• @theia/notebook 1.58.4
• @theia/outline-view 1.58.4
• @theia/output 1.58.4
• @theia/plugin-dev 1.58.4
• @theia/plugin-ext 1.58.4
• @theia/plugin-ext-headless 1.58.4
• @theia/plugin-ext-vscode 1.58.4
• @theia/preferences 1.58.4
• @theia/preview 1.58.4
• @theia/process 1.58.4
• @theia/property-view 1.58.4
• @theia/remote 1.58.4
• @theia/scanoss 1.58.4
• @theia/scm 1.58.4
• @theia/scm-extra 1.58.4
• @theia/search-in-workspace 1.58.4
• @theia/secondary-window 1.58.4
• @theia/task 1.58.4
• @theia/terminal 1.58.4
• @theia/test 1.58.4
• @theia/timeline 1.58.4
• @theia/toolbar 1.58.4
• @theia/typehierarchy 1.58.4
• @theia/userstorage 1.58.4
• @theia/variable-resolver 1.58.4
• @theia/vsx-registry 1.58.4
• @theia/workspace 1.58.4

Thanks. I found some strange behavior. It is likely what you are experiencing also.

Can you remove all breakpoints and then terminate the debug session. Then start a new one. Then run the "Debug_DumpBreakpoints() in the Debug Console BEFORE you set any breakpoints and see if you see any output. If you do, then set some breakpoints and see if you still see output.

I think another workaround is to just close and then reopen the GEL Output view. However it seems like the only way to reopen it is with the Command Palette.

Ki said:

However it seems like the only way to reopen it is with the Command Palette.

Actually it is under "View -> Console -> GEL Output".