GPIO/GPIOTE interrupts not triggered at every event

RE: GPIO/GPIOTE interrupts not triggered at every event

Einar Thorsrud — Thu, 17 Mar 2022 11:30:03 GMT

The GPIO peripheral always runs on a 16 MHz clock, and so this clock is what is relevant for detecting changes etc. The CPU (app core) runs at 128 or 64 MHz as you noted, so while the interrupts are generated by a 16 MHz peripheral, all code executed (including in the interrupt routines) run with the normal CPU clock frequency. Then the CPU may be sleeping and waking up takes a bit of time (depending on state), and the ISR is entered and do some processing, as you would expect for any similar device.

RE: GPIO/GPIOTE interrupts not triggered at every event

Thiago — Thu, 17 Mar 2022 02:38:47 GMT

Thank you. That solved the pin problem. But if I may, I still have a question that is related to the initial topic of this post.

Q - If we are doing operations that are unrelated to the peripherals, these operations are controlled by the main clock (128 / 64 MHz in the case of the nRF5340), but what clock controls the process of entering and leaving the GPIOTE interrupt routine? Is it the main clock or the 16 MHz peripheral clock? Also, if we are executing operations (summation, multiplication) inside the GPIOTE interrupt routine, what clock is used to process these operations?

RE: GPIO/GPIOTE interrupts not triggered at every event

Einar Thorsrud — Wed, 16 Mar 2022 11:42:11 GMT

Ah, I did not notice this before, but the nrfx sample does not handle GPIO pins from port 1. When yo use a pin from port 1, the pin number should be 32 + the P1 pin. So for instance, P1.15 is pin 47. This is normally handled more elegantly when using the Zephyr GPIO API, but when using nrfx directly that is not the case. You can for instance to it like this, though:

Specify the pin in an overlay file like you have before:

&button0 {
	gpios = <&gpio1 15 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
};

Then you can check the port and add 32 as needed as shown in this diff from the nrfx sample in nRF Connect SDK 1.9.1:

devzone.nordicsemi.com/.../6180.main.c.diff

(I have kept the output pin as is here, but you can change that as well).

RE: GPIO/GPIOTE interrupts not triggered at every event

Thiago — Wed, 16 Mar 2022 08:38:20 GMT

I tried to change the INPUT_PIN via the .overlay file using other pins from the P0 port and the interrupt was triggered, but I couldn't trigger interrupts using any pin from the P1 port. Is there something I need to change in the project to be able to use pins from port P1 as input?

RE: GPIO/GPIOTE interrupts not triggered at every event

Thiago — Wed, 16 Mar 2022 00:06:43 GMT

Hi.

[quote userid="7377" url="~/f/nordic-q-a/85841/gpio-gpiote-interrupts-not-triggered-at-every-event/358295#358295"]With high frequencies you will not have time for many instructions in the ISR before you run out of time. So without having seen your code I expect that is the problem. What is the end goal here? Doing things in SW this rapidly does not generally seem like a good idea (and if you are able to do wat you want here, you would not be able to do much else if anything as the CPU is more or less always busy handling the GPIOTE interrupts.[/quote]

So, what is seen in the pictures above is expected and can not be improved by adjusting the configurations?

This is how I changed the pin:

&button0 {
    gpios = <&gpio1 15 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
};

I noticed that if I use the preassigned pin (p0.23) the interrupt is triggered, but if I change the pin as above and connect the signal to p1.15 the GPIOTE ISR is not called.

RE: GPIO/GPIOTE interrupts not triggered at every event

Einar Thorsrud — Tue, 15 Mar 2022 19:20:21 GMT

Hi,

With high frequencies you will not have time for many instructions in the ISR before you run out of time. So without having seen your code I expect that is the problem. What is the end goal here? Doing things in SW this rapidly does not generally seem like a good idea (and if you are able to do wat you want here, you would not be able to do much else if anything as the CPU is more or less always busy handling the GPIOTE interrupts.

Regarding using a different pin you can for instance make an overlay where you map the sw0 alias to something else, and that should work out of the box. How have you selected another pin?

RE: GPIO/GPIOTE interrupts not triggered at every event

Thiago — Tue, 15 Mar 2022 07:36:40 GMT

Also, my application requires that the pin p1.15 be the one configured to trigger the GPIOTE IN interrupts. At the NRFX example when I modified the input pin at the .overlay file I noticed that no interrupt was triggered at all. I tried modifying some values at the IRQ_CONNECT() function without any success. What should I change to generate interrupts from events at the p1.15 pin?