Comments on Disabling breakpoints in real-time section of firmware
Parent
Disabling breakpoints in real-time section of firmware
Got a question about hazardous breakpoints in real-time 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?
I’ve got an STM32 microcontroller which controls an LED flash. The LED current during the flash is within the LED’s pulse rating, but well above the continuous current rating. There’s a dozen lines of code between beginning of the pulse and the end of the pulse. If somebody (myself most likely) slips and sets a breakpoint when the LED is turned on, and the firmware stops at the breakpoint for one second, then the LED will fry. (No hazard to user. Just damage of the instrument.)
I don’t have a safeguard in hardware which would disable the power stage. Perhaps in the next rev of the board I should add a pulse retriggerable one shot which will disable the power stage.
Post
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. 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?
0 comment threads