High power consumption in sleep mode after using SAADC

[piotrs]

I am using nRF52832 with SDK 16.0.0. I have a simple application that uses SAADC and BLE. It reads values from three channels AIN0, AIN2 and AIN4 and sends them via BLE every 10 seconds. The SAADC is initialized with call to nrfx_saadc_init() and unintialized with nrfx_saadc_uninit(). Similar the channels are initialized with nrfx_saadc_channel_init() and uninitialized with nrfx_saadc_channel_uninit(). I read samples with a call to nrfx_saadc_sample_convert(). Before the device enters the sleep mode I uninitialize all channels and the SAADC module. However, it consumes approx. 1mA. When I comment out the calls to nrfx_saadc_sample_convert() then the device consumes a few uA as it should. I notice the same behavior with SDK 15.3.0. What is the correct way to disable SAADC? 

[Andreas]

Hi,

 

Did you enable low power mode when you initalized the SAADC?

 

Best regards,

Andreas

[piotrs]

Yes, I am using low power mode, by setting define (#define NRFX_SAADC_CONFIG_LP_MODE 1) and using NRFX_SAADC_DEFAULT_CONFIG when initializing SAADC.

[Andreas]

Hi,

 

OK, interesting, I thought this would solve it. I believe the issue is the DMA buffer enabling the SAADC, a workaround is described in this reply.

 

Best regards,

Andreas

[piotrs]

I used the last three days to narrow down the problem and more prescience tools to measure current. In fact, when I commented out nrfx_saadc_sample_convert() the compiler removed also a function call to the code that converts the read value to the voltage level. The function is the source of the high current consumption. It uses FPU for the computations. When I removed operations involving FPU the nRF52 consumes 2uA during sleep. When I disable hardware support for FPU (by removing options "-mfloat-abi=hard -mfpu=fpv4-sp-d16" from compiler and linker), I also got 2uA during sleep. With hard FPU, I get 3mA usage. 

[Kenneth]

Related to this:

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_87.html?cp=4_2_1_0_1_24