Post History

Breakpoints are beyond the scope of the C language, so this is up to the specific debugger and CPU core. What you will probably have to do to block accidental breakpoints is to not provide any debug information, so that the debugger won't know which line to place a breakpoint at.

How to do this is very specific to your tool chain, but generally embedded tool chains in debug build spits out an executable with debug information inside (.elf is common). 

If you figure out how to build your program in several steps, then you might be able to compile certain sensitive files as object files - which is the middle step between the compiler and the linker. There will likely be some option to strip debug information, either in the compiler, linker or some other tool [see for example `strip` in Linux](https://stackoverflow.com/questions/1349166/what-is-the-difference-between-gcc-s-and-a-strip-command). This means that the code will still get linked but the debugger has no clue how to associate it with the C code it was based on. The down side is that you won't be able to view or single step through that code on a C level in the debugger either.

I would also suspect that advanced/premium debuggers are likely to have a more convenient solution to the problem.

On the hardware side one might argue if it is wise to have a LED PWM where 100% duty cycle goes beyond the current spec for the LED - the whole reason to drive them with PWM instead of GPIO in the first place is to save current, so why not create a design where 100% duty matches the nominal/maximum current for the LED?