GPIOTE freezes on pin value change

RE: GPIOTE freezes on pin value change

Dan — Sun, 16 Jul 2017 03:00:39 GMT

I'm not really getting results I want but that is what I was thinking so at least my thought process is correct. This seems more like a hidden issue somewhere and I think the initial question has been answered. Thanks Jørgen for taking the time to go though this.

RE: GPIOTE freezes on pin value change

Jørgen Holmefjord — Thu, 13 Jul 2017 13:52:05 GMT

I would expect your code to wait on while(nrf_drv_gpiote_in_is_set(26) == 1) until an interrupt is received. Then you clear the interrupt in the interrupt callback and read sensor data and data_handler is called once. I would then expect the sensor to have cleared the interrupt and you will be left waiting at while(nrf_drv_gpiote_in_is_set(26) == 1) until the next interrupt is received. If the interrupt is not cleared, you will continue reading sensors and calling data_handler until the interrupt pin is cleared.

RE: GPIOTE freezes on pin value change

Dan — Thu, 13 Jul 2017 02:31:54 GMT

I'm using eclipse and am having trouble getting debug working. While I try to get that running could I ask what is your definition of continuing is for this code? My definition is that I expect to see data_handler() being called repeatedly and seeing my TWI values in uart. The interrupt period is longer than the print call and there is plenty of time to see it written to the uart between interrupts so I don't expect that to be the issue. Am I wrong somewhere?

RE: GPIOTE freezes on pin value change

Jørgen Holmefjord — Wed, 12 Jul 2017 12:54:52 GMT

I tried your code again, and it still seems to continue after getting interrupt (commented out the TWI transfer functions, as I don't have that accelerometer available). I suppose you have removed the if(0) statement to get the code further down in main() to run? Have you tried debugging, to see if any functions return error codes, or that the application is continuing as expected?

RE: GPIOTE freezes on pin value change

Dan — Tue, 11 Jul 2017 01:00:24 GMT

The MMA8652FC technical data sheet says that reading the F_STATUS register should clear the FIFO interrupt flag that I send and I do that. There is another function call in main to read out the accelerometer data. I based that code off the temp_sensor example. Here is a link to main.c

RE: GPIOTE freezes on pin value change

Jørgen Holmefjord — Mon, 10 Jul 2017 13:15:20 GMT

I tested your code and it seems to contine as expected for me. Are you doing anything else in your code? Is the interrupt pin from the accelerometer cleared again after being set? You should not have to do anything with the registers when using the driver, it should handle this for you.

RE: GPIOTE freezes on pin value change

endnode — Sat, 08 Jul 2017 09:51:55 GMT

Hi Dan, fully understand the constrains, just note that clones of Saleae Logic can be yours for 5USD including shipping...;)

RE: GPIOTE freezes on pin value change

Dan — Sat, 08 Jul 2017 04:21:43 GMT

This appears to have worked as I can now trigger the statement in pin_event_handler. As a follow-up question, is there something that stops the function form going on after hitting the interrupt? It seems to just stop doing anything in the outermost while loop in function main? I've seen other question that reference NRF_GPIOTE->EVENT_PORT = 0 NRF_GPIOTE->EVENTS_IN[0] but I don't quite understand how these work or if they are related at all to make the code continue.

I assume this should be fairly common action to code where a sensor sends an interrupt and I want to take take note of that and call a read on the data. I haven't seen any examples but is there anything I can reference for this?

RE: GPIOTE freezes on pin value change

Dan — Sat, 08 Jul 2017 04:07:08 GMT

That's good to know that some things like uart can be the source. The delay_ms function was my attempt just to do a quick debug on the value coming in and I wanted to verify that I was getting an interrupt from the accelerometer since if I don't have uart I won't see anything. That I can remove. And unfortunately, since I don't own the hardware like an oscilloscope, uart is the easiest option for me to look at the pin output.

If you have anything like this to point out about my response to Jorgen that would be appreciated. More knowledge or examples is always helpful.

RE: GPIOTE freezes on pin value change

Jørgen Holmefjord — Fri, 07 Jul 2017 07:47:31 GMT

Hi,

You need to set the int_enable parameter in nrf_drv_gpiote_in_event_enable() to true to enable the interrupt. If you look in the implementation of the function, you will see that interrupt and handler is only set if this parameter is true.

Best regards,

Jørgen

RE: GPIOTE freezes on pin value change

endnode — Fri, 07 Jul 2017 07:14:15 GMT

Two hints:

nrf_delay_ms function is blocking MCU with NOP instructions, doesn't really work well if you wait for some asynchronous thing like interrupt. I use it for some quick debugging as well but in your case implementing correct timer (e.g. through RTC based app_timer library) would be much better.
Similar with your interrupt handler: doing any time-consuming action or computation might lead to different kind of failures or unexpected behavior. So your UART logging might look short but in some extreme cases you can be running out of time. As you experience some troubles exactly here I would either remove it completely or put some faster debugging indication like simple GPIO LOW/HIGH control of single output PIN and observing it with oscilloscope or better logical analyzer....