cpu/cortexm_common: flush pipeline before disabling interrupts in idle

[benpicco]

Contribution description

When enabling & disabling interrupts back-to-back pending interrupts are not serviced on Cortex-M23/M33.

Flush the pipeline to give interrupts a chance of executing in sched_arch_idle().

This fixes no_idle_thread on Cortex-M23.

Testing procedure

Issues/PRs references

#14557 (comment)

[maribu]

@kfessel: This might solve the issue you recently experience on the Nucleo-F767ZI

[maribu]

ACK. Even if the extra pipeline flush might not be needed for every Cortex M variant, it is better to be safe than sorry here. (And the additional overhead should be not too bad.)

[aabadie]

This is also fixing the issue I had in #15192 (M33). With this PR (and without the idle thread), it works like a charm.

[benpicco]

Failed tests are

• run_test/tests/mtd_flashpage/samr21-xpro:llvm due to cpu/sam0: flashpage write / read cycle produces different results depending on code layout in flash #14929
• run_test/tests/pkg_libhydrogen/samr21-xpro:llvm due to tests/pkg_libhydrogen: test fails on master for the samr21-xpro with LLVM #15066

[kaspar030]

Nice catch @benpicco! 😄

[kfessel]

@kfessel: This might solve the issue you recently experience on the Nucleo-F767ZI

@maribu: sandly i still got hourly "gnrc_netif: possibly lost interrupt." after i rebased on current master with this patch merged.

(but the examples stayed running (gnrc_simple and the gcoap example )) -> i will run a retest with my project code

[maribu]

@maribu: sandly i still got hourly "gnrc_netif: possibly lost interrupt."

That is expected. If the load is too high, more messages will be generated than the message queue can store. This is due to the design choice of choosing receiver allocated messages in GNRC for communication.

What this should fix is the hang you experienced one night during context switch.