sd_power_system_off() interfere with GPIOTE port interrupts

RE: sd_power_system_off() interfere with GPIOTE port interrupts

Sigurd — Fri, 15 Sep 2017 11:34:22 GMT

Hi,

If you want to use sd_ function calls within the FreeRTOS context, then setting it to 5 is the correct option. See this figure here.

RE: sd_power_system_off() interfere with GPIOTE port interrupts

Mindaugas Tinteris — Thu, 14 Sep 2017 14:08:33 GMT

By making #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5 in FreeRTOSConfig.h now sd_power_system_off() works fine, but I am not sure if it's the right option.

RE: sd_power_system_off() interfere with GPIOTE port interrupts

Mindaugas Tinteris — Thu, 14 Sep 2017 13:50:06 GMT

GPIO_BUTTON_MAIN is 20. Yes I checked, NRF_P0->PIN_CNF[GPIO_BUTTON_MAIN] is indeed 0x0003000C. I'll add one important thing to the whole story: I call sd_power_system_off() from FreeRTOS idle task hook. Afte looking more carefully I discovered, that system goes to Hard Fault Handler after calling sd_power_system_off() and it seems to me that I can find the answer to this here. Now it's only unclear, how to change IDLE task interrupt priority level in FreeRTOS. Any hints would be appreciated.

RE: sd_power_system_off() interfere with GPIOTE port interrupts

Sigurd — Thu, 14 Sep 2017 13:10:34 GMT

I just tested the code you provided, and it worked fine to exit sleep mode with it. The sd_power_system_off() does not interfere with any GPIOTE interrupt settings.

What pin is GPIO_BUTTON_MAIN ? Could you debug/print the GPIO configuration register value of the pin you use, and see if it's correctly configured before you enter system off?

The NRF_P0->PIN_CNF[GPIO_BUTTON_MAIN] should be 0x0003000C if configured correctly.

RE: sd_power_system_off() interfere with GPIOTE port interrupts

Mindaugas Tinteris — Thu, 14 Sep 2017 12:34:29 GMT

Please, read my post original carefully. I do use Sense functionality, and it is working fine unless I use sd_power_system_off(). I am aware of the issue that I should not access POWER register directly when using SoftDevice, that's why I am asking this question. I use this code to setup a pin:

nrf_drv_gpiote_in_config_t in_config_button = GPIOTE_CONFIG_IN_SENSE_HITOLO(false);
in_config_button.pull = NRF_GPIO_PIN_PULLUP;
err_code = nrf_drv_gpiote_in_init(GPIO_BUTTON_MAIN, &in_config_button, ButtonInterruptHandler);
APP_ERROR_CHECK(err_code);
nrf_drv_gpiote_in_event_enable(GPIO_BUTTON_MAIN, true);

I'll repeat myself. The system wakes up if going to SysOff by using POWER reg. This doesn't work only if I use sd_power_system_off().

RE: sd_power_system_off() interfere with GPIOTE port interrupts

Sigurd — Thu, 14 Sep 2017 10:55:20 GMT

Hi,

When in System OFF mode, the device can be woken up through one of the following signals:

The DETECT signal, optionally generated by the GPIO peripheral
The ANADETECT signal, optionally generated by the LPCOMP module
The SENSE signal, optionally generated by the NFC module to “wake-on-field”
A reset

GPIOTE will not wake the processor up from SYSTEM OFF, the sense mechanism in the GPIO peripheral will. If you enable the sense mechanism, a DETECT signal will be generated if the correct sense is detected on one of the pins.

Try to configure the pin you want to use to wake the chip up like this:

nrf_gpio_cfg_sense_input(PIN NUMBER, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);

Also note that when the SoftDevice is enabled, the POWER register is restricted, and should not be accessed directly. When the SoftDevice is enabled, you should therefore only use the sd_power_system_off() function to go to sleep.