Power consumption is too high after sending SPIM3 to sleep

RE: Power consumption is too high after sending SPIM3 to sleep

matthk — Tue, 18 Apr 2023 15:21:43 GMT

Hi Einar,

finally I found the reason, but all the investigations we made were good and necessary.

Each 'supply current consumer' like the acceleration sensor is switched on/off in our electronics by a simple logic gate (74LVC1G17), where the input is driven by a GPIO from the nRF52840 but with an additional external Pull-up of 1 MOhm. Before decreasing the supply voltage to 1.8V I had 3.0V supply voltage in the last Hardware version and there I had the impression, that when starting the CPU the supply current achieved quite high values, and this was reduced when pulling up these inputs of the logic gates?!?

After disabling and uninitialising the acceleration sensor's SPI - then they become inputs - I set the SCLK, /CS and MOSI to output and set these outputs to 0, then I see no longer this additional current of about 100 µA.

The next step is to take out this Pull-Up; then probably the supply current could become even lower when not setting as an output at value 0 but just keep it as input already done by disable and uninitialise. Taking out the Pull-Up will economise 1,8 µA, but concerning the change from GPIO output at 0V to input: Would you expect a significant reduction of supply current doing this?

Thanks so far for your great help.

Best regards,

matthK

RE: Power consumption is too high after sending SPIM3 to sleep

Einar Thorsrud — Fri, 14 Apr 2023 13:51:37 GMT

Hi matthK,

That seems like a good hypothesis, but if you do uninitialize the driver, it does reset the GPIO pins to the default state, which is disconnected inputs. And I see in your snippet that you also write 0x2 to the PIN_CFN registers explicitly, which does the same thing again. So there should not be anything driving these pins unless something else configures them later. Can you check the PIN_CNF registers with a debugger when in idle to see what state they are really in?

Alternatively, how is the VDD to the acceleration sensor switched off? Could there be an issue with that mechanism?

Br,

Einar

RE: Power consumption is too high after sending SPIM3 to sleep

matthk — Thu, 13 Apr 2023 19:23:26 GMT

Hello Einar,

I think having found - but not already resolved - the source of the problem. I suppose that in the acceleration sensor there are ESD-protecting diodes at the inputs (for example at the SPI-interface) which discharge voltage peaks to the supply voltage pins. In my case it seems that the acceleration sensor after switching off the supply voltage at its VDD pins stays supplied by these diodes by at least one signal at the SPI interface still at high logic level.

With the debugger I see that when preparing the sleep mode for the nRF52840 using the upper shown functions first the SPI is disabled then uninitialized; then the VDD of the acceleration sensor is switched off. But later in the sleep mode I see - for example at the Chip Select pin - still that pin outputting a high logic level. So I suppose that this supplies the acceleration sensor; the measured current of additional measured 100 µA at 3 V - which are converted to 1,8V in my design result in about 167 µA which is quite near to the announced current consumption of the acceleration sensor in the datasheet. So it seems that the nRF52840 supplies the acceleration sensor by at least one SPI-signal when VDD of the acceleration sensor is switched off.

I will test this tomorrow, but if that is the source of the problem I will have to find out, why after disabling and uninitialising of the respective SPI still some signals keep high level?!?

Best regards,

matthK

RE: Power consumption is too high after sending SPIM3 to sleep

Einar Thorsrud — Wed, 12 Apr 2023 13:44:43 GMT

Hi,

I am sorry for the late reply. Have you had any progress with this?

[quote user="matthk"]Is it recommended to configure the SPI pins (GPIOs) to inputs using nrf_gpio_cfg_default() when disable and uninit of the respective SPI are executed?[/quote]

Yes, but this is done by the driver when you call nrfx_spim_uninit(), so you do not need to do it explicitly.

[quote user="matthk"]What can I try next?[/quote]

I see. Do you know if it is the nRF or other components on the board that draw more current after SPI have been in use (perhaps the slave device)? If it is possible to get measurements where you could get isolated number for that, it could be useful.

If it is the nRF, and you do disable it and apply the workaround we have discussed earlier I am not able to come up with that could cause the additional current consumption. The difference is 100 uA, which is anyway too little to be caused by the HF clock running, so it must be something else.

RE: Power consumption is too high after sending SPIM3 to sleep

matthk — Mon, 03 Apr 2023 08:45:36 GMT

Hello Einar,

I have implemented your suggestions, but still the supply current is at 125 µA in sleep mode when using SPIM3 before. Without initialise / enable / use / disable / uninit of SPIM3 I see only 25 µA in sleep mode at the 3 V input of our electronics.

void Disable_SPI2_Bus(void)
{
	NRF_SPIM2->TASKS_STOP = 1;
	while(!NRF_SPIM2->EVENTS_STOPPED);  // necessary for Power down

	dth_nrf_spim_disable_spim_FRAM();	// Contains only nrf_spim_disable((NRF_SPIM_Type *) &spi2);
	UnInitializeSPI2Instance();			// Contains nrfx_spim_uninit(&spi2); and bSPI2InitDone = false;

	*(volatile uint32_t *)0x40023FFC = 0;
	*(volatile uint32_t *)0x40023FFC;	// workaround for Error(89) for SPIM2
	*(volatile uint32_t *)0x40023FFC = 1;


		#ifdef EYSKBNZ
	NRF_P0->DIR &= 0xF1FFFFFF;			// Configure Port 0 Bit 25, 26, 27 as Input; bit 24 (MISO) stays as Input
	NRF_P0->PIN_CNF[24] = 0x00000002;	// Configure Port 0.24 (MISO) as Input, without Pull-Up
	NRF_P0->PIN_CNF[25] = 0x00000002;	// Configure Port 0.25 (MOSI) as Input, without Pull-Up
	NRF_P0->PIN_CNF[27] = 0x00000002;	// Configure Port 0.27 (CS KXxxx) as Input, without Pull-Up
	NRF_P0->PIN_CNF[26] = 0x00000002;	// Configure Port 0.26 (SCLK) as Input, without Pull-Up
	NRF_P0->OUT &= 0xF1FFFFFF;			// Set Port 25, 26, 27 to 0
		#endif
//	NRF_SPIM2->ENABLE = 0;
	NRF_LOG_INFO("Disable SPI2 Bus");
}
	#endif

	#ifdef SWITCH_OFF_VCC2

void Disable_KXxxx(void)
{
		#ifdef SPI_BUS_KXxxx_ACTIVE
	NRF_SPIM3->TASKS_STOP = 1;
	while(!NRF_SPIM3->EVENTS_STOPPED); 	// necessary for Power down

	dth_nrf_spim_disable_spim_KXxxx();	// contains only nrf_spim_disable((NRF_SPIM_Type *) &spi);
	UnInitializeSPIInstance();			// contains nrfx_spim_uninit(&spi);	and bSPIInitDone = false;	// Uninitialize SPIM3

	*(volatile uint32_t *)0x4002FFFC = 0;
	*(volatile uint32_t *)0x4002FFFC;	// workaround for Error(89) for SPIM3
	*(volatile uint32_t *)0x4002FFFC = 1;

	NRF_LOG_INFO("Disable SPI Bus");

			#ifdef EYSKBNZ
//	NRF_P0->DIR &= 0xFFE7FF9F;			// Configure Port 0 Bit 6, 19, 20 as Input; bit 5 (MISO) stays as Input
//	nrf_gpio_cfg_default(5);
//	NRF_P0->PIN_CNF[5] = 0x00000002;	// Configure Port 0.05 (MISO) as Input, without Pull-Up
//	nrf_gpio_cfg_default(6);
//	NRF_P0->PIN_CNF[6] = 0x00000002;	// Configure Port 0.06 (MOSI) as Input, without Pull-Up
//	nrf_gpio_cfg_default(19);
//	NRF_P0->PIN_CNF[19] = 0x00000002;	// Configure Port 0.19 (CS KXxxx) as Input, without Pull-Up
//	nrf_gpio_cfg_default(20);
//	NRF_P0->PIN_CNF[20] = 0x00000002;	// Configure Port 0.20 (SCLK) as Input, without Pull-Up
//	NRF_P0->OUT &= 0xFFE7FF9F;			// Set Port 5, 6, 19, 20 to 0
			#endif
		#endif

		#ifdef KXxxx_SENSOR
	if (bVCCKXxxx_On == true)
	{
		Disable_Vcc_KXxxx();
		KXxxxState.ui8Initialized = false;
	}
	NRF_GPIOTE->EVENTS_IN[0] = 0;
		#endif
//	KXxxx_ReadInterruptRegINT_REL();	// only for test
}

Is it recommended to configure the SPI pins (GPIOs) to inputs using nrf_gpio_cfg_default() when disable and uninit of the respective SPI are executed?

What can I try next?

Best regards,

matthK

RE: Power consumption is too high after sending SPIM3 to sleep

Einar Thorsrud — Fri, 31 Mar 2023 15:12:32 GMT

Hi,

[quote user="matthk"]1. Do I have to execute the following workaround for erratum 89 only in the TWI1 disabling function, which is in my case 0x40004FFC or is that also needed at disabling of SPIM2 (at 0x40023FFC) and SPIM3 (at 0x4002FFFC)?[/quote]

The workaround is specific for each peripheral, so if the issue is related to TWI1 for instance, you need to use the workaround for TWI1, and the same for the others. That means, when you are done and uninit it, use the workaround. (Note that the address is different for each peripheral except for those with the same peripheral ID. Just find the base address in the product specification, and add 0xFFC.)

[quote user="matthk"]2. Is disabling of spi (SPIM3) sufficient or is an uninitialize needed?[/quote]

The workaround will reset the peripheral, so that any configurations is lost. So you should uninit the driver and re-init it afterwards (if not, there can be a mismatch if you don't re-init the driver again, as some registers are only written to during initialization).

RE: Power consumption is too high after sending SPIM3 to sleep

matthk — Fri, 31 Mar 2023 08:55:38 GMT

Hi Einar,

yes, the system is in the considered Phase in low power - please see the endless loop in the main()-function below.

For explaining the HW:

We have a temperature sensor at TWI with TWI_INSTANCE_ID 1. Then we have an acceleration sensor KXxxx where we want to use SPIM3 to be able to run higher than 8 MB/s. And then we have an external FRAM which communicates with SPIM2. We have also 2 Hall sensors at GPIOs where one detects if the supervised motor turns and the second one measures the speed. If the motor turns, the temperature sensor and the acceleration sensor as well as the Hall have to measure speed, temperature and acceleration which are transmitted by BLE. The GPIOTE unit is used. The supply voltage of the temperature sensor and the acceleration sensor can be switched off by GPIO. The supply voltage of the electronics is 1,8V. One additional GPIO is used to control an external FET.

As we have actually no (battery buffered) RealTimeClock we use RTC2 which creates every 125ms an interrupt, in this every 8th pass a seconds-based time variable is increased.

The problem appears when the motor stopps and the electronics shall go to very low energy consumption. The procedure for going to energy saving mode is:

First reconfigure the GPIO which drives the external FET as input

Then write SLEEP command to the FRAM and disable spi2 (which uses SPIM2)

Then switch off VDD for the second (fast speed, but high power consumption) Hall sensor, the first (slow speed, but extremly low-power) is needed for the detection of the next rotation

Then switch off VDD of the temperature sensor and the internal pull-ups (TWI-Bus)

And then finally disable spi (which uses SPIM3) for the acceleration sensor and switch off its VDD

By using compiler switches (#ifdef...#endif) I could find out that the operating current of our electronics goes down to about 25 µA when using the upper described go to sleep procedure with the only exception of the SPIM3 unit. If the acceleration sensor is switched on at start turning and then switched off like described, but without initialising SPIM3 (by this there is no communication) the supply current goes down to about 25 µA; when I allow the communication by setting #define SPI_BUS_KXxxx_ACTIVE then after disabling everything 125 µA are drawn. So I don't know what is missing at the deactivation of SPIM3 to achieve the 25 µA supply current...

Just one sentence to the currents: The mentioned currents are measured at the (3V) input of the electronics; as there is a DC/DC converter for supplying the electronics with 1,8V the current at 1,8V is apprixmately (not considering losses) 3,0/1,8 = 1,67 times higher.

Now I have 2 questions:

1. Do I have to execute the following workaround for erratum 89 only in the TWI1 disabling function, which is in my case 0x40004FFC or is that also needed at disabling of SPIM2 (at 0x40023FFC) and SPIM3 (at 0x4002FFFC)?

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

2. Is disabling of spi (SPIM3) sufficient or is an uninitialize needed?

What can I test/check next?

Best regards,

matthK

#ifdef SPI_BUS_KXxxx_ACTIVE
/**@brief Function for handling the idle state (main loop).
 *
 * @details If there is no pending log operation, then sleep until next the next event occurs.
 */
static void idle_state_handle(void)
{
    if (NRF_LOG_PROCESS() == false)
    {
        nrf_pwr_mgmt_run();
    }
}
#endif

/**@brief Function for the Power manager.
 */
static void power_manage(void)
{
    ret_code_t err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}
    
	
int main(void)
{
	// Initialize.
	ret_code_t err_code = NRF_SUCCESS;
	
	// a lot of initialization and other stuff
	
	
	// Enter endless loop.
    for (;;)
    {
        if (mDhkeyPending == true)
        {
            err_code = nrf_ble_lesc_request_handler(); //TODO: CRYPTO should run in low interrupt priority like an idle-loop in the main application context
            APP_ERROR_CHECK(err_code);

            mDhkeyPending = false;
        }
   		if (NRF_LOG_PROCESS() == false) //  && (nrf_sdh_is_enabled() == true))
   		{
   			// No more logs in the buffer
   			power_manage();
   		}

#ifdef SPI_BUS_KXxxx_ACTIVE
// 		nrf_pwr_mgmt_run();
// 		__WFE();						// use only when no Softdevice is used
   		idle_state_handle();

   		NRF_LOG_FLUSH();
#endif
    }
}

RE: Power consumption is too high after sending SPIM3 to sleep

Einar Thorsrud — Thu, 30 Mar 2023 14:52:17 GMT

Hi,

It is not clear to me what current consumption you are measuring and in which state. Are you in a low power system on moe (sd_app_evt_wait() or WFE or similar)? Which resources should be active at this point, and what current do you measure? In the various situations (I see 125 uA and 25 uA but the specifics of what these numbers represent is not clear to me).

And regarding the workaround for erratum 89 I see you have commented it out, and the order is wrong. It should be like this:

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

And this should be doene after you have uninitialized everything related to TWIM. So no new calls to the driver after this (before you re-initialize it the next time you need to use it).

RE: Power consumption is too high after sending SPIM3 to sleep

matthk — Wed, 29 Mar 2023 14:17:50 GMT

Just to complete: I have also tested the workaround for error 195 SPIM: SPIM3 continues to draw current after disabling, but no change...

void dth_nrf_spim_disable_spim_KXxxx(void)
{
	nrf_spim_disable((NRF_SPIM_Type *) &spi);
	*(volatile uint32_t *)0x4002F004 = 1;
}