GPIOTE problems

RE: GPIOTE problems

Frank — Wed, 07 Sep 2016 10:01:37 GMT

Hi, Stefan Sorry for my mistake, I can detect the interrupt actually, but the period is not 16ms as the graph above shows, it's about 1s. This is a HUGE deviation. Anyway, I can reach the lowest comsumption when use the sensor, but it cannot match well with nrf51822.

RE: GPIOTE problems

Stefan Birnir Sverrisson — Wed, 07 Sep 2016 07:15:11 GMT

For further explanation, check the discussion on this thread. I find it strange though that you do not detect any interrupt when using the GPIOTE PORT event. If you have softdevice enabled, you could miss an interrupt once in a while but not all the time, as BLE events are periodic but not constant.

RE: GPIOTE problems

Frank — Mon, 05 Sep 2016 09:22:34 GMT

Thank you. I've checked the interrupt priority, it is always set to high, but this question still occurs.From your answer, it seems no efficient way to solve this problem. I can only make the interrupt duration longer than maybe 500us, right?

RE: GPIOTE problems

Stefan Birnir Sverrisson — Fri, 02 Sep 2016 17:17:29 GMT

Make sure the gpiote interrupt priority is set to high, i.e. that APP_IRQ_PRIORITY_HIGH is set for GPIOTE in the nrf_drv_config.h file.

The current consumpion difference you see is normal. Current consumption when using high accuracy is ~1mA, while the low accuracy gpiote uses <1uA. When using low accuracy, the GPIOTE PORT event is used. The PORT event does not know which pin caused the interrupt, but needs to check the status of pins in the interrupt handler to conclude what pin caused the interrupt. If the CPU is blocked by a higher priority interrupt, e.g. BLE interrupt when the signal occurs, then the GPIOTE interrupt handler in the nrf_drv_gpiote does not detect any pin signal, and the application interrupt is not called. BLE interrupts can block the CPU up to 500us, and therefore potentially delay the GPIOTE interrupt by 500us. If you have another interrupt executing at high priority as well, that will also block execution of the GPIOTE handler.

You could check if the nrf_drv_gpiote driver actually gets the GPIOTE port interrupt by placing a breakpoint at the beginning of the GPIOTE_IRQHandler.