Sleep current is high after using SAADC

[Roy Huang]

Hi,

There is a similar case:

High power consumption in sleep mode after using SAADC

But I am using the SAADC driver version 2.0 because the oversampling feature is only supported in new driver, low power mode is not supported.

My environments:

nRF52840, the sdk version is 17.02, s140 version 7.2.0. Because we need the oversample feature in SAADC, so we are using SAADC driver version 2.0. When there are two channels sampled, the sleep power current is very high, more than 600uA, but if only one channel is sampled ,the sleep current is low, only 4uA. UART is also disabled.

Please help on this. Thanks

Regards

Roy Huang

[Karl Ylvisaker]

Hello Roy Huang,

Thank you for your patience, and thank you for the very thorough description of your issue!

This does indeed sound very strange, and I do not immediately see any flaws in your description or included code.
I have discussed this with some colleagues, and it sounds similar to an issue we've heard of earlier, where the High Frequency CLK is never released and thus is left running. This corresponds well with the 600 µA increase in current you report.

Could you try to call TASKS_STOP at the end of your NRFX_SAADC_EVT_DONE event handling?
Alternatively, could you check whether the status of the HFCLK is Running when the increase in current consumption is present?

I will test your example here on my end shortly, to see if I can see the same behavior. If I am able to reproduce this I will open an internal ticket with our developers, so that they may examine this more closely.

Best regards,
Karl

[Roy Huang]

Hi Karl,

For your suggestion:

1. I tried inserting code "nrf_saadc_task_trigger(NRF_SAADC_TASK_STOP);" in SaadcHandler, but no difference.

2. I tried to check the state bit in register HFCLKSTAT, but whatever sample one channel or two channels, this bit is always 1, so I guess I have no way to find out whether HFCLK is running when CPU is sleeping.

Best Regards,

Roy

[Karl Ylvisaker]

Hello Roy,

Thank you for your patience, and for testing this and getting back to me with your findings.
I find this even more strange, and I will need to confer with our development and test teams, to see if they have any input. 

I will let you know as soon as I have discussed this issue with them.

Best regards,
Karl

[leox]

Hi Roy,

Please find the attached source code, tested with a nRF52840DK,  it works ok now with low power on multi  ADC channels.

1: apply the errata 212 which helped. More details on this errata: https://infocenter.nordicsemi.com/topic/errata_nRF52840_Rev2/ERR/nRF52840/Rev2/latest/anomaly_840_212.html

• As the source code re-configure the ADC on each timeout. So it’s ok to apply this workaround.

2: change this  to 1 to use the workaround, 0: not to use.

    #define ENABLE_ERRATA_212_WORKAROUND  1

3: Also noticed the second ADC output always 0,  now it’s ok with buffer index +1 instead +2 “NRF_LOG_INFO("%d %d", *(uint16_t *)p_event->data.done.p_buffer, *(uint16_t *)(p_event->data.done.p_buffer + 1));”5850.ble_app_saadc_sample.7z