SEVONPEND flag and high interrupt priorities

[RK]

There's a note in the migration guide which says .. very ominously ...

Applications must not modify the SEVONPEND flag in the SCR register when running in priority level 1 for s130 and priority levels 2 or 3 for s132.

Two questions

1. Why? Some rough idea of what that affects would be helpful as it's such a specific prohibition and all it really affects is the behaviour of WFE so it's hard to figure out what it could break.
2. I have some code which runs in thread mode and modifies SEVONPEND, when it's done, it puts it back to what it was. However it could easily be interrupted by an interrupt in one of those high priorities whilst it's been modified (in this case it's being set). I assume, even though the interrupt doesn't modify it itself, just executing with SEVONPEND modified from thread mode breaks that prohibition.

[Susheel Nuguru]

Hi RK,

1. There are few SVC calls that sets SEVONPEND flag in SCR waits for some hardware events by going to sleep (__WFE) without enabling the interrupts. So if you are in higher priority than SVC (priority 1 in S130 , priority 2 or 3 in S132) and if you disable this flag then there is a possibility that the softdevice will worst case sleep forever (or sleep long enough to fail its real time constraints and assert)

2. Thread mode is the least priority. This restriction does not apply to contexts with lower priority than or equal to SVC. Because in these lower priorities, app cannot interrupt softdevice (and hence cannot disable this flag) until it wakes from the hardware event it is waiting on.

[Susheel Nuguru]

temporarily using BASEPRI equal to SVC should be safe. So your use case is not in conflict with anything :)