This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to determine the context of a callback

Hi,


I am encountering some difficulties to undertand the context in which my sdk modules call back are called.
I am using the uart part of ble uart nus example, and thus the app_uart module. I was wondering if uart_event_handle was called from one interrupt, or is stacked in the app_scheduler event queue at some point ? In a more general way, how do I know if my app is using interruptions or the app events scheduler ?

All the best,

#include <nrf_uart.h>
#include <nrf_uarte.h>
#include <app_uart.h>

void uart_event_handle(app_uart_evt_t * p_event)
{
      uint32_t       err_code;
      
    NRF_LOG_INFO("uart_event_handle \r\n");

    switch (p_event->evt_type)
    {
        case APP_UART_DATA_READY:
            // do something with received data
            break;

        case APP_UART_COMMUNICATION_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_communication);
            break;

        case APP_UART_FIFO_ERROR:
            APP_ERROR_HANDLER(p_event->data.error_code);
            break;

        default:
            break;
    }
}
Parents
  • Hi,

    The app uart library does not include support for the app scheduler so the callback is reported in the UART interrupt context. Generally, I think the easiest way to find this out by debugging the application in an IDE. Below is a screenshot I took from  Segger Embedded studio when I have hit a breakpoint in the UART callback. As you can see from the call stack, the UART IRQ handler is called first followed by some event handling before notifying the app directly through the registered callback. The ISR number shown in the xPSR register on the right would have been zero if the callback was invoked in main context through the app scheduler, etc.

    It's also possible to use the current_int_priority_get() function in your code if you want to check if you are in an interrupt context or not programmatically.

Reply
  • Hi,

    The app uart library does not include support for the app scheduler so the callback is reported in the UART interrupt context. Generally, I think the easiest way to find this out by debugging the application in an IDE. Below is a screenshot I took from  Segger Embedded studio when I have hit a breakpoint in the UART callback. As you can see from the call stack, the UART IRQ handler is called first followed by some event handling before notifying the app directly through the registered callback. The ISR number shown in the xPSR register on the right would have been zero if the callback was invoked in main context through the app scheduler, etc.

    It's also possible to use the current_int_priority_get() function in your code if you want to check if you are in an interrupt context or not programmatically.

Children
Related