nrfx_saadc_abort in SAADC API V2

[nrbrook]

I'm using nrfx_saadc V2 in nRF5 SDK 17.0.2. In nrfx_saadc_abort nrf_saadc_task_trigger(NRF_SAADC_TASK_STOP); is called regardless of if the ADC is currently running. If the ADC is not running this pending task causes several mA of current consumption. It is worth noting that nrfx_saadc_abort is called in nrfx_saadc_uninit, so trying to stop or uninit the SAADC causes excessive current consumption if the ADC was not running.

[Karl Ylvisaker]

Hello again,

I've given this some more though- the STOP task should complete pretty much instantly if the SAADC is not currently busy anyways, so unless your application uninits and reinits the SAADC at a high frequency I would think that these added instructions will cause a negligible increase in overall power consumption. Especially so when it prevents you from leaving the SAADC in a higher-power state if the uninit fails.
If you think that this is causing excess power consumption in your application you may modify the driver to check for the SAADC's current state, and not to trigger the STOP task if it is not active. You could then measure the average power consumption to see how this influences your applications consumption.

Best regards,
Karl

[nrbrook]

Hi, the pending task keeps the CPU active which does cause several mA of current consumption. I already surrounded with a busy check which fixed the issue and reduced current consumption from 4.7mA to 50uA when connected. 

[Karl Ylvisaker]

I'm glad to hear that you've already implemented a change that achieves the functionality you were after!
Could you elaborate what you mean when you say connected - are you here exclusively talking about the scenario in which the SoftDevice takes control of the CPU before the task is processed?
How long is the duration of the added 4.7 mA consumption, compared to when you've added the busy check?

Best regards,
Karl

[nrbrook]

By "connected" I just meant connected as a Bluetooth peripheral.

Current consumption after calling abort is constant at 4.7mA until power off (because the CPU is stopped) with the existing code. When I added the busy check current consumption doesn't get that high for extended periods of time (only during radio or CPU active)

[Karl Ylvisaker]

Thank you for elaborating.

nrbrook said:

When I added the busy check current consumption doesn't get that high for extended periods of time (only during radio or CPU active)

That is interesting! How long would these extended periods of time be?

nrbrook said:

Current consumption after calling abort is constant at 4.7mA until power off (because the CPU is stopped) with the existing code.

You say that this goes on from the _abort call until power off because the CPU is stopped, could you elaborate on this? If you mean that the CPU is in SYSTEM_ON sleep (idle) it should not have gone halfway through the _abort call before entering the SYSTEM_ON sleep. When you say until power off, does this mean that you require a power cycle or device reset in order to see the current consumption go down again? If I am understanding what you are saying here correctly it does indeed not sound right at all.

Have you based your application on a specific example, or do you have a minimal project that demonstrates this behavior?

Best regards,
Karl

[nrbrook]

Karl Ylvisaker said:

That is interesting! How long would these extended periods of time be?

With the task pending (existing implementation) – ~4.7mA constantly until system off (when I call nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_STAY_IN_SYSOFF);). Resetting will reduce power consumption as task will not be pending.

Without task pending (checking for busy before starting STOP task) – ~50uA average current, with small peaks during radio or CPU activity (as normal)

I think if you use the standard SAADC v2 example it will exhibit the behaviour, but I haven't tested it.