nrfx_gpiote_in_init and logging within its event handler

[Christopher Hunt]

Hi there. When nrfx_gpiote_in_init's event handler is called, is it being called as an interrupt? I note that if I use NRF_LOG_INFO within the body of the event handler, then my device will reboot on occasion. What I think I must do is to enqueue an event for processing outside of being an interrupt, but I've not yet confirmed that I should need to, or how. Any pointers here are appreciated. Thanks.

[Christopher Hunt]

Actually, it seems to reboot no matter whether I log or not. I'm using the BLE template project and so I'm now beginning to wonder if the reset is a feature of BLE not being connected. So far, if I connect the device I've not seen it reset.

[Karl Ylvisaker]

Hello Christopher,

When nrfx_gpiote_in_init's event handler is called, is it being called as an interrupt?

Yes, this is correct. You assign the interrupts priority during initialization of the peripheral.

I note that if I use NRF_LOG_INFO within the body of the event handler, then my device will reboot on occasion.

Are you seeing any error messages printed to your logger output when the resets occurs?
Could you also verify that you have defined DEBUG in your preprocessor definitions, like shown in the included image?

With DEBUG defined you should see a full length error message printed to your logger output if an error code != NRF_SUCCESS is passed to an APP_ERROR_CHECK.

The default behavior of the peripheral ble_template example in the SDK is to advertise for 180 seconds ( as defined at the top of the main.c file - ADV_DURATION ) before entering sleep mode. Could this be what you are interpreting as a sudden reset / shutdown ?

Best regards,
Karl

[Christopher Hunt]

Thanks Karl.

Yes, I’ve got debug enabled. It could well be the sleep mode that I’m encountering. I shall check further.

If I need to perform logic in the main context, how can I trigger that from the interrupt context?

FYI my code is derived from the BLE template example. Thanks.

[Karl Ylvisaker]

Christopher Hunt said:

Thanks Karl.

It is no problem at all, Christopher.

Christopher Hunt said:

Yes, I’ve got debug enabled. It could well be the sleep mode that I’m encountering. I shall check further.

Are you using deferred logging?
If you are, then you could place a breakpoint in the on_adv_evt handlers IDLE event, to see if this is the event sending the device to sleep.

Christopher Hunt said:

If I need to perform logic in the main context, how can I trigger that from the interrupt context?

Is there a particular reason why would like it to be performed in the main context?
The easiest way to do this would be to set a variable during the interrupt, and have a conditional section as part of the main function.
However, you could also just change the priority level of the particular peripherals interrupt, and process the interrupt directly in the event handler.

Christopher Hunt said:

FYI my code is derived from the BLE template example. Thanks.

Thank you for clarifying.

Best regards,
Karl

[Christopher Hunt]

I’ll give the breakpoint a go. Thanks.

Re the main vs interrupt context, is it not possible for the main context to be interrupted? If the main context was halfway through writing into memory, couldn’t an interrupt routine cause havoc when reading that same memory? Or perhaps I’m making some incorrect assumptions here...

The template example calls upon the power manager to loop, so I don’t see how I could poll for state to change...