GPIOTE interrupt not working with softdevice S140?

[Sietse]

Hello,

From the ble_app_uart example I created a version where instead of the UART the incoming data over BLE is processed using the scheduler.

Processing is not much more then echoing the incoming strings back over BLE in the scheduler_event_handler. This works fine on a nrf52840 (android nano 33 ble).

But when I try to create an interrupt via GPIOTE, then the code stops working.

  ret_code_t err_code;
  if(!nrf_drv_gpiote_is_init())
    {
      err_code = nrf_drv_gpiote_init();
      APP_ERROR_CHECK(err_code);
      nrf_gpio_pin_set(LED_DL2);
    }
  nrf_gpio_pin_clear(LED_DL3_RED);

  nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(true);
  in_config.pull = NRF_GPIO_PIN_PULLUP;

  err_code = nrf_drv_gpiote_in_init(BUTTON_1, &in_config, in_pin_handler);
  APP_ERROR_CHECK(err_code);
  nrf_gpio_pin_set(LED_DL1);
  return;

  nrf_drv_gpiote_in_event_enable(BUTTON_1, true);

This is the init code for gpiote, the only change to the code. Note that I use LEDs to show to where the code gets.

We can see that nrf_drv_gpiote_is_init() holds: the softdevice does that. The strange thing is that nrf_drv_gpiote_in_init() does not return as shown by the LED_DL2 led NOT lighting up.

There is a return statement here to make sure the event is not enabled, to make for a simpler scenario.

The same init code works ok when not using a softdevice, so why is the init-function not returning when using a  softdevice? Thanks in advance.

[Edvin]

Hello,

Does the arduino (I assume it is not "android") nano 33 ble have a debugger? If not, have you tried to use a DK?

 

We can see that nrf_drv_gpiote_is_init() holds: the softdevice does that.

 The function nrf_drv_gpiote_is_init() can't hold anything. Are you basing this on the assumption that nrf_gpio_pin_clear(LED_DL3_RED); is not reached? If so, you should check what the APP_ERROR_CHECK(err_code) does, and what err_code is after nrf_drv_gpiote_init(); If APP_ERROR_CHECK(err_code) receives an err_code != 0, then the error handler will kick in, and either halt the application, or reset the application. In either case nrf_gpiote_pin_clear() will not be reached. 

So does it have a debugger? Do you have any way to either step in the application, or monitor a log from the device?

Best regards,

Edvin

[Sietse]

Thanks for the quick response!

With holds I mean "its value is true", so the if-branch is skipped.

I now changed the last part of the code into

  err_code = nrf_drv_gpiote_in_init(BUTTON_1, &in_config, in_pin_handler);
  nrf_gpio_pin_set(LED_DL1);
  if (err_code == 0) nrf_gpio_pin_set(LED_DL3_GRN);
  teller = err_code;
  //  APP_ERROR_CHECK(err_code);                                                                                                                                                                                                              
  return;

It now shows that err_code != 0. I removed APP_ERROR_CHECK and hoped that the app would keep running and it did.

When receiving strings via BLE they are interpreted as commands, and one of these commands sends the value of teller back over BLE. The value of err_code == 8.

This means NRFX_ERROR_FORBIDDEN, but this is NOT one of the returns of nrf_drv_gpiote_in_init!

What could this mean here?

 Thanks again, Sietse

PS. I use arm-none-eabi-gdb so I can debug, but for now I use the above trick.

[Edvin]

Sietse said:

This means NRFX_ERROR_FORBIDDEN, but this is NOT one of the returns of nrf_drv_gpiote_in_init!

 I agree. Are you sure that 8 is returned from nrf_drv_gpiote_in_init()? Or do you use this teller somewhere else as well?

BR,

Edvin

[Sietse]

I declare it and put it in the reponse string:

int32_t teller = 0;
   ...
sprintf(response, "teller: %lx\n\r", teller);
   ...
teller = err_code;  

Thats all, no other mentioning of teller.

Using SDK_17.0.2 and arm-non-eabi-gcc 9.2.1 20191025 on linux/debian.

[Edvin]

Ok,

Can you please try to step inside nrf_drv_gpiote_in_init() and see what function call that returns 8? Use your debugger to test this and step inside the application.

Best regards,

Edvin

[Edvin]

Do you have access to a DK? Does the same issue occur if you run the application on a DK? If so, is there any way for me to reproduce this on a DK?