This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 reset behaviour on GPIO output pins

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?

  • Any chance to catch the sequence on that GPIO line with fast logical analyzer or oscilloscope? If it realy goes HIGH/LOW/HIGH during wake-up of nRF5x from SYSTEM_OFF then for how long? You can detect this in FW through RESETREAS or GPREGRET registers so then during init sequence of your GPIO output PIN you can avoid certain steps (if they cause change of GPIO line state).

  • It's on a development board where I don't have good access to the pin, at least not with all the motion I need to subject the board to in order to get it to wake from sys off, so it's not going to be possible to hook up my logic analyser. But I do have an LED on the board showing the state of the pin and whether the modem has power. If I run gdb and let it break at the top of main, the pin has already gone low by then. None of my code has executed, so it's not something I'm doing in my code that has set it low.

  • 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)...

Related