See erratum 837070 in "ARM Processor Cortex-M7 (AT610) and Cortex-M7 with FPU (AT611), Product revision r0, Sofware Developers Errata Notice".

Basically the problem is that msr BASEPRI won't immediately take effect and the instruction following it won't have the new / desired dynamic priority and thus it can be preempted as if BASEPRI hadn't been modified.

The suggested workaround is to temporarily disable interrupts when msr BASEPRI is issued, so basically something like this:

cpsid i
msr BASEPRI
cpsie i

We can directly apply this fix in claim since claim only modifies BASEPRI when interrupts are enabled. (If interrupts are disabled, claim is a no-operation)

However, It would be ideal if we only applied this fix when targeting Cortex-M7 devices. And I think we can do that but we'll need some help from svd2rust. SVD files contains these <cpu> and <revision> fields that would let us identify chips with the problem. Device crates could expose CPU and REVISION constants that claim could check to decide whether to apply the workaround or not.

Thanks @pftbest for reporting this.
cc @perlindgren