Fatal error having called nrfx_gpiote_in_init

[Christopher Hunt]

I'm new to the nrf5 GPIO functionality and having a little difficulty getting started. Upon having called `nrfx_gpiote_in_init`, my app reports a fatal error and the device resets. 'hoping that the following code sheds some light on this:

```

/**@brief Handle GPIO input sensing events

*/

static void on_gpio_in_evt(nrfx_gpiote_pin_t pin, nrf_gpiote_polarity_t action)

{

  NRF_LOG_INFO("Pin changed!");

}

/**@brief Set up our actual sensors

*/

static void gpio_init()

{

  ret_code_t err_code;

  nrfx_gpiote_pin_t pir_pin1 = NRF_GPIO_PIN_MAP(1, 1);

  nrfx_gpiote_in_config_t config = NRFX_GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);

  if (!nrfx_gpiote_is_init())

  {

    err_code = nrfx_gpiote_init();

    APP_ERROR_CHECK(err_code);

  }

  err_code = nrfx_gpiote_in_init(pir_pin1, &config, on_gpio_in_evt);

  APP_ERROR_CHECK(err_code);

  nrfx_gpiote_in_event_enable(pir_pin1, true);

}

```

My `sdk_config.h` enables GPIOTE (I don't think I've changed the config from the BLE peripheral template).

Here's my console output:

```

<info> app_timer: RTC: initialized.
<error> app: Fatal error
<warning> app: System reset

```

Related: I've interpreted the doc to read that it is ok to perform app functionality in the input event handler i.e. we are out of the world of interrupts. Not that it makes any difference here though, the failure occurs as a consequence of `APP_ERROR_CHECK` following the `nrfx_gpiote_in_init` call.

Thanks for any pointers.

[Karl Ylvisaker]

Hello,

Not that it makes any difference here though, the failure occurs as a consequence of `APP_ERROR_CHECK` following the `nrfx_gpiote_in_init` call.

Could you make sure that DEBUG is defined in your preprocessor defines? It should look like the included image:


Please make sure this is the case, and run the program again - you should then see a complete error message printed to the log, with which we may begin the debugging.

Best regards,
Karl

[Christopher Hunt]

Thank you Karl. This yields the following very interesting snippet:

<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at ../../../main.c:698

There's obviously now some heap that I've not set up? Again, I'm using the BLE peripheral template.

[Karl Ylvisaker]

Christopher Hunt said:

Thank you Karl.

No problem at all, Christopher!

Christopher Hunt said:

This yields the following very interesting snippet:

Yes, this is much easier to work with.
NRF_ERROR_NO_MEM is often returned by a function when it has insufficient allocated memory to be executed.
Which function is being called at line 698 of your main.c?
When we know the exact function generating the error code, we can look it up in the API Reference, to see how we should proceed with the error.

Best regards,
Karl

[Christopher Hunt]

L698 is the APP_ERROR_CHECK in the following:

err_code = nrfx_gpiote_in_init(pir_pin1, &config, on_gpio_in_evt);

APP_ERROR_CHECK(err_code);

 

So, I'd say it is in the nrfx_gpiote_in_init function.

I'm checking memory parameters now, but so far it looks ok. There's almost 256k of RAM, so perhaps some allocator?

[Karl Ylvisaker]

Christopher Hunt said:

So, I'd say it is in the nrfx_gpiote_in_init function.

Yes, this is correct. So, taking a look at the nrfx_gpiote_in_init function API Refernce we see that:

NRFX_ERROR_NO_MEM

No GPIOTE channel is available.

What is your (NRFX_)GPIOTE_NUM_OF_LOW_POWER_EVENTS defined as?
Try to increase it, to see if this resolves your error.

Best regards,
Karl

[Christopher Hunt]

It turns out that declaring "high accuracy" for the config is required:

nrfx_gpiote_in_config_t config = NRFX_GPIOTE_CONFIG_IN_SENSE_TOGGLE(true);

If I pass false (as I was) then NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS needs to be >= GPIOTE_CH_NUM. GPIOTE_CH_NUM is set to 8 by default.

There's no doc I found explaining the relationship of GPIOTE_CH_NUM. I thought that low accuracy equated to low power, but perhaps there's a different meaning altogether?

[Christopher Hunt]

Actually, I misread the code. While it certainly works for high accuracy, low accuracy appears to require some more configuration? NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS does not have to be greater than GPIOTE_CH_NUM. Still a bit confused - I do want the port events for lower power...

[Karl Ylvisaker]

Christopher Hunt said:

It turns out that declaring "high accuracy" for the config is required:

The difference between high- and low-accuracy ( PORT events ) can be read about in the GPIOTE documentation.

You will indeed have to specify how many low-power events ( PORT events ) your application will use, when using PORT events.
You may use up to 8 low power events, by setting it in the configuration. This will however allocate GPIOTE channels, so you may then have less high-accuracy events in use at the same time. In your case, setting NUM_LOW_POWER to 1 should remove the NO_MEM error you saw previously.

Christopher Hunt said:

I thought that low accuracy equated to low power, but perhaps there's a different meaning altogether?

Yes, you are correct here - low accuracy is PORT events, which are low power.

Best regards,
Karl

[Christopher Hunt]

OK, turns out that the template has settings both for legacy and contemporary GPIOTE i.e. GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS (which was set to 4) and NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS (which was set to 1). I've now removed the legacy settings and specified a value of 5 for NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS (the number of buttons on the DK + 1 pin I want).

All is good in the world.

Thanks for all of the pointers!

[Karl Ylvisaker]

Christopher Hunt said:

OK, turns out that the template has settings both for legacy and contemporary GPIOTE i.e. GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS (which was set to 4) and NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS (which was set to 1). I've now removed the legacy settings and specified a value of 5 for NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS (the number of buttons on the DK + 1 pin I want).

Great, I am glad to hear that you were able to resolve the issue.

Christopher Hunt said:

All is good in the world.

I am happy to hear you say that, Christopher!

Christopher Hunt said:

Thanks for all of the pointers!

It is truly no problem at all, I am happy to help! :) 

Please do not hesitate to open a new ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl