Slow time-to-enable GPIO using Connect SDK on nRF52832

[Anthony W]

I'm using the nRF52832 in an energy harvesting application, where I need to cold-start the device and set a GPIO output high in under 50ms in order to latch the power supply. From everything I can tell in the spec, this should not be a problem at all, however in even the simplest application this is taking about 350ms to happen. I'm using the Connect SDK which might be the problem, but that still seems like quite a bit of latency.

Any ideas whether this is possible on this device (preferably with the Connect SDK), and where I might look to fix this issue?

[Jared]

Hi,

Can you specify where you are setting the GPIO? In main()? 

regards
Jared 

[Anthony W]

I define it in an overlay:

/ {
    gpiocustom {
        compatible = "gpio-keys";
        gpiocus0: gpiocus_0 {
            gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;
            label = "Custom gpio 28";
        };
    };
    aliases {
        gpiocus0 = &gpiocus0;
    };
};

I'm using the u-blox BMD-350 module embedded in the BMD-35-EVK development board (ubx_bmd300eval_nrf52832 spec). Power (1.8V) is applied directly to the module via the external power header.

Source file is pretty simple. It enables the GPIO and blinks an LED.

#include <zephyr.h>
#include <drivers/gpio.h>

#define SLEEP_TIME_MS   1000

#define LED0_NODE DT_ALIAS(led0)
#define EN_1V8_NODE DT_ALIAS(gpiocus0)

static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);
static const struct gpio_dt_spec en_1v8 = GPIO_DT_SPEC_GET(EN_1V8_NODE, gpios);

void main(void)
{
	int ret;

	if (!device_is_ready(led.port)) return;
	if (!device_is_ready(en_1v8.port)) return;

	if (gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE) < 0) return;
	if (gpio_pin_configure_dt(&en_1v8, GPIO_OUTPUT_ACTIVE) < 0) return;

	while (true) {
		ret = gpio_pin_toggle_dt(&led);
		if (ret < 0) {
			return;
		}
		k_msleep(SLEEP_TIME_MS);
	}
}

[Jared]

Hi,

Could you try to use the SYS_INIT function as in this example? That would set the GPIO much earlier during boot. You might have to write directly to the GPIO register instead of using the driver as it might not be available at that stage. Here is documentation for the function. I think this method would reduce the delay considerably. 

regards
Jared 

[Anthony W]

Thank you, this looks promising. I haven't had a chance to try this yet since the J-Link OB interface seems to have gotten corrupted on the dev board, but once I fix this I'll try it and let you know if it worked.

[Jared]

Great,

Keep me updated!

regards

Jared