nrfx_saadc_abort in SAADC API V2

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.

  • Hello,

    Thank you for bringing this to our attention. I will create an internal ticket with the developers of the SAADC driver and ask them to investigate this further.

    Best regards,

  • 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,

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

  • 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,

  • 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)