G431 does not behave as expected, when debugging a breakpoint in interrupt

[Tobe]

I have a breakpoint in the interrupt, but when i debug this point, the scope does not show the signal (red) as expected.It should be high and not low, as you can see in the picture.

[waclawek.jan]

Maybe DBGMCU_APBxFZR1.DBG_TIMx_STOP is set. Maybe it's set by the debugger itself; it may have some tickbox for this.

Debugging is intrusive.

JW

[Tobe]

No stop bits are set. Only DGB_SLEEP, DGB_STOP and DGB_STANDBY.

Why would it stop, and then take 30ms to get into the interrupt? That is a long time, also for debugging i would say. Then debugging would not really work on this point, as there is stuff beeing executed 30ms away, form where it should have happend.

[waclawek.jan]

You have never explained what is "red signal", what's the expected behaviour and why do you think it's different from the observed one; e.g.

> the scope does not show the signal (red) as expected.It should be high and not low, as you can see in the picture.

I see it being both low and high, successively.

Also, you did not explain, why do you think it takes 30ms to get interrupt.

So, I was left with a guess. And, guess what, that guess was incorrect.

JW

[Tobe]

The red signal shows the interrupt activity (high for inside of interrupt).

The program (debugger?) does stay out of the interrupt for 30ms (read from scale of scope) when it should not (green line is input for interrupt).

Now i have attached another picture:

The program stays outside of interrupt for 30ms, but then fires one interrupt, leaves the interrupt, but then goes back into it again and stops at the breakpoint.

[waclawek.jan]

> The program (debugger?) does stay out of the interrupt for 30ms (read from scale of scope) when it should not (green line is input for interrupt).

OK so you have some program - e.g. interrupt with higher or same priority as the interrupt in question - which lasts 30ms under some circumstances.

Or, if you've just clicked breakpoint in the debugger at that moment, it might've been that the debugger stopped execution for 30ms so that it could insert the breakpoint.

JW

[Tesla DeLorean]

Please stop using RMW on the TIM->SR register

ie #define CLEAR_BIT( REG,   BIT  )    ((REG) &= ~(BIT))

TIM->SR = ~1; // A simple write to clear UPDATE source

Using RMW has secondary effects, including a race condition that can cause you to miss other interrupts that pend in the 8+ APB cycles that's going to take.

[Tobe]

Its the "Or". (30ms for a interupt at 170Mhz would be quite a beast 😉 -  an ugly one )

Yes, i have activated the breakpoint to jump into it, i guess then your right. This is inserting the breakpoint.

I have now put in some extra code to have a breakpoint without the above issue.

[Tobe]

Please explain to me what RMW means, then id be happy to follow your suggestion, if it seems reasonable to me.

TIM->SR = ~1; // A simple write to clear UPDATE source

I must confess, that i also dont know what it does.

[waclawek.jan]

~ in C is bitwise NOT, i.e. it inverts all the bits of given word.

~1 thus is 0xFFFF'FFFE.

The above notation clears TIMx_SR.UIF. Read TIMx_SR bits description in the RM; also the meaning of abbreviations which are next to the register bits such as rc_w0, they are given at the very beginning of the RM.

A writeup why you should not use RMW (Read-Modify-Write) operations to clear TIMx_SR here.

JW