This is not specifically a Feather issue, more of a SDK usage issue I believe.
Using SDK v1.9.1.
I am using the following code, but am unable to control in P0.30 (D3 on the silkscreen).
I can control P0.29 and P0.04 with this below code without issues.

As opposed to most other gpio, I think this one is on PORTD instead of PORTC, could it be that PORTD is not powered up for some reason and I am missing that?

The below code is copy/paste from a larger project so hopefully I did not forget any details, but this is the idea.

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

// Feather Pin (D2) 29 = SD_SWITCH (output, active low, nRF9160 connected low)
#define SD_SWITCH_PIN                 30 // pin D3
#define SD_SWITCH_PIN_NAME            "GPIO_0"
#define SD_SWITCH_BIT                 BIT(SD_SWITCH_PIN)

void main(void)
{
    const struct device *gpio_dev;
    uint32_t gpioValue = 0U;
    int err;

    const char* const gpioName = SD_SWITCH_PIN_NAME;
    gpio_dev = device_get_binding(gpioName);
    if (!gpio_dev) {
        LOG_ERR("Cannot bind gpio device");
    } else {
        err = gpio_pin_configure(gpio_dev, SD_SWITCH_PIN, GPIO_OUTPUT_ACTIVE);
        if (err) {
            LOG_ERR("Cannot configure SD_SWITCH_PIN gpio");
        } else {
            printk("SD_SWITCH_PIN gpio configured\n");
        }
    }
    enable_gpio();
    while(1);
}

void enable_gpio(void) {
    const struct device *gpio_dev;
    const char* const gpioName = SD_SWITCH_PIN_NAME;
    gpio_dev = device_get_binding(gpioName);
    if (!gpio_dev) {
        LOG_ERR("Cannot bind gpio device");
    } else {
        gpio_pin_set(gpio_dev, SD_SWITCH_PIN, 0);
    }
}

    I can control P0.14 on PORTD so it is not port related, I am searching for something that is holding P0.30 in the device tree config…

      aldras on the nRF9160 Feather, D3 is connected to the INT1 pin. It’s a push-pull output so it will hold the line.

      You can cut JMP1 if you want to use D3 separately.

        Oh thanks Jared, I did not catch that since traces jump around with tags on the schematic.
        I will avoid that pin for future use. However I was planning to use P0.29 too, I will try to avoid that one as well.

          I notice that INT2 is not jumped, it seems, but I still want to avoid that for just incase for future use.

            Yep P0.29 is not connected but if you ever want to use the accel interrupts you’ll want to avoid using it.

              Terms and Conditions | Privacy Policy