SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

false condition if statement getting executed inside ISR


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)