This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf_drv_clock_calibration_force introduces excess current consumption

Hi!

One of the designs still has the internal RC for the low frequency clock. Hardware and software turns out to be working okay, where system off current is ~0.4uA and sleeping current is ~4 uA.
When device boots up two clock APIs are called :

	APP_ERROR_CHECK(nrf_drv_clock_init(nullptr));
	nrf_drv_clock_lfclk_request();

This works fine all the clocks running and the device works as expected. We also have the code where we force the RC calibration at some point (where precision measurements need to be done):

		APP_ERROR_CHECK(nrf_drv_clock_calibration_force());
		uint32_t calibStarted = platform::millis32();
		bool calibrating = true;
		while(calibrating)
		{
			nrf_drv_clock_is_calibrating(&calibrating);
			platform::sleepMillis(1);
			if(platform::millis32() - calibStarted > 1000)
			{
				LOGD("RC calib timeout\n");
				break;
			}
		}

The platform namespace functions are what they say, just wrappers around RTC drivers.

Now the current consumption gets higher if we run the application with the bootloader installed (ble dual bank S310). I drew down the cause which seems to be forcing RC calibration, then the sleeping current goes to ~40uA. What is not in sync with what the bootloader does so that RC calibration introduces excess 36uA of current? It is not happening when no bootloader is installed on the system. Also I noticed that calibration always timeouts when bootloader is installed, otherwise not.

SDK version is 12.

Cheers!

Parents Reply Children
Related