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]

Hello,

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.

Could you please elaborate on this - which pins were you using on the DK, and which pins have you changed to on the finished product? How do you see the interrupt toggling, are you scoping the line?
I suspect that this might be an issue with the Pin Assignment.

The only difference is that the PCA code included the board.c files.

Could you possibly share the code snippet of the interrupt pin configuration from both before and after the pin change?

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.

What does this error message say? How is this error handled, since the application is able to continue?

Looking forward to resolve this issue together!

Best regards,
Karl

[Constantin]

Hello,

Sure the Pins for interrupt I used at the development board is the following:

	nrf_gpio_cfg_input(IMU_INT2, NRF_GPIO_PIN_NOPULL);
	nrf_gpio_cfg_sense_set(IMU_INT2, NRF_GPIO_PIN_SENSE_HIGH);

For the PCA10056 the IMU_INT2 is NRF_GPIO_PIN_MAP(0, 27) which works fine. For the BMD340 it is NRF_GPIO_PIN_MAP(1, 3). Again, this pin for the BMD340 runs fine when I execute the normal interrupt it is triggered as expected. Only when I go to sleep it fails to wake up.

The error messages at both boards are the following:

00> <info> SENSTATE: Switch off command received
00> <info> BLE_CONN_HANDLER: Disconnected connection handle 0
00> <info> BLE_CONN_HANDLER: Idle Advertising.
00> <info> BLE_CONN_HANDLER: Error 2006
00> <info> BLE_CONN_HANDLER: Fast advertising.
00> <info> BLE_CONN_HANDLER: Disconnected.

The only difference is that the PCA10056 can be woken up and the BMD340 not. The code for configuring the interrupt is during normal application is the following:

	nrf_drv_gpiote_in_config_t DT_INT_CFG = {NRF_GPIOTE_POLARITY_LOTOHI, NRF_GPIO_PIN_NOPULL, false, true};
	APP_ERROR_CHECK(nrf_drv_gpiote_in_init(IMU_INT2, &DT_INT_CFG, bmx_tap_handler));
	nrf_drv_gpiote_in_event_enable(IMU_INT2, true);

I hope this helps?

Kind regards,

C.W.

[Karl Ylvisaker]

Hello C.W,

Constantin said:

For the PCA10056 the IMU_INT2 is NRF_GPIO_PIN_MAP(0, 27) which works fine. For the BMD340 it is NRF_GPIO_PIN_MAP(1, 3). Again, this pin for the BMD340 runs fine when I execute the normal interrupt it is triggered as expected. Only when I go to sleep it fails to wake up.

Thank you for elaborating. I do not see anything wrong with these pin choices, or how they could prevent waking up. It should be enough to have nrf_gpio_cfg_sense_set on a GPIOTE Event enabled pin. Could you confirm for me whether you mean SYSTEM_OFF or SYSTEM_ON sleep when you say 'fails to wake up'?
In either case, could I see the code section leading up to the sleep entry (i.e the shutdown prepare section, or the section leading up to SYSTEM_ON sleep)?
I also notice that you are using NOPULL - do you have external pullups / pulldowns on your lines, or is there another reason why you are not using pull?

Constantin said:

The error messages at both boards are the following:

Could you place some breakpoints in your BLE_CONN_HANDLER to find out exactly which function returns this error? Have you implemented any error handling for this particular error in your application?

Best regards,
Karl

[Constantin]

Could you confirm for me whether you mean SYSTEM_OFF or SYSTEM_ON sleep when you say 'fails to wake up'?

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

I also notice that you are using NOPULL - do you have external pullups / pulldowns on your lines, or is there another reason why you are not using pull?

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

Could you place some breakpoints in your BLE_CONN_HANDLER to find out exactly which function returns this error? Have you implemented any error handling for this particular error in your application?

Sure I can. I will try

[Constantin]

Okay the error code on both boards is produced by sd_power_system_off with error message 0x2006.