SAADC scan + burst & oversmaple

RE: SAADC scan + burst & oversmaple

Einar Thorsrud — Wed, 21 Nov 2018 13:58:40 GMT

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.

RE: SAADC scan + burst & oversmaple

mchartier — Tue, 20 Nov 2018 19:29:09 GMT

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.

RE: SAADC scan + burst & oversmaple

Einar Thorsrud — Tue, 06 Nov 2018 09:55:36 GMT

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;

RE: SAADC scan + burst & oversmaple

mchartier — Mon, 05 Nov 2018 21:21:21 GMT

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.

RE: SAADC scan + burst & oversmaple

Einar Thorsrud — Fri, 02 Nov 2018 13:03:23 GMT

Hi,

I do not have an explanation for this behavior at this point, but I am tempted to believe that there is a hardware limitation/issue of some sort. Your driver modifications come from this post I see. I do not have a workaround either (other than "don't do it").

Here is you example in a slightly simplified variant where it is easy to see the difference in current consumption between 1 and 2 channels by setting the SAADC_CHANNELS define accordingly (for my own reference).

devzone.nordicsemi.com/.../main.c

RE: SAADC scan + burst & oversmaple

Einar Thorsrud — Tue, 30 Oct 2018 14:52:22 GMT

I have tested your code and see the same behavior. I do not have an explanation for it, but we have seen similar issues before. I will look into it and hopefully get back to you tomorrow.

RE: SAADC scan + burst & oversmaple

Radiohead — Mon, 29 Oct 2018 19:06:40 GMT

Thank you for your reply Einar,

In the example the definitions SAMPLES_IN_BUFFER was set to 1, but it should have been 3, since I used three channels.That's why you got an assert.devzone.nordicsemi.com/.../nRF5_5F00_SDK_5F00_14.2.zip

In the saadc callback I un-init the saadc and all channels, the ADC results are as expected and there are no asserts. Still there is a continous 1mA current consumption when I measure with a power profiler after the first saadc initialization.

Here is the edited project with a stripped down sdk 14.2. The project can be found under nRF5_SDK_14.2\examples\peripheral\saadc_burst.

RE: SAADC scan + burst & oversmaple

Einar Thorsrud — Mon, 29 Oct 2018 08:36:43 GMT

Hi,

There should not be any additional current consumption between the sampling events when you have disabled the SAADC peripheral (calling the nrf_drv_saadc_uninit()). In this case, the SAADC peripheral should not keep the DMA logic active.

I have not been able to test your code. There are some asserts when in nrf_drv_saadc.c (I use the one you included in saadc_test.zip). Can you make sure to include all modified SDK files and check that they are sufficient in order to run the example on the nRF52832 DK with an otherwise unmodified SDK 14.2?