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.
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
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.
0 comment threads
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?
I have a similar problem when debugging firmware on a dsPIC that drives a flyback power supply. The switch isn't designed to be on for very long, as eventually the inductor saturates. Usually the transistor blows out when it is left on too long. In normal operation, the PWM hardware in the micro guarantees the switch will be on for only a specified amount of time each pulse.
My solution for debugging is to disable the flyback power supply altogether. I have a build-time switch that causes the project to be built for single stepping with an ICD. That switch causes the flyback power supply module to be disabled.
That method allows debugging everything except the flyback power supply itself. Debugging the flyback supply is more tricky, but it's just one module.
In your case, you can do something similar so that you can debug everything except the LED driver. If you really need to debug that, then unsolder the LED, or input to the LED driver, and watch it on a scope instead. If you need to do this often, modify your engineering unit with a jumper or something to disconnect the LED from the drive signal.
Another possibility is to use a current-limited power supply for the LED section during debugging. Set the current limit so that the LEDs can be left on indefinitely without harm. If you're debugging the firmware logic, you probably don't need the full brightness from the LEDs.
0 comment threads
0 comment threads