Hi, I'm trying to figure out why my basic timer interrupt on the STM32H7B3x dev board isn't working as expected. It seems to be triggering more often than I expect depending on when I clear the flag within the interrupt.

There is a delay when the flag is cleared last such that the interrupt is re-entered, although the flag is cleared. If you were checking for the flag explicitly before performing the action, you wouldn't see this effect (although it would still eat up CPU cycles).

Here is @Community member​'s writeup:

http://efton.sk/STM32/gotcha/g7.html

Hi TDK, many thanks for helping.

I have seen this kind of approach (the one you suggested) on some of the ST examples but questioned why they do it this way - It's something that isn't required on other micros.

So - to try and further understand this, if I add a checking instruction (to check the flag) as soon as I enter the IRQ, doesn't this also add a delay (and hence the IRQ will be re-entered)? Or are there certain instructions that should be used as soon as the IRQ are entered to facilitate this?

I'm happy to use this approach for this IRQ (and others?) but question it's robustness? How do I know it will ALWAYS perform this way?

Again, thanks for your engagement on this, it's quite baffling at the moment but I'm sure there is a good reason for it all...

Why would checking for the flag not be robust? The flag behaves as expected. It's just that the interrupt is just re-entered if it's cleared last.

ST's examples check the flag because there are typically many flags which cause the interrupt to fire and it has to figure out which one did it.

Make sure you read the writeup I added to my first post.

Also note that to clear a specific flag, you write a 0 to that bit. There is no need to perform a read-modify-write.

TIMx->SR = ~TIM_SR_UIF;

Hi TDK,

thanks for your reply; I think I understand what you're saying:

When I clear the flag, there is a delay to when the flag actually gets reset. If this instruction is near the exit of the IRQ handler, then there is a time period (after the PC has started to unravel the stack) where the flag is actually still set (due to delay 'lag'), therefore it gets re-entered.

So, I've just tried adding some small delay after the flag clear code and it now works as expected.

It makes sense, but does this mean that the hardware for the IRQ flag bit isn't clocked on the same CPU clock? Is it maybe because the timer register is on a separate bus (APB1) therefore possibly slower than the core clock? If so, then I need to be very careful about any peripheral register modifications in real-time?

again, thanks for your input and this is valuable info going forward; it would've taken me ages to get to this point without your help.

regards

> You could perhaps use a fencing instruction like __DCB() to ensure completion.

That does not guarantee anything beyond the processor core, i.e. it ignores the resynchronizers on AHB/APB bridges (and in the overcomplicated 'H7 also the inter-matrix resynchronizers), write buffers on the AHB/APB bridges, the peripheral-to-NVIC delay/resynchronization, NVIC's internal delays, and whatnot.

It may "work" but only coincidentally, simply as "any" delay.

Qualifying the interrupt source works, as writes and reads to the same peripheral are never reordered (pending the peripheral area is tagged as Device in MPU, which it by default is).

JW

> my take-away from this is that for any time-critical regions of code that write to peripheral registers, always read it back to ensure its state is known before relying on it to do something else?

There may be some registers where this is needed, but they are few and far between and I don't think they include the status flags. Just clear the flag at the beginning of the ISR and do your other stuff after that. If your ISR is extremely short, perhaps also check for the relevant flag before assuming it is set. Your ISR right now just increments a variable, but since you can use a timer to achieve the same thing, surely you must be putting more code in there eventually.

> So Jan, are you saying that the 'correct' method of handling the flag to guarantee deterministic performance is to first write to the flag (to reset it), then to subsequently read it back again?

That will make sure that the flag has been cleared by the time execution proceeds beyond the readback, yet unfortunately it won't guarantee the flag's clear reaches the NVIC before effective exit from NVIC, i.e. it won't ensure the "redundant" interrupts to happen. In that writeup TDK linked above there's a link to a thread dealing just with that.

The recommended procedure is to read the flags at the beginning of the ISR, check, if the appropriate flag is set, and only if set, clear it and execute the rest of the ISR. The rationale is, that "whatever" you do, you won't prevent the ISR to be entered falsely again, but checking the flag makes sure it was not a "legit" interrupt so you then leave early.

As TDK said, with any nontrivial ISR just clearing the flag early will be most probably fine, but the above procedure is peace of mind. And, at the end of the day, most nontrivial interrupts handle several sources so you'll end up checking the flags anyway.

JW