Increased current consumption on nrf54l15 + s145

[Maciej]

Hi all,

We're building a PoC of a simple BLE device with a following setup:

• custom PCB with nrf54l15 rev2 and 32MHz oscillator
• FreeRTOS + custom port
• nrfx version 3.14.0
• softdevice s145 version 10.0.0
• our application layer

In order to handle the softdevice operation we're using some of the modules from nRF5 SDK (like nrf_sdh, nrf_sdh_ble etc.).

The baseline current consumption for now for most of the functionalities disabled and the mcu sleeping is 6uA. The moment the softdevice is enabled with 

nrf_clock_lf_cfg_t const clock_lf_cfg =

    {

        .source        =     0,

        .rc_ctiv       =      32,

        .rc_temp_ctiv  = 2,

        .accuracy      =   1,

        .hfclk_latency = 1000,

        .hfint_ctiv    =     8,

    };

ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);

 

the current consumption increases to about 140uA and stays on this level as long as the softdevice is enabled. The moment the softdevice is disabled with 

sd_softdevice_disable() the level goes back to 6uA. That is the case even if no BLE functionalities are started.

If the  NRF_CLOCK.TASKS_XOSTOP is triggered manually, the current level goes back to 6uA, but the softdevice stops working correctly.

On initialization the nrf_oscillators_hfxo_cap_set is called.

After a full power cycle the behaviour is the same.

For the builds with app protection off, if the device is reset by the debbuger - the moment the debugging session is closed and the debugger is disconnected, the current also goes back to 6uA even if the softdevice is still enabled (the debugging session is crucial not physically disconnecting the probe). After that, softdevice and the device itself are working correctly.

Is the clock configuration wrong? Some peripherals are handled incorrectly?

Regards,

Maciej

[Hung Bui]

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. 

[Maciej]

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.

[Hung Bui]

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. 

[Maciej]

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 ?

[Hung Bui]

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. 

[Hung Bui]

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

[Maciej]

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?