The problem that keys occupy the process

RE: The problem that keys occupy the process

XiongYin — Wed, 18 Sep 2024 04:11:12 GMT

Hi Sigurd,

I think you may not receive the update of this ticket anymore since it's "Verified Answer".

So I created another ticket: Nordic DevZone (nordicsemi.com).

Thanks!

RE: The problem that keys occupy the process

XiongYin — Wed, 11 Sep 2024 10:38:03 GMT

Hi Sigurd,

Kenyon and I found that:

The PWM module "app_pwm" enabled "Port Event" in "nrfx_gpiote_init". (This is ok.)
Our sense button (P0.01) will trigger the "Port Event" and its ISR "port_event_handle". (This is ok.)
Then the "nrf_gpio_latches_read_and_clear" will clear the register "LATCH" which makes our key scanning routine can not get any change of bit P0.01 of register "IN". (This is something wrong we think.)

So our questions are:

Should "nrf_gpio_latches_read_and_clear" check the owner of each bit before clearing?
Does the clearing of the bit of "LATCH" indeed affect the register "IN" as we tested?

Thanks!

RE: The problem that keys occupy the process

Sigurd — Fri, 12 May 2023 11:16:44 GMT

[quote user="kenyon"]I got to the root of the problem. As you described, sense and port event conflict in gpiote. I configured the NRF_GPIO_PIN_SENSE_LOW trigger mode in the key to do the wake-up foot. Then in app_pwm there is the function of configuring gpiote. I did not redefine the trigger mode of the key to NRF_GPIO_PIN_SENSE_NONE when the key woke up. Therefore, the subsequent pwm work and keys occupy gpiote at the same time, resulting in the entire program working abnormal. Although I changed the key trigger mode to NRF_GPIO_PIN_SENSE_NONE after waking up, the program returned to normal[/quote]

Great!

[quote user="kenyon"]But I wonder if there is an easier way to deal with this gpiote occupancy conflict. Because I have no problem configuring gpiote function in key and pwm in SDK11 products.[/quote]

No, I'm not aware of any other ways. There have been several changes to the gpiote driver since SDK 11.

RE: The problem that keys occupy the process

kenyon — Fri, 12 May 2023 02:27:19 GMT

Hi Sigurd.
I didn't do sense and gpiote with the same pin. key(pin31) just use for sense.app pwm use no pin.
I got to the root of the problem. As you described, sense and port event conflict in gpiote. I configured the NRF_GPIO_PIN_SENSE_LOW trigger mode in the key to do the wake-up foot. Then in app_pwm there is the function of configuring gpiote. I did not redefine the trigger mode of the key to NRF_GPIO_PIN_SENSE_NONE when the key woke up. Therefore, the subsequent pwm work and keys occupy gpiote at the same time, resulting in the entire program working abnormal. Although I changed the key trigger mode to NRF_GPIO_PIN_SENSE_NONE after waking up, the program returned to normal. But I wonder if there is an easier way to deal with this gpiote occupancy conflict. Because I have no problem configuring gpiote function in key and pwm in SDK11 products.

Thanks for your reply!

RE: The problem that keys occupy the process

Sigurd — Wed, 10 May 2023 14:51:49 GMT

Hi,

Could be similar to the issue as in this post here, nrfx_gpiote_irq_handler() stucks when using TWIM , I believe the issue there was doing both nrf_gpio_cfg_sense_input() and nrf_drv_gpiote_in_init() on the same pin. i.e. using gpio API to set sense input, and again using the GPIOTE API to configure the sense parameter. So if you try using the PIN for multiple things, and with different APIs, this could happen it seems.

RE: The problem that keys occupy the process

kenyon — Wed, 10 May 2023 02:11:33 GMT

Hi Sigurd.
Have not. I just found the crux of the conflict, but didn't know how to solve it. Because I looked at the code and found that pin31 was not reused anywhere else, and pin31 did not use interrupts for keystrokes. But once I've initialized both the keystroke and app_pwm, as soon as I press the keystroke, it goes to gpiote's handler and causes both Bluetooth and ble processes to fail, but when I release the keystroke, it works again. So I don't know how to solve this problem?

RE: The problem that keys occupy the process

Sigurd — Tue, 09 May 2023 15:35:28 GMT

Hi,

[quote user="kenyon"]I found that the gpiote used by app_pwm conflicts with the key(pin31), which is really strange. All I have to do is mask app_pwm_init and the key will work.[/quote]

So the issue is solved?

RE: The problem that keys occupy the process

kenyon — Tue, 09 May 2023 13:19:22 GMT

I found that the gpiote used by app_pwm conflicts with the key(pin31), which is really strange. All I have to do is mask app_pwm_init and the key will work.