Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

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.

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

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

Reply Children
  • 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

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

  • 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

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

  • Hello again,

    Thank you for your patience with this.
    It is the pending task + idling CPU = increased power consumption that I am having trouble understanding. The 4.7 mA constant current consumption indicates that the CPU is running constantly, but at the same time it is not clearing the pending task?
    I would then suspect that the CPU is busy with some other task - or perhaps even busy-waiting - somewhere with a higher-priority for the duration of the increased power consumption. Could there be a possibility for this at all in your application?

    I will have to test this on my end, to see if I am able to replicate the behavior you are seeing.

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

    Could you be specific about which example you are referring to here? The nRF5 SDK does not contain an example using the SAADC v2 driver.
    You also mentioned that your application is in a BLE connection when this happens.
    Is it necessary to be in a connection to see the behavior?
    If so, would you think that a SAADC v2 + BLE UART example combination should suffice to replicate it?

    Best regards,
    Karl

Related