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]

Hello, Karl!

Callback code, for example:

void button_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
   NRF_LOG_INFO("button_handler %d %d", pin, action);
   nrf_gpio_pin_toggle(PIN_LED);
}

void impulse_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
   NRF_LOG_INFO("impulse_handler %d %d", pin, action);
}

If I configure 1(any) gpio pin then corresponding callback called(log is displayed). 

PIN_BUTTON - 25

PIN_IMPULSE - 9 (I use CONFIG_NFCT_PINS_AS_GPIOS define)

I use custom board:

 

 

[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