2023-02-13 03:28 AM
2023-02-20 03:14 AM
Hello,
If you are using an Advanced Timer to generate the PWM channels, you benefit from its Debug mode. On a breakpoint, the timer can be configured to either stop counting or carry on counting. This is configured in the debug module. On STM32G4xx and STM32F3xx MCUs, if the timer counter is stopped on a breakpoint, its output is disabled.
So, there is no need to ask STM32CubeIDE to disable the PWM output on a break point, this can be done directly by the MCU itself.
Now, breaking the software while the motor is controlled can be dangerous as it may result in high currents that may destroy the boards and/or the motor. If you really need to do so, it is strongly recommended to set a maximum current limit on your power supply.
Best Regards,
Fred.
2023-02-21 01:09 AM
Hello,
Thank you for your reply. Indeed, it is not recommended to place breakpoints while the motor is running. But sometimes, it happens forget a breakpoint, do a bad manipulation or a bug and the program can stop while the engine is running. On certain IDEs like those of RENESAS, for example, you can configure the debugger to launch a function (written by the programmer who codes what he wants in his function, even the launch of a measurement) automatically after stopping the program whatever the event (breakpoint, Stop, Pause, bug etc...), Is CUbeIDE able to do it ? because it is a very robust debugging option to avoid breaking MOS. THANKS
2023-02-21 02:28 AM
Hello,
What about using the Debug mode of the Advanced Timer as proposed in my previous answer? If you use either a G4 or an F3, it would do the same as what the debugger would do. Now, if you really need to do this through the debugger, I cannot help you there. I'll let others provide the information.
Best Regards,
Fred
2023-02-21 05:40 AM
Hi @Fred V. ,
Are you talking about this:
For safety purposes, when the counter is stopped (DBG_TIMx_STOP = 1), the outputs are
disabled (as if the MOE bit was reset). The outputs can either be forced to an inactive state
(OSSI bit = 1), or have their control taken over by the GPIO controller (OSSI bit = 0) to force
them to Hi-Z.
?
Is this only in the 'F3 and 'G4 mcus?
Is this only in the Advanced Timers (TIM1, TIM8, TIM20)?
I'd recommend to add this to the overall block schematics of these timers, it may be quite surprising to the unaware.
JW
2023-02-21 07:25 AM
This "call on breakpoint" methodology isn't particularly prevalent.
Generally there are a lot of systems where dead-stopping like this can be catastrophic.
Here its perhaps best to instrument, and have an emergency stop button via a high priority EXTI, or wrapping breakpoints in a routine that gets the system into a safe/safer state before trapping to the debugger.
Also wrap any hard fault or error handlers so they fail safe too.
Output trace, diagnostic and telemetry so behaviour can be characterized.
TBH understanding program logic and flow should be done earlier.
2023-02-21 07:57 AM
Hi @waclawek.jan,
I am indeed talking about this. The Debug Mode seems to exist on all timers (usually described the last sub-section of the functional description of the timer. However, the safety behavior you mention is not. You can find it on Advanced Timers, HR Timers and some GP Timers of the STM32F3, F7, G0, G4 and H7. It is not present on F0 and F4. I did not check the other series.
BR
Fred
2023-02-21 08:13 AM
Thanks, @Fred V. .
> It is not present on F0 and F4
Indeed, RM0091 for 'F0 does not mention it, but:
I guess you've checked some other 'F4 then the "classics" covered by RM0090, in which case determining whether this feature is or is not present may be more tricky than I thought...
JW
2023-02-21 10:39 PM
Back to the original question: ".. would like to launch a function automatically when my program stops after a breakpoint"
Yes, that can be done with STM32CubeIDE's debugger gdb. The Debugger Console View in STM32CubeIDE is needed to enter interactive commands.
Prepare a C function that should be called, for testing I used blink() which blinks a LED few times.
Make sure that the function is not optimized out by the complier/linker, e.g. by calling it once in the code or some tool magic.
Start debugging, set a breakpoint and stop at it. Debugger Console output like:
Temporary breakpoint 2, main () at ../Core/Src/main.c:78
78 HAL_Init();
Breakpoint 1, main () at ../Core/Src/main.c:104
104 printf("Hello\n");
enter:
commands 1
> call blink()
> end
next time you stop at breakpoint 1, the function will be called.
Notes:
get more help from the Debugger Console:
help commands
help commands
Set commands to be executed when the given breakpoints are hit.
Give a space-separated breakpoint list as argument after "commands".
A list element can be a breakpoint number (e.g. `5') or a range of numbers
(e.g. `5-7').
With no argument, the targeted breakpoint is the last one set.
The commands themselves follow starting on the next line.
Type a line containing "end" to indicate the end of them.
Give "silent" as the first line to make the breakpoint silent;
then no output is printed when it is hit, except what the commands print.
help call
Call a function in the program.
Usage: call EXP
The argument is the function name and arguments, in the notation of the
current working language. The result is printed and saved in the value
history, if it is not void.
hth
KnarfB
2023-02-22 01:09 AM