Freeze timers in breakpoints

[pa_it]

Posted on April 25, 2013 at 17:15

Hi all

I've tried to debugg a controll-function, but this is impossible because the timers (one create ticks and the oder count them) are running while the programm is freezed in a breakpoint.

The stdPeriph_lib has some function to modify DBGMCU_APB1_FZ (STM32F0) and the oder registers, but they are only writtable from the debugger.

Where could I set these options? I've looked for it in IAR Workbench, CooCox and Atollic and there is no possibility to enable/disable the timers for the st-link debugger.

Can anyone tell me, how I could do this (everytime disable all timers before the breakpoints is reached and then enable the timers again isn't the solution)?

Best regards

Patrick

[Tesla DeLorean]

Posted on April 25, 2013 at 18:19

Like adding

DBGMCU_APB1PeriphConfig(DBGMCU_TIM2_STOP, ENABLE);

in main()?

[pa_it]

Posted on April 25, 2013 at 20:41

This was the first thing I've tryed because it seems very handy. But there was no effect. Why? Take a look at the datasheet:

''The register is asynchronously reset by the POR (and not the system reset). It can be

written by the debugger under system reset.''

None of these debug-register can be written in the user software, or the iar-compiler cand hadle this.

I've now some new Informations: STM32F0 with IAR don't work. STM32F4 with CooCox works. Hm this sucks.

[Tesla DeLorean]

Posted on April 25, 2013 at 22:01

I'm not sure how the reset impacts this unless you're going into STANDBY, but that's not very debugger friendly anyway.

You should definitely be able to program these, if the IAR debugger subsequently muddles with them, well that's an issue to take to IAR support. I might try this in Keil on the STM32F0-Discovery if I get a moment.

Grinding the system to a halt in a debugger isn't safe for a lot of things (machines in motion), is there some way to understand the code outside the system, or output telemetry so you can monitor the dynamic performance of the code/operation?

[carsten]

Posted on November 01, 2013 at 07:53

Hi together,

I have the same problem with the STM32F05. I use the KEIL uVision 4.2 for degugging. It seems that the DBGMCU registers are not possible to write from software and from debugger as well.

@Clive1: Did you test it with Keil and the Discovery Board? Any news about to this topic?

I thinkt this is a normal function to freeze all timers/watchdog during debugging. It was no problem with the STM32F103.

Thank you for your help.

[Tesla DeLorean]

Posted on November 01, 2013 at 15:44

Keil 4.20 is a bit antiquated, predating the F0 by 2 years, I have 4.71 on the bench here, and it seems capable of reading/writing to the DBGMCU registers on a STM32F0-DISCO. I don't have a serial port, and it doesn't support SWV, so haven't spent a lot of time reviewing it's behaviour on/off the debugger.

[carsten]

Posted on November 04, 2013 at 13:40

Hi Clive1, Thank you for feedback.

I use at well 4.71.2.0. Sorry for wrong information.

How did you test it? How did you see that it works?

(Timer or Wdg?)

If I use function below (main)

DBGMCU_APB1PeriphConfig(DBGMCU_IWDG_STOP, ENABLE);

I have no success in periheral register (system viewer).

Thank you.

[Tesla DeLorean]

Posted on November 04, 2013 at 15:53

I'll pull the code, in transit right now. Make sure you have enabled the DBGMCU clock.

{
char String[64];
DBGMCU->APB1FZ = 0;
RCC_APB2PeriphClockCmd(RCC_APB2Periph_DBGMCU, ENABLE);
sprintf(String, ''%08
X'', DBGMCU->APB1FZ);
USART_OutString(String);
DBGMCU_APB1PeriphConfig(DBGMCU_TIM2_STOP, ENABLE);
sprintf(String, ''%08
X'', DBGMCU->APB1FZ);
USART_OutString(String);
DBGMCU_APB1PeriphConfig(DBGMCU_TIM3_STOP, ENABLE);
sprintf(String, ''%08
X'', DBGMCU->APB1FZ);
USART_OutString(String);
}

[carsten]

Posted on November 05, 2013 at 08:17

Thank you.

The DBGMCU clock was the problem, stupid.