NRF_GPIO->IN reading wrong value/pin

RE: NRF_GPIO->IN reading wrong value/pin

Vidar Berg — Thu, 25 Jul 2019 13:15:11 GMT

Thanks for the update, and for pointing out that you may need to adjust the number of events in sdk_config.

RE: NRF_GPIO->IN reading wrong value/pin

Heiner — Thu, 25 Jul 2019 13:12:55 GMT

Hi Vidar,

I tried it again with your recommendation

[quote userid="4240" url="~/f/nordic-q-a/49864/nrf_gpio--in-reading-wrong-value-pin/199757"]set the .high_accuracy flag to 'false'[/quote]

and that worked. Thank you for the explanation.

It might be useful for other people reading this thread to know, that you also have to modify GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS in sdk_config.h to the number of low power events, or else it won't work correctly.

Tank you again for your help.

Sincerely,

Heiner

RE: NRF_GPIO->IN reading wrong value/pin

Vidar Berg — Mon, 22 Jul 2019 11:45:59 GMT

Hi Heiner,

[quote user="Heiner"]could you please refer to an example or point me to an explanation on how this is achieved?[/quote]

The driver will use PORT events if you set the .high_accuracy flag to 'false' when you configure the input. I.e., it should be sufficient to just change the accuracy flag in your original code in order to use PORT event.

[quote user="Heiner"]I can not really understand, why a comparison with the NRF_GPIO->IN register would return TRUE, even if the wrong bit is toggled.[/quote]

IN is not latched and should always return the current pin state. To check if the DETECT signal has been raised for a particular pin you need to check the LATCH registers. Also, note that LATCH must be manually cleared to detect the next input transition. Recommend to use the GPIOTE/button handler library instead of creating your own code.

Best regards,

Vidar

RE: NRF_GPIO->IN reading wrong value/pin

Heiner — Fri, 19 Jul 2019 12:51:22 GMT

Hi Vidar,

[quote userid="4240" url="~/f/nordic-q-a/49864/nrf_gpio--in-reading-wrong-value-pin/199262"]configuring the driver to use PORT events[/quote]

could you please refer to an example or point me to an explanation on how this is achieved?

In the GPOITE documentation it is only stated: "Turning off high accuracy [...] enables the low-power feature" and "The following code example shows how to use a pin to detect toggling using high accuracy".

There's no example on how to use the low accuracy function of the driver, neither it's explained how to configure the driver to use a PORT event instead, at least not in that section.

[quote userid="4240" url="~/f/nordic-q-a/49864/nrf_gpio--in-reading-wrong-value-pin/199262"]look up the addresses in the memory view[/quote]

That worked, thank you.

However I'm even more confused now, because the registers actually change as expected. I even changed my GPIOs to #30 and #31, to move them as far from the button GPIOs as possible, but the problem remains.

I can not really understand, why a comparison with the NRF_GPIO->IN register would return TRUE, even if the wrong bit is toggled.

From my understanding it should only return TRUE once, when for example Bit 31 is changing from 1 to 0 and I compare ~NRF_GPIO->IN & 1<<31.

~NRF_GPIO->IN & 1<<30 should not return true in this case, if Bit 30 is still 1.

Sincerely,

Heiner

RE: NRF_GPIO->IN reading wrong value/pin

Vidar Berg — Thu, 18 Jul 2019 12:05:09 GMT

Hi,

[quote user=""]Using the nrf GPIOTE driver works, but I wanted a solution that consumes less power, as this is for a low power application.[/quote]

The driver would become low power if you configured it to use the PORT event instead of the IN events. Excerpt from the driver documentation:

Input pins can be configured to be controlled in different modes:

So I would suggest that you to go revert back to the working configuration and make sure you configuring the driver to use PORT events. You may also consider using the Button handling library on top to handle debouncing if that's necessary for your design.

[quote user=""]However they would both have to be high, before one switch could toggle an interrupt. If one switch was low it wouldn't work for some reason.[/quote]

PORT events are triggered by the DETECT signal. This is explained in more detail in the GPIO chapter of the product specification (link).

[quote user=""]Looking at the LOG output (since NRF_GPIO->IN is restricted memory, that I cannot debug) it does seem like one pin is triggering both if clauses.[/quote]

This is a limitation imposed by Segger embedded Studio, but you can look up the addresses in the memory view as a work-around.

Best regards,

Vidar