Increased current consumption on nrf54l15 + s145

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Fri, 18 Sep 2026 12:20:11 GMT

Hi again Maciej,

The info we got from the team is that the IRQs is expected to be forwarded to the softdevice before it is enable requested. Not after it's enabled.
My suggestion is to forward before calling nrf_sdh_enable_request(). Do you see any potential issue with that ?

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Fri, 18 Sep 2026 11:36:16 GMT

Hi Maciej,
Thanks for the clarification.
I will check internally to see where exactly the application is expected to forward the interrupt to the softdevice.

RE: Increased current consumption on nrf54l15 + s145

Maciej — Thu, 17 Sep 2026 14:14:33 GMT

Hi,

I'm calling the nrf_sdh_enable_request() which propagates the NRF_SDH_EVT_STATE_ENABLE_PREPARE and calls the sd_softdevice_enable.

On the NRF_SDH_EVT_STATE_ENABLE_PREPARE I'm disabling the interrupt.

Now it looks like this:

case NRF_SDH_EVT_STATE_ENABLE_PREPARE:

1. Disable the interrupt

2. Set flag for forwarding to softdevice

break;

After I started forwarding to softdevice on this event the issue is not present - that is 100% repeatable as I mentioned. The current draw is reduced to minimal levels - I meant 6uA mentioned in the original original post of mine here.

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Thu, 17 Sep 2026 13:59:33 GMT

Hi Maciej,

Sorry for the confusion. What I meant is to start forwarding interrupt when calling nrf_sdh_enable_request() .
Please confirm you don't call sd_softdevice_enable() in NRF_SDH_EVT_STATE_ENABLE_PREPARE event . It's handled by nrf_sdh.c

You mentioned that after you implemented the fix the issue reduced to "minimal levels" what does that mean ? Do you still occasionally see the issue ?

If you forward the interrupts right before nrf_sdh_enable_request() would that stop the issue ?

RE: Increased current consumption on nrf54l15 + s145

Maciej — Thu, 17 Sep 2026 13:05:31 GMT

" Let me sum it up, you are not forwarding the CLOCK_POWER [...] interrupt is not forwarded to the softdevice but to the application " - That is correct. This time between you mention is guarded by the critical section, but the clock interrupts still fire because they are time critical for the softdevice - that's the behaviour I'd like to confirm.

" My understanding is that you won't use the clock when you enable softdevice, correct ? " - That is also correct. I believe I mustn't use it when the softdevice is enabled, so I'm not using it.

" Is there anyway you can do the test by disable the CLOCK_POWER interrupt or start forwarding it right before you call sd_softdevice_enable() just to see if the problem disappear? " - That's more or less the "solution" I described. I'm disabling the interrupt and start forwarding to the softdevice just before the sd_softdevice_enable is called (on NRF_SDH_EVT_STATE_ENABLE_PREPARE).

Which interrupt is missed I'm not sure. I'll try to investigate that.

The behaviour is 100% repeatable, for both - the increased current based on nrf_sdh_is_enabled, and low current for the "solution".

Can you confirm that the CLOCK_POWER should be executed even under a critical section because of the stack's time constraints? That would be the case also for other softdevice's interrupts listed in github.com/.../irq_forward.s.

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Thu, 17 Sep 2026 12:42:09 GMT

Hi Maciej,

Thanks for the clarification.
Let me sum it up, you are not forwarding the CLOCK_POWER interrupt to the softdevice until nrf_sdh_is_enabled() return true., correct.
So the period between the time you call sd_softdevice_enable() until the time nrf_sdh_is_enabled() return true the CLOCK_POWER interrupt is not forwarded to the softdevice but to the application.

Is there anyway you can do the test by disable the CLOCK_POWER interrupt or start forwarding it right before you call sd_softdevice_enable() just to see if the problem disappear ?

My understanding is that you won't use the clock when you enable softdevice, correct ?

Which clock interrupt do you think that may trigger in such period ? My understanding is that it was 100% repeatable. Can you check what it is ? I couldn't recall if we start any clock when enabling softdevice. Also it's not so clear to me why missing some clock interrupt would result in the clock being kept running and still the BLE activity has no issue.

RE: Increased current consumption on nrf54l15 + s145

Maciej — Thu, 17 Sep 2026 06:03:08 GMT

Hi,

yes, I'm familiar with this file and I'm basing my implementation on it. However, I have some doubts regarding the CLOCK_POWER interrupt.

Because of our custom setup we can't just forward the interrupt unconditionally - we need the clock before the softdevice is enabled for the initialization and rtos setup. That's why I tried to implement some kind of a switch inside the interrupt routine. That switch would route the interrupt to the softdevice or the driver's handler.

I believe I found the issue. I implemented that switch using the nrf_sdh_is_enabled(), which returns the state of a variable that is set just after the sd_softdevice_enable() in a critical section. The critical section must allow the softdevice's interrupts to fire (I believe for s145 that is still the case?). So in a brief window where the softdevice re-enabled the CLOCK_POWER interrupt (I'm disabling it on NRF_SDH_EVT_STATE_ENABLE_PREPARE) and the nrf_sdh_is_enabled() is still false, the interrupt could be lost for the softdevice.

The "solution" is to introduce a new flag for routing the CLOCK_POWER interrupts. It's false (route to driver) from the start and is set to true (forward to softdevice) on NRF_SDH_EVT_STATE_ENABLE_PREPARE. This way the interrutps are forwarded to the softdevice even in that brief window I mentioned. The state of this flag is technically incorrect in the window between the NRF_SDH_EVT_STATE_ENABLE_PREPARE and the sd_softdevice_enable(), however the interrupt is disabled during that exact window, so it should not be a problem.

I write the solution in quotation marks, because I'm still hesitating whether this reasoning is correct and the issue is exactly what I described. The only thing I'm certain is that the high current consumption was 100% repeatable before and is reduced to minimal levels now also with 100% repeatability.

Is my understanding of the criitcal section and softdevice's interrupts correct also for s145? Does this reasoning seem plausible?

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Wed, 16 Sep 2026 13:26:36 GMT

Have you looked the irq_forward.s file ? Do you use it in your setup ?
github.com/.../irq_forward.s

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Wed, 16 Sep 2026 12:38:00 GMT

HI Maciej,

I'm not so familiar with FreeRTOS, but could you clarify how the interrupt forwarding is done in your application?

My understanding is that the interrupt are already handled by the softdevice and depends on if softdevice's enabled or not it will be forwarded to the application or not.

My understanding was wrong. I was messing up with earlier implementation.

RE: Increased current consumption on nrf54l15 + s145

Maciej — Wed, 16 Sep 2026 08:09:07 GMT

Hi,

Sorry for the delay. I'm now almost sure that the cause lies somewhere on the boundary between nrf_sdh_ interface and interrupt forwarding to the softdevice.

Can you confirm how the forwarding should behave for the softdevice's interrupts on s145:

reset - called unconditionally from startup .S code
SWI00, AAR00_CCM00, ECB0, TIMER10, RADIO_0, GRTC_3 - forwarded unconditionally on every corresponding interrupt
CLOCK_POWER - forwarded if the softdevice is enabled, routed to the driver's interrupt handler if the softdevice is disabled
hardfault - is the forwarding necessary ?

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Thu, 10 Sep 2026 12:15:12 GMT

Hi Maciej,

Active debugging session keeps the HFCLK running. So actually it could be the same thing. HFCLK for some reasons was kept running.
It would be interesting to know if you see the same problem with the bare metal.

RE: Increased current consumption on nrf54l15 + s145

Maciej — Thu, 10 Sep 2026 11:25:50 GMT

Hi,

Yes, your understanding is correct. Although for the debugger-case the current drops exactly when the session is closed, not when the probe is physically disconnected. I'd guess that the debugger does something while ending the session that results in the lower current consumption.

I'm not sure whether the two cases are caused by the same reason. However it seems unlikely in this situation, that the result is exactly the same for two unrelated bugs.

The LFCLK is configured only via the nrfx_clock_lfclk_start() and the NRFX_CLOCK_CONFIG_LF_SRC is set to 0.

I'll use the bare metal sample and see what happens. I haven't tried it yet.

RE: Increased current consumption on nrf54l15 + s145

Hung Bui — Wed, 09 Sep 2026 13:24:36 GMT

Hi Maciej,

Please correct me if I'm wrong:
- On a board without a debugger , the issue can be observed and the high current consumption only disappear when you disable softdevice or calling NRF_CLOCK.TASKS_XOSTOP .

- On a board with debugger connected, the issue disappear when the debugging session is stopped and the debugger is disconnected physically ?

Do you have the same issue when testing with our baremetal SDK ?
We need to check why HFXO was kept running even when you don't have any BLE activity. Please make sure you don't have in other part of the code configure LFCLK source to SYNTH. That would require the HFCLK to run to generate the SYNTH LFCLK.
I would suggest to try compare it to the bare metal sample (if the sample doesn't show the same issue). Try to simplify the application to the point that it similar to the bare metal sample and go from there.

- Please also try to test on a DK as a comparison.