CPU does not wake up after sd_power_system_off

[Constantin]

Hi,

I a have a firmware which was developed on a PCA10056 development board. We attached an external sensor which can produce an interrupt.

The interrupt is used to wake up the system from sd_power_system_off. On the development in release mode the CPU sleeps correctly and can be woken up. On the real product PCB the code is exactly the same. Only the Pins are changed. But I can see the interrupt toggling and producing a Log message on both systems but on the real PCB the CPU does not wake up.

Again the code base is exactly the same, both are compiled without DEBUG etc.. The only difference is that the PCA code included the board.c files.

The strange thing is that despite other notifications in this forum the PCA board can be brought to system sleep with the Debugger console connected. And it still shows an error return value but works as expected. For the real PCB the same error message is notified but the application crashes / freezes at the end.

Any suggestion would be valuable.

Kind regards,

PS: SDK 17.0.1 was used and the PCB module was BMD340 of ublox without external oszillator. Same clock settings were used for PCA10056.

[Karl Ylvisaker]

Constantin said:

This is difficult to debug because I cannot really debug in this case.

No, sorry, of course it is SYSTEM_OFF, as you mention in your original ticket text. My apologies for the oversight.
Please note that the device only goes into emulated SYSTEM_OFF when debugging. Could you show the section of code leading up to the call to sd_power_system_off?

Constantin said:

No there is no external pull up and I double checked that the interrupt really occurs and it occurs measured with an oszilloscope.

In general it is recommended that you use either PULLUP or PULLDOWN on your inputs, so that the voltages always are in a known state. In this case I would have added PULLDOWN on your interrupt pin, to make sure that it is LOW whenever it is not explicitly set to HIGH on either side of the connection.
What is the pulse-length of the interrupt signal?

Constantin said:

Sure I can. I will try

Great! I look forward to hearing what you find. I am not sure that this error is linked to the non-waking behavior, but it is still good to rid the application of any errors and warnings before deployment.

Best regards,
Karl

[Constantin]

void BLEConnectionHandler::sleep_mode_enter(void)
{
	ret_code_t err_code;

    // Prepare wakeup buttons.
	nrf_gpio_cfg_input(IMU_INT2, NRF_GPIO_PIN_NOPULL);
	nrf_gpio_cfg_sense_set(IMU_INT2, NRF_GPIO_PIN_SENSE_HIGH);

    // TODO: power off
	nrf_gpio_pin_clear(LED_ERROR);
	nrf_delay_ms(500);
	nrf_gpio_pin_set(LED_ERROR);

    // Go to system-off mode (this function will not return; wakeup will cause a reset).
	#ifdef DEBUG
	err_code = sd_power_system_off();
	NRF_LOG_INFO("Error code %x", err_code);
	 while(1);
	#else
	sd_power_system_off();
	#endif  // DEBUG_NRF
}

The pulse width of  the signal is arround 100 usec since it is a non-latched interrupt. The function sleep_mode_enter is called as soom as the advertising switched to IDLE.

[Karl Ylvisaker]

Hello again,

Thank you for your patience with this, and for providing the code snippet leading up to SYSTEM_OFF.

I do not immediately see anything wrong with your code here.
Could you elaborate on your choice not to use PULL on your input pins? Leaving input pins floating is seldom a good thing as it could yield unintended results. For example if the input on the pin is latched immediately after configuration, and thus there will be no transition to HIGH during sleep.

Could you try to flash the device, disconnect the debugger, wait until advertising timeout and SYSTEM_OFF sleep, and then use the oscilloscope to scope the interrupt pin IMU_INT2 and tell me what you see when you do?

Best regards,
Karl