nrfx_saadc_abort in SAADC API V2

RE: nrfx_saadc_abort in SAADC API V2

Karl Ylvisaker — Thu, 16 Dec 2021 15:09:37 GMT

Hello again,

Thank you for your continued patience with this.

I have just gotten back to this, and after examining the driver more closely it seems that the NRFX_ASSERT at the beginning of nrfx_saadc_abort should have triggered to alert you to the fact that the abort call was made when the SAADC was already uninitialized. In general, calling HAL or driver functions on an uninitialized peripheral may produce undefined behavior.

To avoid this happening in the future, I would recommend that you defined DEBUG_NRF in your preprocessor defines during your development, so that the NRFX_ASSERTS are enabled. This way, you will be notified if this or something similar ever happens again in the future. After having tested and verified your application you can safely remove the DEBUG_NRF define.

Best regards,
Karl

RE: nrfx_saadc_abort in SAADC API V2

Karl Ylvisaker — Thu, 28 Oct 2021 11:30:46 GMT

Hello again,

Thank you for your patience.

[quote user="nrbrook"]I haven't tested this myself but I do not think I am doing anything particularly unique that would trigger this issue, I think it is likely to occur whenever the ADC is already stopped and the stop task is triggered. I assume that the task can't be completed because the ADC is not running, so the CPU continues to run (I don't know how the internal mechanisms of the tasks and CPU operate).[/quote]

I think this sounds unlikely, since we have a lot of functionality implemented to get the CPU to idle as soon as possible, and avoid these kinds of hangups, but I will have to test this myself before I can say this for sure.

[quote user="nrbrook"]I don't think it is necessary for the BLE connection to be active (or even the radio at all). I am fairly sure this condition occurred without the radio active, but my current measurement was from after the connection occurred.[/quote]

This suffices as a working hypothesis that I may test out on my end, thank you for elaborating.

[quote user="nrbrook"]If you have difficulty reproducing the issue I can look in to what I might be doing differently.[/quote]

Thank you. With this information I can do a test to try to replicate it on my end. I will update you as soon as I have had the chance to do so.

Best regards,
Karl

RE: nrfx_saadc_abort in SAADC API V2

nrbrook — Mon, 25 Oct 2021 11:05:00 GMT

Hi Karl, here is some example code but no I don't think there is an example project:

https://github.com/NordicSemiconductor/nrfx/wiki/SAADC-Advanced-mode-with-IRQs

I haven't tested this myself but I do not think I am doing anything particularly unique that would trigger this issue, I think it is likely to occur whenever the ADC is already stopped and the stop task is triggered. I assume that the task can't be completed because the ADC is not running, so the CPU continues to run (I don't know how the internal mechanisms of the tasks and CPU operate).

I don't think it is necessary for the BLE connection to be active (or even the radio at all). I am fairly sure this condition occurred without the radio active, but my current measurement was from after the connection occurred.

If you have difficulty reproducing the issue I can look in to what I might be doing differently.

RE: nrfx_saadc_abort in SAADC API V2

Karl Ylvisaker — Sun, 24 Oct 2021 15:57:15 GMT

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.

[quote user="nrbrook"]I think if you use the standard SAADC v2 example it will exhibit the behaviour, but I haven't tested it.[/quote]

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

RE: nrfx_saadc_abort in SAADC API V2

nrbrook — Tue, 19 Oct 2021 17:06:15 GMT

[quote userid="87869" url="~/f/nordic-q-a/80636/nrfx_saadc_abort-in-saadc-api-v2/334564#334564"]That is interesting! How long would these extended periods of time be?[/quote]

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.

RE: nrfx_saadc_abort in SAADC API V2

Karl Ylvisaker — Mon, 18 Oct 2021 11:16:31 GMT

Thank you for elaborating.

[quote user="nrbrook"]When I added the busy check current consumption doesn't get that high for extended periods of time (only during radio or CPU active)[/quote]

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

[quote user="nrbrook"]Current consumption after calling abort is constant at 4.7mA until power off (because the CPU is stopped) with the existing code.[/quote]

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

RE: nrfx_saadc_abort in SAADC API V2

nrbrook — Fri, 15 Oct 2021 10:29:17 GMT

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)

RE: nrfx_saadc_abort in SAADC API V2

Karl Ylvisaker — Fri, 15 Oct 2021 10:25:00 GMT

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

RE: nrfx_saadc_abort in SAADC API V2

nrbrook — Fri, 15 Oct 2021 09:46:24 GMT

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.

RE: nrfx_saadc_abort in SAADC API V2

Karl Ylvisaker — Fri, 15 Oct 2021 09:08:27 GMT

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

RE: nrfx_saadc_abort in SAADC API V2

Karl Ylvisaker — Thu, 14 Oct 2021 14:54:40 GMT

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