current consumption in k_sleep

[Ingfu]

Hi,

we have a custom board with the nrf54l15 and are doing power optimizations for standby. Our device will never go to SYSTEM OFF as the init draws to much power.

We expect a difference between SYSTEM ON idle and SYSTEM OFF of around 2µA, but we measure a difference of 17µA while sleeping with with k_sleep compared to sys_poweroff.

We checked all peripherals we used, but they seem disabled. Any ideas, where the 17µA could result from? Is there some code/tool, that goes through all peripherals and states what is still active?

[Vidar Berg]

Hello,

Does your app enable any pin interrupts (buttons, etc)? If so, try using GPIOTE PORT instead of GPIOTE IN events by using the "sense-edge-mask" property in your gpio devictree node. Unlike IN events, PORT events does not impact the sleep current.

Example: https://github.com/nrfconnect/sdk-zephyr/blob/4910be262e76b0cfbc5ca609d977fc0696b3a112/tests/drivers/gpio/gpio_basic_api/boards/nrf54l_sense_edge.overlay

Best regards,

Vidar

[Ingfu]

Hallo,

changing the sense-edge-mask has an influence on the current. However, I don't get interrupts any more. Does the API change when using port events?

gpio_pin_configure_dt(&drv_cfg->int_gpio, GPIO_INPUT);

gpio_init_callback(&drv_data->gpio_cb, tmag5273_irq_handler, BIT(drv_cfg->int_gpio.pin));

gpio_add_callback(drv_cfg->int_gpio.port, &drv_data->gpio_cb);

gpio_pin_interrupt_configure_dt(&drv_cfg->int_gpio, GPIO_INT_LEVEL_ACTIVE);

[Vidar Berg]

Hallo,

No, it is not expected to affect the API usage. The _LEVEL_ triggering should be using PORT events by default anyway. Is this the only interrupt pin you are configuring? If you want to double check you can read out the GPIOTE Configuration registers to see if any of the CONFIG registers have been set.

[Ingfu]

In the GPIO, I can see that the pin is latched, but the isr is never called. strange.

[Vidar Berg]

Could you read out the GPIOTE configuration and INTEN registers as well?

[Ingfu]

I probably solved it. When using LEVEL interrupt, the ISR work item was never executed as the pin interrupt was not cleared, as the work item would write to the sensor.  Can I suggest to include the interrupt configuration in any of the dev academy courses? The information regarding power consumption, LEVEL vs. EDGE,  sense-edge-mask and port vs. input and GPIO vs GPIOTE seems a little bit scattered around.

Also, is there any information on the latency introduced by using the sense mechanism? Or the minimun pulse duration? And is it possible to reconfigure the sense-edge-mask during runtime?

[Vidar Berg]

Good to hear, thanks for the update. With LEVEL triggering the interrupt will keep firing until the input signal is de-asserted. What you probably want in your case is to use GPIO_INT_EDGE_TO_ACTIVE in combination with the "sense-edge-mask" DT property. I agree that the information is a bit scattered, but we are actually already planning to include this in a devacademy course.

The minimum pulse duration is about 10 us currently (you should add some margin here), but we have updated the drivers to support using the Latch detect mode which will shorten the required pulse with to around 1 us.

Driver update: https://github.com/nrfconnect/sdk-zephyr/pull/3898