SAADC scan + burst & oversmaple

[Radiohead]

• SDK14.2
• Segger Embedded Studio
• nRF52 development board

According to this post https://devzone.nordicsemi.com/f/nordic-q-a/20556/how-does-the-saadc-scan-mode-use-the-burst-1 the SAADC can use multichannel scan mode with burst enabled  on all channels and oversampling set on any other value other than disabled. The product specification of the nRF52832 is a bit confussion as stated by the linked post.With the necessary changes I got oversamping with burst on three channels working as expected.

However the power consumption direclty increases after the first ADC conversion to roughly 1mA and doesn't go back to the expected 2uA when I only measure a single channel:

Multichannel

Single channel:

From what I read on the forum, this is due to the easyDMA staying active after the conversion completes. I've tried disabling the SAADC peripheral and the ADC channels after the convertion completes, as is done with the low power SAADC multichannel example on Nordic's github, but nothing disables the easyDMA's current consumption.

So my question is if there's a remedy for the power consumption after a scan with burst and oversampling or do I need a different approach to quickly measure all channels?

Code with which I've been testing:

saadc_test.zip

[mchartier]

I too am using the SAADC in the same manner (i.e. multiple channels, oversample, and burst enabled) however I do not yet have the equipment to measure the power usage.  This power issue is very concerning to me and this is possible a show stopper for us.  

If you are looking for a workaround I just have this one idea:  Do a single-shot conversion after you get all your samples and you do all the uninit() calls.  By doing a single-shot conversion on a single channel with burst disabled I would expect the SAADC to release DMA resources and power down normally. 

[Einar Thorsrud]

Another likely explanation is that the SAADC for some reason continue to request the HF clock, but I don't know. I have created an internal bug report so that it will be investigated, but that is likely to take some time.

A possible workaround is to use this line of code after disabling the SAADC (typically right after you call nrf_drv_saadc_uninit()):

*((volatile uint32_t *)0x40007FFC) = 0;

Then you also need to use this line before enabling the SAADC (typically right before you call nrf_drv_saadc_init()):

*((volatile uint32_t *)0x40007FFC) = 1;

[mchartier]

I now have the PPK and I confirmed my application has the same power issue when SAADC is configured with scan+burst+oversample.  The power problem does not happen when I turn off scan and leave burst+oversample tunred on.  Stopping the SAADC and calling saadc_uninit() did NOT fix the problem, but when I tried your workaround (0x40007FFC = 0) the problem was fixed. However, In my application I need to take samples of two pins every 5ms so it seems like bad design to call saadc_init() and saadc_uninit() every 5ms.  I am hoping someone can find another workaround that would allow me to leave SAADC enabled in continuous sample mode.

[Einar Thorsrud]

I am not able to think of any way that will let you keep the SAADC enabled. I cannot say that it will not be possible though, as the root cause of this issue has not yet been found.