Can't configure 2 gpio pins with opposite pull state

[Serhio]

Hi,

I try configure 2 gpio pins with opposite pull state, one NRF_GPIO_PIN_PULLUP, other NRF_GPIO_PIN_PULLDOWN:

nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);
in_config.pull = NRF_GPIO_PIN_PULLUP; 
err_code = nrf_drv_gpiote_in_init(PIN_BUTTON, &in_config, button_handler);
APP_ERROR_CHECK(err_code);
nrf_drv_gpiote_in_event_enable(PIN_BUTTON, true);

nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);
in_config.pull = NRF_GPIO_PIN_PULLDOWN;
err_code = nrf_drv_gpiote_in_init(PIN_IMPULSE, &in_config, impulse_handler);
APP_ERROR_CHECK(err_code);
nrf_drv_gpiote_in_event_enable(PIN_IMPULSE, true);

But, callback don`t called.

If I configure with same pull state, then callback is called.

Why is this occurs? How to set up pins with diffrent pull state?

Thank you!

[Karl Ylvisaker]

Hello,

That sounds strange.
Could you detail your issue some more: 

But, callback don`t called.

How are you testing this, and how does it behave differently than expected? I just want to make sure that I have understood you correctly.
Could you also share the callback code, which is / is not being called?

Why is this occurs? How to set up pins with diffrent pull state?

Which pins on the nRF52832 are you using, and what are they connected to?
Are you working with a nRF52 DK, or a custom board?

Looking forward to resolving this issue together!

Best regards,
Karl 

[Serhio]

In same time, I can use this code:

    nrf_gpio_cfg_input(PIN_BUTTON, NRF_GPIO_PIN_PULLUP);

    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);
    in_config.pull = NRF_GPIO_PIN_PULLDOWN;
    err_code = nrf_drv_gpiote_in_init(PIN_IMPULSE, &in_config, impulse_handler);
    APP_ERROR_CHECK(err_code);
    nrf_drv_gpiote_in_event_enable(PIN_IMPULSE, true);

And then use nrf_gpio_pin_read(PIN_BUTTON)

But that doesn't suit me..

[Karl Ylvisaker]

Hello,

Sorry for my late reply.

Thank you for clarifying.

Serhio said:

PIN_IMPULSE - 9 (I use CONFIG_NFCT_PINS_AS_GPIOS define)

Could you also tell me what this pin is connected to? 

Serhio said:

callback called(log is displayed).

Are you using deferred logging, by the way?
If you are, it is not a definite way to see the flow of your program using logs, since they will be written only when the CPU have no other task.
Instead, I would suggest using a LED or sending a message to verify that you have entered into one of the callbacks.

Serhio said:

And then use nrf_gpio_pin_read(PIN_BUTTON)

But that doesn't suit me..

No, I would not recommend this, this is far from ideal.
I see now that you are configuring both your inputs as low-accuracy. 
Could you tell me what your GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS is defined as in your sdk_config? I suspect it might be set to 1, in which case you should try increasing it to 2. Please try this, and let me know if this resolves your issue.

Furthermore, I would alert you to the difference between PORT event and IN_EVENT, since you are currently using low-accuracy configuration which means that both pins will generate the same PORT event, as opposed to high-accuracy configuration which has a dedicated IN_EVENT per pin.

Looking forward to resolving this issue together,

Best regards,
Karl 

[Serhio]

Karl Ylvisaker said:

Could you also tell me what this pin is connected to?

For testing purposes, I`m connecting it with a plus. Thus, it is like a button. In release, a phototransistor will be connected there.

Karl Ylvisaker said:

Instead, I would suggest using a LED or sending a message to verify that you have entered into one of the callbacks.

I like your holistic approach) I've tried using nrf_gpio_pin_toggle(PIN_LED)

Karl Ylvisaker said:

Could you tell me what your GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS is defined as in your sdk_config?

I am aware of this define. But thank you for not forgetting about that. It`s equal 4

Karl Ylvisaker said:

Furthermore, I would alert you to the difference between PORT event and IN_EVENT, since you are currently using low-accuracy configuration which means that both pins will generate the same PORT event, as opposed to high-accuracy configuration which has a dedicated IN_EVENT per pin.

Now for the good news. As you suggested. I setup pin with hi-accuracy is true and now it works. 

But does this cause increased power consumption? The device under development is powered by a CR2032 battery and the issue of power consumption is very important.

Thus, low-accuracy don't work for pins with opposite pull state?

Thanks for your answers.

[Karl Ylvisaker]

Hello again,

I am terribly sorry for the late reply.

Serhio said:

For testing purposes, I`m connecting it with a plus. Thus, it is like a button. In release, a phototransistor will be connected there.

Thank you for clarifying. So, what you are saying is that both GPIOs in questions are connected with a button, sensing a change in the level, correct?

Serhio said:

I like your holistic approach) I've tried using nrf_gpio_pin_toggle(PIN_LED)

Great! What was the results of these trails, were you able to confirm the callback behavior using the LED?

Serhio said:

I am aware of this define. But thank you for not forgetting about that. It`s equal 4

Thank you for verifying this. It is indeed quickly overlooked, and so I just had to make sure this was not the case right now. 

Serhio said:

Now for the good news. As you suggested. I setup pin with hi-accuracy is true and now it works.

That is good news indeed!

Serhio said:

But does this cause increased power consumption? The device under development is powered by a CR2032 battery and the issue of power consumption is very important.

Yes, high-accuracy GPIOTE IN_EVENTS does increase power consumption compared to the low-accuracy PORT event. The GPIOTE IN will enable the HFCLK source to run when a edge is triggered, then start sampling using the HFCLK.
There is also some Erratas present for the GPIOTE on the nRF52832. Which SoC version and variant are you working with?

Serhio said:

Thus, low-accuracy don't work for pins with opposite pull state?

I have never heard of this behavior before, and neither has my colleagues that I have conferred with. I would not expect this either.

Could you share with me a stripped down project in which you are seeing this behavior?
I will then attempt to replicate the behavior on my end, so that I may better debug it.

Looking forward to getting to the bottom of this!

Best regards,
Karl

[Karl Ylvisaker]

Hello again,

Could you also try to use GPIOTE_CONFIG_IN_SENSE_TOGGLE() instead of _LOTOHI for your buttons?

I believe that if a port event is triggered on a low to high transition on a pin, a new port event can’t be triggered before that pin has gone low again or the pin is configured to sense low (which will trigger a new event on high to low transition). See the answers to this and this post.

The results of this test will also tell us more about what might be causing the unexpected behavior you are seeing.

Best regards,
Karl

[Serhio]

Hello! I`m very sorry for my late reply. I was on vacation.

Karl Ylvisaker said:

So, what you are saying is that both GPIOs in questions are connected with a button, sensing a change in the level, correct?

Yes

Karl Ylvisaker said:

What was the results of these trails, were you able to confirm the callback behavior using the LED?

Yes, the LED state did not change

Karl Ylvisaker said:

Which SoC version and variant are you working with?

NRF52832_xxAA_REV2, SoftDevice S132 v5.0.0

Karl Ylvisaker said:

Could you also try to use GPIOTE_CONFIG_IN_SENSE_TOGGLE() instead of _LOTOHI for your buttons?

I tried. And it works! Code:

{    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);
    in_config.pull = NRF_GPIO_PIN_PULLUP;
    err_code = nrf_drv_gpiote_in_init(PIN_BUTTON, &in_config, button_handler);
    APP_ERROR_CHECK(err_code);
    nrf_drv_gpiote_in_event_enable(PIN_BUTTON, true);}/**/


    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);
    in_config.pull = NRF_GPIO_PIN_PULLDOWN;
    err_code = nrf_drv_gpiote_in_init(PIN_IMPULSE, &in_config, impulse_handler);
    APP_ERROR_CHECK(err_code);
    nrf_drv_gpiote_in_event_enable(PIN_IMPULSE, true);

I use GPIOTE_CONFIG_IN_SENSE_TOGGLE only for one button and now... works both buttons..

Karl Ylvisaker said:

Could you share with me a stripped down project in which you are seeing this behavior?
I will then attempt to replicate the behavior on my end, so that I may better debug it.

For reproduce issue, just use code from my first message. And connect one button to "+" and other to "-"

[Karl Ylvisaker]

Hello,

Serhio said:

I`m very sorry for my late reply. I was on vacation.

No worries at all, I hope you had a great vacation!

Serhio said:

NRF52832_xxAA_REV2, SoftDevice S132 v5.0.0

Thank you for letting me know.

Serhio said:

I tried. And it works!

Serhio said:

I use GPIOTE_CONFIG_IN_SENSE_TOGGLE only for one button and now... works both buttons..

I am glad to hear that! Then I would think the problem was caused due to the PORT event already being generated when the second one came in.
Is the application now working as you had intended?
If you are using TOGGLE on both, you can keep track of which direction it has transitioned since the last event.

Best regards,
Karl 

[Serhio]

Karl Ylvisaker said:

Is the application now working as you had intended?

Yes, Karl, I'm satisfied how the application works now. Thank you for your help.