SEVONPEND flag and high interrupt priorities

RE: SEVONPEND flag and high interrupt priorities

Susheel Nuguru — Tue, 24 May 2016 07:44:51 GMT

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

RE: SEVONPEND flag and high interrupt priorities

RK — Tue, 24 May 2016 07:32:36 GMT

@aryan - thanks. That's fine then, my use-case still works safely. I'm doing something similar, using BASEPRI to block interrupts for a critical section around a low power sleep but letting the softdevice critical interrupts stay unblocked. In order to that you have to use WFE with SEVONPEND set or you don't wake up on the lower priority interrupts.

The alternative is to set PRIMASK, clear BASEPRI, use WFI for sleep and quickly set BASEPRI then clear PRIMASK when WFI returns to let the softdevice critical interupt run. That delays the interrupt by just a few cycles, but I prefer not to have it blocked at all if possible.

Good I can leave the code like it is.

RE: SEVONPEND flag and high interrupt priorities

Susheel Nuguru — Tue, 24 May 2016 07:15:26 GMT

Hi RK,

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)
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.