Zephyr: Last software timer expiration does not cause immediate transition into low power sleep

RE: Zephyr: Last software timer expiration does not cause immediate transition into low power sleep

Vidar Berg — Wed, 02 Sep 2026 12:03:19 GMT

Thanks for the update and feedback. I agree, having an assert to catch invalid FPU usage inside ISRs sounds like a good idea given the current limitation . I am still trying to understand why the current consumption increases after a FPU exception. Will update the ticket when I know more.

RE: Zephyr: Last software timer expiration does not cause immediate transition into low power sleep

xorly — Wed, 02 Sep 2026 07:57:58 GMT

Not related to this specific issue, but the Zephyr also documentation states that use of FPU instructions inside interrupts is not supported:

This is the most important info for me! I completely missed this fact in the docs.

I tried to create global volatile float sink variable and write it from timer expiry callback (ISR) and that went fine. Increased power draw in sleep is probably caused by some heavier FPU use in ISR, not just load/store.

My opinion:

Zephyr should assert in such cases. There are flags in Cortex M cores indicating FPU activity on current stack, so ti is doable. I have the impression, that Zephyr uses asserts mostly for user input validation and not even that extensively. Advanced assumptions like this one are rarely guarded by an assert.

Thank you for looking into this!
Your answer resolves the issue for me, but if you find out anything interesting or manage to improve Zephyr quality in this aspect, let me know!

RE: Zephyr: Last software timer expiration does not cause immediate transition into low power sleep

Vidar Berg — Tue, 01 Sep 2026 14:17:07 GMT

Thanks for sharing the code and config. This is an interesting find. I was able to reproduce this on my end as well, and it seems like the elevated sleep current may potentially be related to the FPU. I assume you are also not seeing the issue if you don't enable CONFIG_FPU in your project config?

Not related to this specific issue, but the Zephyr also documentation states that use of FPU instructions inside interrupts is not supported:

https://nrfconnectdocs.nordicsemi.com/ncs/latest/zephyr/kernel/services/other/float.html

I will continue to investigate this on my end.

RE: Zephyr: Last software timer expiration does not cause immediate transition into low power sleep

xorly — Mon, 31 Aug 2026 14:48:38 GMT

So this was interesting adventure, it looks like (some?) float operations in the timer expiry callback cause increased power draw.

I've also attached disassembly of each handler.

devzone.nordicsemi.com/.../4048.main.cpp

devzone.nordicsemi.com/.../13457.prj.conf

devzone.nordicsemi.com/.../my_5F00_timer_5F00_expiry_5F00_handler_5F00_float_5F00_disassembly.txt devzone.nordicsemi.com/.../my_5F00_timer_5F00_expiry_5F00_handler_5F00_raw_5F00_disassembly.txt

RE: Zephyr: Last software timer expiration does not cause immediate transition into low power sleep

xorly — Mon, 31 Aug 2026 10:25:36 GMT

Hello,

these are my C++ wrappers, but nothing special in there, so I did not include them (except the timer callback).
Anyway, when I reduced the example to just directly call zephyr API functions, the issue is gone.

2nd blink sequence is done by calling zephyr API functions directly, rest are though my wrapper.

I am still looking through the code for the difference.

RE: Zephyr: Last software timer expiration does not cause immediate transition into low power sleep

Vidar Berg — Fri, 28 Aug 2026 11:19:25 GMT

Hello,

Sorry, I can see you are using C++ but I do not recognise the function and classes you are using. Have you implemented your own timer or is it a wrapper around the Zephyr timer (https://nrfconnectdocs.nordicsemi.com/ncs/latest/zephyr/kernel/services/timing/timers.html#timers-v2)? Can you provide a minimal version of your project that would allow me to reproduce the problem here?

Best regards,

Vidar