Posted by dautrevaux on 2020-04-24 16:25

Sorry, but if you had a bouncing issue, you would have exactly what you describe:

1. PRX goes from OFF to ON, generating interrupt that goes through the THEN part (setting Finstance to X
2. PRX goes almost immediatly to OFF again (bouncing), generating the same interrupt that goes now through the ELSE part (setting Rinstance to X+x µs and tOFF to xµs where x should be quite small)
3. the PRX goes again ON, sending again the same interrupt but going again through the THEN part, setting F instance to X + y µs, y slightly greater than x, and tON to y - x, again quite small)

Another option, that may or may not give the same result, is that your callback may be called twice, for two different GPIO pins; you should test the value of GPIO_pin and only execute your code if it is the expected pin; however, you should probably always go through teh same branch of the IF, so the problem could go unnoticed.

That’s the only reasonable possibility; there is no way the compiler can generate an IF/THEN/ELSE construct so that it executes BOTH the then and else parts. If it does, in such a simple case, it will never, ever, go past the simplest test and be distributed at more than 2 or 3 users...

As a rule of thumb, when something does not work as expected, the bug is in my code, never in the compiler (well, being honest, as I’m a compiler writer, it occurs to me a few times that the compiler was wrong, but it was MY code that was failing, not the compiler compiling it ).

SW4STM32 uses the linaro compiler just for that: the provided binary was extensively tested before being released so you can trust it: if your code behaves this way, it’s because you ask it to behave like that.

Bernard (Ac6)