GPIO Interrupt Latency

RE: GPIO Interrupt Latency

Hung Bui — Mon, 16 Sep 2024 10:24:52 GMT

Hi Ricardo,
Thanks for letting me know. I'm glad that you figured that out. Sorry that I didn't spot that. Thought you were using 1.8V VDD.

RE: GPIO Interrupt Latency

Ricardo Ferreira — Mon, 16 Sep 2024 10:14:24 GMT

Hello Hung Bui ,

So the problem was not the problem...

It was an hardware issue, and I incorrectly assumed it was a Zephyr issue.

The GPIO generating the interrupt was 1.8V and the board (VDD) was 3.0V.

As GPIO requires 0.7xVDD to measure logic high, it sometimes took a few ms while to detect it.

I changed the supply to generate a 3V interrupt and now interrupt handling is instantaneous (~20us) as expected.

Thanks for the help anyway.

RE: GPIO Interrupt Latency

Ricardo Ferreira — Mon, 09 Sep 2024 15:12:12 GMT

Hello Hung Bui ,

Sorry for not replying.

I've been busy and not been able to get back at this issue.

As soon as I have something I'll get back to you.

Thank you for your patience.

Best regards,

Ricardo

RE: GPIO Interrupt Latency

Hung Bui — Wed, 04 Sep 2024 08:01:48 GMT

Hi Ricardo,
You mentioned

[quote user="Ricardo Ferreira"]The sample at samples/boards/nrf/nrfx has zero latency, but as soon as I add a thread to manage communcations and a worker to handle interrupt, interrupt response goes almost to 3ms (although sometimes it instantaneous).[/quote]

Is there anyway you can provide that sample ?

I think the approach here is to find a way to reproduce the issue and then try strip down your driver/application until you don't see the latency then we would know what cause that.

If you want to use the Zephyr GPIO driver, you can start with the zephyr\sample\basic\button sample. As far as I know, the Zephyr GPIO driver will use gpio_nrfx.c at low level anyway. And in that file you will find IRQ_CONNECT() used.

RE: GPIO Interrupt Latency

Ricardo Ferreira — Tue, 03 Sep 2024 15:02:49 GMT

Hello Hung Bui,

Yes, I had understood that, so how can I use standard GPIO methods without CONFIG_GPIO = y?
Do I have to change all my drivers to use gpios without CONFIG_GPIO?

Is there anyway IRQ_CONNECT can coexist with CONFIG_GPIO?

Best regards,

RE: GPIO Interrupt Latency

Hung Bui — Tue, 03 Sep 2024 14:02:52 GMT

Hi Ricardo,
Thanks for the info. Now I can build and see the same IRQ_CONNECT complain.
From what I can see it's because the battery library you have, it uses Zephyr's GPIO driver (in Kconfig in drivers\battery it select GPIO)
You will see the same error if you change CONFIG_GPIO = y in the default nrfx sample.

The problem is that Zephyr's GPIO driver also defines a IRQ handler for GPIO causing a conflict with the IRQ_CONNECT define in nrfx sample.

RE: GPIO Interrupt Latency

Ricardo Ferreira — Tue, 03 Sep 2024 11:29:47 GMT

The files I sent you include a custom board in the boards folder with name with nrf52840dk.dtsi and respective pinctrl files, which have all pin configurations. Please make a build configuration with that board.

RE: GPIO Interrupt Latency

Hung Bui — Tue, 03 Sep 2024 11:26:17 GMT

Hi Ricardo,
I tried to build your project here with NCS v2.6.0 board nRF52840dk_nRF52840 but I ran into another error:
It complains about the battery device tree or something.

Have you made sure you included everything ?

Please try to test with as simple as possible code to reproduce the issue.

RE: GPIO Interrupt Latency

Ricardo Ferreira — Tue, 03 Sep 2024 10:48:21 GMT

Hello Hung,

I sent you via PM.

RE: GPIO Interrupt Latency

Hung Bui — Tue, 03 Sep 2024 07:49:14 GMT

Hi Ricardo,
Pleas provide your code. It seems that you have connected two irq handlers to the same IRQ.

RE: GPIO Interrupt Latency

Ricardo Ferreira — Mon, 02 Sep 2024 14:29:20 GMT

Hello Hung Bui,

I only got back from vacation myself today.

I picked-up a new nrfx samples and started adding my custom code for my drivers.

When I add code that used GPIO, the compilation starts failing with this:

gen_isr_tables.py: error: multiple registrations at table_index 6 for irq 6 (0x6)
Existing handler 0x9307, new handler 0x9307
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

How can I safely change to IRQ_CONNECT?

Should my other drivers use another method other than GPIO based functions?

Best regards,

Ricardo Ferreira

RE: GPIO Interrupt Latency

Hung Bui — Mon, 26 Aug 2024 09:14:44 GMT

Hi Ricardo,
I'm taking over the ticket from Håkon because he is on vacation.

Could you please send us the code where you modified the samples/boards/nrf/nrfx that reproduce the issue ?

I assume you toggle the GPIO when you are in the button_handler ? 2.5ms seems like a lot. Interrupt handler should be able to interrupt works and threads.

RE: GPIO Interrupt Latency

Elfving — Mon, 19 Aug 2024 14:24:23 GMT

Hi,

[quote user="Elfving"]

Strange that this is happening even when the threads are non-preemptive, though I agree that the other threads are probably the culprit here.

[/quote]

I take this back; the threads running shouldn't make much of a difference. And 2.5ms is way too long.

Thanks for giving me a way to reproduce it. I'll try this myself later this week.

Regards,

Elfving

RE: GPIO Interrupt Latency

Ricardo Ferreira — Fri, 16 Aug 2024 13:01:59 GMT

Hello Elfving ,

Here is a print of the threads' states at the moment the worker is called to handle interrupt off-load communications.

The only thread preemption is sysworkq.

Best regards,

Ricardo

RE: GPIO Interrupt Latency

Elfving — Fri, 16 Aug 2024 12:07:10 GMT

[quote user="Ricardo Ferreira"]

When I implement the exact code on my application, the same issue I reported is happening.

Probably related to other threads running in the system, but it's strange because all other threads are non-preemptive. I haven't activated any BLE threads - that will probably increase the latency by a lot.

[/quote]

Strange that this is happening even when the threads are non-preemptive, though I agree that the other threads are probably the culprit here.

Could you have a look at the other threads that are running? You can eg. use the Thread Viewer in the VSC extension. Have look here for a rundown on how to use it.

Regards,

Elfving

RE: GPIO Interrupt Latency

Ricardo Ferreira — Fri, 16 Aug 2024 10:09:54 GMT

Hello,

An update.

Still not able to reduce and stabilize interrupt response latency.

I have tried IRQ_CONNECT and IRQ_DIRECT_CONNECT, with and without IRQ_ZERO_LATENCY flag.

The sample at samples/boards/nrf/nrfx has zero latency, but as soon as I add a thread to manage communcations and a worker to handle interrupt, interrupt response goes almost to 3ms (although sometimes it instantaneous).

Any help would be appreciated.

Thanks in advance,

Ricardo

RE: GPIO Interrupt Latency

Ricardo Ferreira — Wed, 14 Aug 2024 14:43:01 GMT

Hello,

I was finally able to pick-up this development again.

So I followed sample at samples/boards/nrf/nrfx which uses IRQ_CONNECT and PPI.

Running the sample directly in a nRF52840Dk, it seems to work perfectly - no delay between interrupt and action.

When I implement the exact code on my application, the same issue I reported is happening.

I tried changing priorities but no improvement.

I tried changing IRQ_CONNECT to IRQ_DIRECT_CONNECT, but this results in a fatal error.

RE: GPIO Interrupt Latency

Ricardo Ferreira — Thu, 08 Aug 2024 14:10:06 GMT

Hello Elfving ,

Regarding IRQ_DIRECT_CONNECT, I haven't figured out how to use it with GPIOTE but I'll have another look and documentation. Also, from what I read, it could cause a few issues with managed GPIO interrupts.

PPI looks intersting, I will try it.

I also tried applying NVIC_SetPriority(GPIOTE_IRQn, IRQ_PRIO_LOWEST), and it seems to improve latency but doesn't completely solve it.

Best regards,

RE: GPIO Interrupt Latency

Elfving — Thu, 08 Aug 2024 12:04:29 GMT

Hello,

Have you used IRQ_DIRECT_CONNECT?

For testing purposes I guess PPI would be the fastest. You can also try that.

Regards,

Elfving