GPIOTE Interrupt nRF51822 freezing

RE: GPIOTE Interrupt nRF51822 freezing

Ole Bauck — Fri, 13 Jan 2017 13:04:53 GMT

I am running out of ideas. It works with .hi_accuracy = true which indicates that there is something wrong with the PORT event functionality, but then setting the polarity to toggle should work. What is the PIN_CNF[9] register when the interrupt stops? Is it still PIN_CNF[9] = 0x0003000C?

RE: GPIOTE Interrupt nRF51822 freezing

Guillaume Levant — Wed, 11 Jan 2017 12:11:46 GMT

I tried the following configuration :

 nrf_drv_gpiote_in_config_t p9_config =
	    {
	        .sense = NRF_GPIOTE_POLARITY_TOGGLE,
	        .pull = NRF_GPIO_PIN_PULLUP ,
	        .is_watcher = false,
	        .hi_accuracy = false
	    };

Then when the interrupt occurs, I check with nrf_gpio_pin_read(9) that the pin level is 0. But I have the same problem with this configuration : The interrupt is not processed, and the following interrupt are not either process unless I set p0.09 high.

RE: GPIOTE Interrupt nRF51822 freezing

Ole Bauck — Tue, 10 Jan 2017 13:50:10 GMT

I totally understand that it is not acceptable to have that high current consumption, this was just to narrow down the possible causes for the problem.

I think I know what is the cause of the problem now. It is probably in how the sense and port event mechanism works. As described in the Reference Manual chapter 14 - GPIO, each pin has a separate DETECT signal that is set high when the pin sense the correct level. All DETECT signals are combined into a common DETECT signal that is used to trigger the PORT event. When using .hi_accuracy = false this mechanism is used. The problem is that the DETECT signal is not cleared unless no pins are sensing the correct level. This is why it works after you set the P0.09 pin manually to high and not before.

I thought the gpiote driver had a way of avoiding this, but after checking more thoroughly this is only the case if the sense is set to NRF_GPIOTE_POLARITY_TOGGLE. Then the sense bit will be flipped in the interrupt, thereby clearing the DETECT signal for that pin.

One way to fix your problem is to configure the sense to NRF_GPIOTE_POLARITY_TOGGLE, but then you need to check in some way if the pin went from high to low or low to high. You can do this by checking the pin input value with nrf_gpio_pin_read(uint32_t pin_number).

I will talk to the developers if we can improve the gpiote driver such that this is not a problem in the future.

RE: GPIOTE Interrupt nRF51822 freezing

Guillaume Levant — Mon, 09 Jan 2017 14:43:43 GMT

I tried it and the problem disappears with this configuration. But unfornutately the power consumption of the device is way too high in this case (about 1mA during advertising, 1.25mA connected). According to this result, do you know a solution which permit me to keep .hi_accuracy = false ?

RE: GPIOTE Interrupt nRF51822 freezing

Ole Bauck — Mon, 09 Jan 2017 13:53:24 GMT

Can you try to set the accuracy to high on P0.09:

.hi_accuracy = true

And see if you still have the same problem?

RE: GPIOTE Interrupt nRF51822 freezing

Guillaume Levant — Thu, 22 Dec 2016 13:26:10 GMT

I set it the priority of gpiote level to APP_IRQ_PRIORITY_HIGH, and the BLE is still working (I see BLE_GAP_EVT_CONNECTED and BLE_GAP_EVT_DISCONNECTED, and also read and write requests). But I noticed something interesting : The interrupt on P0.09 is active when the pin is low, and then the problem described above happens. But on a BLE disconnection event, I send an I2C command to a IC that sets the P0.09 high, and then the other interrupts are working even if the disconnection comes after the interrupt, and they works until P0.09 goes low again. So it seems to be link to the fact that P0.09 is low, but I can't understand why. In you opinion what piece of my code is missing to permit you to help me further ?

RE: GPIOTE Interrupt nRF51822 freezing

Ole Bauck — Wed, 21 Dec 2016 12:45:36 GMT

So something is happening when you get interrupt for P0.09 that is blocking all other interrupts at that level and below. If you increase the interrupt priority to APP_PRIORITY_HIGH you should see that the the BLE event also does not show. Could you verify this?

I am not sure how I can help you further without having a look at your code.

RE: GPIOTE Interrupt nRF51822 freezing

Guillaume Levant — Thu, 15 Dec 2016 14:30:46 GMT

Yes I noticed that the power_manage() function doesn't return in this case, but it does for BLE event, so I think you are right. But the point is that when the interrupt should occurs, an RTT command should be sent in the gpiote handler, and I have never seen this interrupt for P0.09 interrupt, but I do for P0.03 and P0.06.

RE: GPIOTE Interrupt nRF51822 freezing

Ole Bauck — Thu, 15 Dec 2016 13:56:25 GMT

The power_manage() function does basically the same thing as __WFE(), it puts the chip to sleep waiting for events that will wake it up. If it was stuck here nothing would work.

My guess is that you are stuck in an interrupt at a low level. Then all interrupts at the same level or lower, including main, will not be able to execute. Interrupts at a higher level will work as usual, this will include the SoftDevice code. Check if your main code is called at all (add something after the power_manage function to indicate that this function returns).

RE: GPIOTE Interrupt nRF51822 freezing

Guillaume Levant — Wed, 14 Dec 2016 16:04:07 GMT

Ole, I made a few test and I noticed that during this bug, only the gpiote interrupt and the timer are not working. The BLE works perfectly fine and I can send commands that shows that the MCU is not completely frozen when I use the gpiote interrupt, not the timer. I wonder if the code is stuck in a power_manage() function. Is it possible that it could disable the gpiote interrupt ?

RE: GPIOTE Interrupt nRF51822 freezing

Guillaume Levant — Thu, 08 Dec 2016 15:09:40 GMT

I set UART0_ENABLED to 0 in nrf_drv_config.h, and I excluded from build every library related to UART. Here are the different value for PIN_CNF :

PIN_CNF[3] = 0x0003000C
PIN_CNF[6] = 0x0002000C
PIN_CNF[9] = 0x0003000C

So to me it fits with the configurations I sent during the initialization (Input, S0S1, pull-up, wake-up on low level).

I tried to replace the interrupt by a timer in repeat mode with a period of 30 seconds, the same thing happens. So I think this problem is not related to the GPIOs or GPIOTE. I'll look into if I encountered an error somewhere...

RE: GPIOTE Interrupt nRF51822 freezing

Ole Bauck — Thu, 08 Dec 2016 14:03:41 GMT

You are sure this pin is not used anywhere else in the code such that the gpio config is altered? On the DK pin P0.09 is used for uart TX, in case you are basing your code on a PCA10028 example and have not commented out uart code. To check that the gpio config is correct you can go into debug mode, stop the code when the problem happens (this will also tell you where the code is stuck), then you can check system peripherals -> gpio and the PIN_CNF[9] register. It should be the same as PIN_CNF[6] and PIN_CNF[3], except for maybe the SENSE bit.

Does the whole device freeze or is it only the gpiote interrupt that are not working? Can you check if you encountered an error condition? Check this.