Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

60%
+1 −0
Q&A Disabling breakpoints in real-time section of firmware

Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section? Generally compilers are completely unaware of debugg...

posted 9mo ago by Gnomo‭  ·  edited 9mo ago by Gnomo‭

Answer
#2: Post edited by user avatar Gnomo‭ · 2023-08-18T06:49:13Z (9 months ago)
  • > Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section?
  • Generally compilers are completely unaware of debuggers. Code and debuggers are supposed to be completely trasparent to each one for obvious reason (you want to code to behave in the same way it always do while you are debugging).
  • But but but
  • (That's not a good practice)
  • Technically it can be feasible programatically. Afaik all debuggers doesn't nothing more than writing and reading on system bus. Taking your specific platform as an example, you can write the same debug peripheral, as the debugger would, to disable all breakpoints before your critical section and then re-enable them at the end. (Provided they are hardware breakpoint, software one are another story)
  • So, depending on your micro, before entering critical code, you could backup the value of FUNCTION field of the DWT_FUNCTIONn registers, disable all the breakpoint putting FUNCTION to zero, and then after the critical code, write back the original value.
  • It is horrible but it works.
  • In practice, most of the time you just want to comment out the row of code that can be problematic. If this is not possible what you need is tracing. So provided that you microcontroller supports it, go get a look about coresight functionalities.
  • > Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section?
  • Generally compilers are completely unaware of debuggers. Code and debuggers are supposed to be completely trasparent to each one for obvious reason (you want to code to behave in the same way it always do while you are debugging).
  • But but but
  • (That's not a good practice)
  • Technically it can be feasible programatically. Afaik all debuggers doesn't nothing more than writing and reading on system bus. Taking your specific platform as an example, you can write the same debug peripheral, as the debugger would, to disable all breakpoints before your critical section and then re-enable them at the end. (Provided they are hardware breakpoint, software one are another story)
  • So, depending on your micro, before entering critical code, you could backup the value of FUNCTION field of the DWT_FUNCTIONn registers, disable all the breakpoint putting FUNCTION to zero, and then after the critical code, write back the original value.
  • There's a small chance that the debugger program you breakpoint while you are in the critical section so you can still burn your led if you put breakpoints while the code in free-running.
  • In practice, most of the time you just want to comment out the row of code that can be problematic. If this is not possible what you need is tracing. So provided that you microcontroller supports it, go get a look about coresight functionalities.
#1: Initial revision by user avatar Gnomo‭ · 2023-08-18T06:45:15Z (9 months ago)
 > Does C have a mechanism which lets me mark a section of code such that breakpoints are somehow ignored or not allowed just in that section?

Generally compilers are completely unaware of debuggers. Code and debuggers are supposed to be completely trasparent to each one for obvious reason (you want to code to behave in the same way it always do while you are debugging).

But but but
(That's not a good practice)

Technically it can be feasible programatically. Afaik all debuggers doesn't nothing more than writing and reading on system bus. Taking your specific platform as an example, you can write the same debug peripheral, as the debugger would, to disable all breakpoints before your critical section and then re-enable them at the end. (Provided they are hardware breakpoint, software one are another story)
So, depending on your micro, before entering critical code, you could backup the value of FUNCTION field of the DWT_FUNCTIONn registers, disable all the breakpoint putting FUNCTION to zero, and then after the critical code, write back the original value.
It is horrible but it works.

In practice, most of the time you just want to comment out the row of code that can be problematic. If this is not possible what you need is tracing. So provided that you microcontroller supports it, go get a look about coresight functionalities.