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

GPIO configuration issues AFTER moving to NCS 1.6.1

The following code works perfectly fine every single time if i use NCS 1.5.1..we decided to move to 1.6.1 recently, and while we were able to get everything else working, GPIO interrupts and and IO for GPIOs that are NOT part of the device tree (but defined outside) don't seem to work.. As in same EXACT project with no changes but just using 1.6.1 SDK has different behavior. 

behavior of the following piece of code.. if someone can tell me what changed in 1.6.1 that is related to GPIO management, that will be greatly appreciated.. 

SDK 1.5.1: interrupts every time we touch the touch surface
SDK 1.6.1: no interrupts what so ever.. build has no warnings , the log has no errors/warning either

//Touch interrupt
#define NRF53440_GPIO_PIN_FOR_ZTW622_TOUCH_INTR (1) //P1.1 

volatile bool touch_ztw622_intr_happened = false;
void touch_ztw622_intr_process(const struct device *dev,
    struct gpio_callback *cb,
    uint32_t pins) {

  printk("\n touch intr happened");
  touch_ztw622_intr_happened = true;
#if KBPRO_ENABLE_TOUCH
  k_sem_give(kbpro_touch_get_sem_details());
#endif 
}

//works on 1.5.1 but not on 1.6.1
bool kbpro_nrf5340_gpio_interrupt_for_touch_ztw622_setup(void) {
  int ret;

  gpio_pin_configure(gpio_1_dev, NRF53440_GPIO_PIN_FOR_ZTW622_TOUCH_INTR, GPIO_INPUT);

  ret = gpio_pin_interrupt_configure(gpio_1_dev, NRF53440_GPIO_PIN_FOR_ZTW622_TOUCH_INTR, GPIO_INT_EDGE_FALLING); //GPIO_INT_LEVEL_LOW);
  if (ret != 0) {
    printk("Error %d: failed to configure Touch interrupt pin %d\n", ret, NRF53440_GPIO_PIN_FOR_ZTW622_TOUCH_INTR);
    return false;
  }

  gpio_init_callback(&touch_ztw622_cb,
      touch_ztw622_intr_process,
      BIT(NRF53440_GPIO_PIN_FOR_ZTW622_TOUCH_INTR));

  gpio_add_callback(gpio_1_dev, &touch_ztw622_cb);
  return true;
}

any feedback will be very helpful

Parents
  • I tried editing v1.6.1\zephyr\boards\arm\nrf5340dk_nrf5340\nrf5340_cpunet_reset.c (I use secure build).. i saw the code uses the pins 0 and 1 (of port 1) so i commented the usage.. I HAVE NO IDEA what's the side effect of this is (yet) but if i do this, i can get interrupts on my configured pin.. 
    can you please consider helping me understand what might be going on given this is Nordic's code ?

    Like I  mentioned, this issue happens only if you use BLE.. if you have a simple application without BLE (and hence no netcore), life is good.. but who would need nrf5340 if that's the use case :-)

    static void remoteproc_mgr_config(void)
    {
    /* UARTE */
    /* Assign specific GPIOs that will be used to get UARTE from
    * nRF5340 Network MCU.
    */
    #if 0 ///---------------------- commented these lines
    CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_TX] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_RX] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    NRF_P0->PIN_CNF[CPUNET_UARTE_PIN_RTS] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    NRF_P0->PIN_CNF[CPUNET_UARTE_PIN_CTS] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    #endif
    /* Route Bluetooth Controller Debug Pins */
    DEBUG_SETUP();

    /* Retain nRF5340 Network MCU in Secure domain (bus
    * accesses by Network MCU will have Secure attribute set).
    */
    NRF_SPU->EXTDOMAIN[0].PERM = 1 << 4;
    }
    #endif /* !CONFIG_TRUSTED_EXECUTION_NONSECURE */

Reply
  • I tried editing v1.6.1\zephyr\boards\arm\nrf5340dk_nrf5340\nrf5340_cpunet_reset.c (I use secure build).. i saw the code uses the pins 0 and 1 (of port 1) so i commented the usage.. I HAVE NO IDEA what's the side effect of this is (yet) but if i do this, i can get interrupts on my configured pin.. 
    can you please consider helping me understand what might be going on given this is Nordic's code ?

    Like I  mentioned, this issue happens only if you use BLE.. if you have a simple application without BLE (and hence no netcore), life is good.. but who would need nrf5340 if that's the use case :-)

    static void remoteproc_mgr_config(void)
    {
    /* UARTE */
    /* Assign specific GPIOs that will be used to get UARTE from
    * nRF5340 Network MCU.
    */
    #if 0 ///---------------------- commented these lines
    CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_TX] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    CPUNET_UARTE_PORT_TRX->PIN_CNF[CPUNET_UARTE_PIN_RX] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    NRF_P0->PIN_CNF[CPUNET_UARTE_PIN_RTS] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    NRF_P0->PIN_CNF[CPUNET_UARTE_PIN_CTS] =
    GPIO_PIN_CNF_MCUSEL_NetworkMCU << GPIO_PIN_CNF_MCUSEL_Pos;
    #endif
    /* Route Bluetooth Controller Debug Pins */
    DEBUG_SETUP();

    /* Retain nRF5340 Network MCU in Secure domain (bus
    * accesses by Network MCU will have Secure attribute set).
    */
    NRF_SPU->EXTDOMAIN[0].PERM = 1 << 4;
    }
    #endif /* !CONFIG_TRUSTED_EXECUTION_NONSECURE */

Children
Related