Bug in app_gpiote.c and an improvement for ISR in nrfx_gpiote.c

RE: Bug in app_gpiote.c and an improvement for ISR in nrfx_gpiote.c

Edvin — Mon, 28 Nov 2022 11:54:54 GMT

I will just put it in a waiting state, so it will be opened whenever someone write to it any time in the future 🙂

BR,
Edvin

RE: Bug in app_gpiote.c and an improvement for ISR in nrfx_gpiote.c

anikchen — Thu, 24 Nov 2022 11:01:46 GMT

Thanks Edvin, I really appreciate your recognition, and would keep this thread open for one week to someone who maybe want to comment on it.

Best regards,

Anik

RE: Bug in app_gpiote.c and an improvement for ISR in nrfx_gpiote.c

Edvin — Thu, 24 Nov 2022 07:47:43 GMT

[quote user="anikchen"]

You are also right that "That is a limitation of the module.". However, it should be as reliable as possible to minimize the risk. Indeed the driver level in nrfx_gpiote.c uses some hardware features to do that, such as LATCH in PORT EVENT, with which the interrupt could be held until it's processed. But it's a pity that the app level in app_gpiote.c doesn't utilize this feature.

[/quote]

I totally agree!

[quote user="anikchen"]And this really happened in the situation while 2 interrupts are triggered at the same time.[/quote]

Yes. It is a good point.

[quote user="anikchen"]E> Thanks a lot for your support. I noticed and understood. Event the team has no schedule, it's also a good thing if this thread could help someone here who maybe encounter the same problem.[/quote]

That is also a very good point! Thank you for sharing! This is all valuable feedback!

Best regards,

Edvin

RE: Bug in app_gpiote.c and an improvement for ISR in nrfx_gpiote.c

anikchen — Thu, 24 Nov 2022 02:59:21 GMT

Thanks for your comments!

A> You are right. I am using low accuracy as I call the API <app_gpiote_user_register()> in which the hi_accuracy is set to default false (PORT EVENT): const nrf_drv_gpiote_in_config_t config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);

And even I manually set it to true (IN EVENT), it also works with the same problem because both IN EVENT and PORT EVENT use the shared callback <gpiote_handler()> where the bug locates in app_gpiote.c. Of course, I already tested and checked this.

B> You are also right that "That is a limitation of the module.". However, it should be as reliable as possible to minimize the risk. Indeed the driver level in nrfx_gpiote.c uses some hardware features to do that, such as LATCH in PORT EVENT, with which the interrupt could be held until it's processed. But it's a pity that the app level in app_gpiote.c doesn't utilize this feature.

C> The logic of the app level is: it receives events through <gpiote_handler()> from the driver level. Then it makes the decision on whether the event is rising triggering or falling triggering just according to the last pin state. If the last pin state is High, it would deliver a HiToLo event to user application callback registered by <app_gpiote_user_register()>, and vice versa. As we can see, the last pin state decided everything. If something unexpectedly changed it's value, the user application would get an unexpected event accordingly. And this really happened in the situation while 2 interrupts are triggered at the same time.

D> It's a good option to use the API in nrfx_gpiote.c skipping app_gpiote.c just like what "the implementation that is used in SDK\examples\peripheral\pin_change_int" do. But sometimes, for most developers, the official library is the first choice as it's much convenient to get started and able to boost the development.

E> Thanks a lot for your support. I noticed and understood. Event the team has no schedule, it's also a good thing if this thread could help someone here who maybe encounter the same problem.

Thanks Edvin and Best regards,

Anik

RE: Bug in app_gpiote.c and an improvement for ISR in nrfx_gpiote.c

Edvin — Wed, 23 Nov 2022 13:25:45 GMT

Hello,

I am aware that if you are using low accuracy, which means high_accuracy = 0 in:

/** @brief Input pin configuration. */
typedef struct
{
    nrf_gpiote_polarity_t sense;               /**< Transition that triggers the interrupt. */
    nrf_gpio_pin_pull_t   pull;                /**< Pulling mode. */
    bool                  is_watcher      : 1; /**< True when the input pin is tracking an output pin. */
    bool                  hi_accuracy     : 1; /**< True when high accuracy (IN_EVENT) is used. */
    bool                  skip_gpio_setup : 1; /**< Do not change GPIO configuration */
} nrfx_gpiote_in_config_t;

You will get an interrupt on every pin change, but since this is a low accuracy / low power approach, the event itself will not hold the state of the pin that triggered the task, but this will be read out by the state of the pin that triggered the task, and add it to the user event. That is a limitation of the module.

That being said, I couldn't say that I recognized the gpiote_handler, and I see that out of the box, this module is not used in any of the examples. Not saying it doesn't work, but I don't know the inns and outs of it. If I need "raw" gpio handlers, I usually use the implementation that is used in SDK\examples\peripheral\pin_change_int, where you can choose between hi_accuracy enabled or disabled.

I will forward your input to the developer team, but seeing as the nRF5 SDK is in maintenance mode, I am not sure when/if they will look into it.

Best regards,

Edvin