nRF52 reset behaviour on GPIO output pins

[Eliot Stock]

Hi. I have a board here based on the nRF52832, using SD 132 and SDK 13.0.0, with a modem on it that I'd like to keep powered on even when the Nordic is in system off mode. Power to the modem is controlled by a GPIO output pin on the Nordic:

nrf_gpio_cfg_output(MODEM_PWR_EN);
nrf_gpio_pin_set(MODEM_PWR_EN); // Active high.

Some time later I then go into sys off by running:

nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);

and continuing to run the scheduler after that call.

What I'm seeing is that the modem does indeed stay powered up while I'm in sys off. But I also have an accelerometer hooked up to wake the Nordic on motion:

nrf_gpio_cfg_sense_input(ACCELEROMETER_INTERRUPT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_SENSE_HIGH);

and the minute that happens, on the reset, the modem loses its power. If I run the debugger, I know that sys off is only simulated and so perhaps I can expect to see confusing behaviour there, but I've been able to see the same thing happening with the debugger detached.

Other devzone questions imply that the reset behaviour is different when coming from sys off than for other resets, and that this shouldn't happen. When does this pin go low and why?

[endnode]

That's what I would suspect: GPIOs might get reset in start-up code before you even enter your main function. Still I would debug this by temporarily redirecting this GPIO to some line which is accessible for logical analyzer/oscilloscope (in the worst case I assume you have P0.21 aka SWD RESET which can be re-purposed as GPIO) and see when exactly line drops to LOW and for how long. If you have another spare GPIO it might be good to use it for signalling where in the code you are (before going to SYSTEM_OFF/after waking up through reset) so you can see when exactly the line get reset (which might indicate if it is in SW - potentially patchable - or if it is HW property of the chip - and so hard to workaround). I'm not and HW engineer but I assume that some capacity might solve this effect (short LOW pulse would still look like HIGH on output)...