nrfx_gpiote_irq_handler() stucks when using TWIM

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

Susheel Nuguru — Wed, 27 Apr 2022 07:43:42 GMT

something seems to have changed, hard to see what changed while comparing code side by side.

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

pioupus — Tue, 26 Apr 2022 12:43:40 GMT

Exactly, this is problem. I did this in my application because PIN_CRASH should wake up the CPU when sleeping. The fun fact is, that the problem only appeared after updating from sdk16 to sdk17. With SDK16 everything worked fine.

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

Susheel Nuguru — Tue, 26 Apr 2022 12:35:30 GMT

I think the problem is that you are configuring the pins using gpio API as sense input and again using the GPIOTE to configure the sense parameter. I do not see a need to do the both.

Comment the sense configuration from either one.

After commenting the below two lines in gpio_init, i do not see this behavior anymore.

	//nrf_gpio_cfg_sense_input(PIN_IN, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_SENSE_LOW);
	//nrf_gpio_cfg_sense_input(PIN_CRASH, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_SENSE_LOW);

This piece of code has nothing to do with FreeRTOS as I see it.

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

Susheel Nuguru — Tue, 26 Apr 2022 10:43:21 GMT

I managed to reproduce this today, seems like it is not stuck but seems like there is a big delay sometimes when you press button 2. Not sure what it is but i need to investigate. Will be back to you when i have more info.

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

pioupus — Mon, 25 Apr 2022 11:04:39 GMT

Ok, I managed it to write a small example project for PCA10040 which (sometimes) reproduces the error: Press button 1 and the led toggles. If you press button 2 it often stucks in

//nrfx_gpiote.c
    if (status & (uint32_t)NRF_GPIOTE_INT_PORT_MASK) {
        port_event_handle(input); //stucks in the underlying loop within port_event_handle
    }

and the led won't toggle anymore.

The link is: https://github.com/pioupus/nrfx_gpiote_irq_handler_stucks_when_using_TWIM.git

It doesnt crash always. I think, if it is not possible to produce a crash, you have to restart the debugger and powercycle.

regards

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

Susheel Nuguru — Wed, 20 Apr 2022 10:25:38 GMT

Sure, if you can setup an example project, I can try debugging it at my end as well. Good luck with your investigation.

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

pioupus — Wed, 20 Apr 2022 09:44:26 GMT

Hi,

You are perfectly right that it is an ugly solution. The problem was that this was quick check if that is the endless loop which is responsible for blocking the system. GCC did not complain so I didnt see that there is a naming conflict. As I found out the system works if i break the loop after 100 passes and the loop's break condition is the reason why the system blocks.

I later found out that this happens if a pin is configured as SENSE but the GPIOTE module is not introduced to that pin. This way I guess GPIOTE assumes this pin is PIN_NOT_USED and the corresponding latch bit is not reset. I will investigate more about this. Hopfully I will have the time to setup an example project for the PCA10040. I think there might be trap for developers using the GPIOTE driver this way.

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

Susheel Nuguru — Wed, 20 Apr 2022 09:32:21 GMT

Hi,

The code is a bit confusing

static void port_event_handle(uint32_t *latch) {
    int i = 0; 
    do {
        i++;
        for (uint32_t i = 0; i < NRFX_GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS; i++) {

There seems to be two definitions of "i" and I am not sure why you need the "int i = 0;" definition in your code.
I have not seen this before, and it does not make sense that the for loop keep on advancing even though you clearly mentioned GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS to 4. Can you reproduce this on nRF52832 DK? Can you give me a minimalistic project to reproduce this?

[quote user=""]I can break the loop as shown above but this is not a beautiful solution. [/quote]

No, that solution looks very ugly. Can you remove the another definition of "i" and make sure that there are no other definitions of GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS anywhere in your code?

RE: nrfx_gpiote_irq_handler() stucks when using TWIM

pioupus — Tue, 19 Apr 2022 11:43:49 GMT

I observed something which helps to understand the problem:

The scl signal is via external hardware indirectly connected with a pin which is SENSE-configured but not setup to be used via GPIOTE. As I understand the situation: The GPIOTE interrupt is fired since the SENSE-configured pin is activated but as it is not known to the GPIOTE driver this pin is ignored and the driver stays in the loop without clearing the interruptstatus of the SENSE pin.