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, 

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. 

[Maciej]

Hi

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

[Hung Bui]

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 ? 

[Maciej]

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.

[Hung Bui]

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. 

[Hung Bui]

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 ?