[SOLVED] API OS_InInterrupt() doesn't work if called inside function called by OS SW timer

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] API OS_InInterrupt() doesn't work if called inside function called by OS SW timer

    We are using OS version: V5.18.0.3

    We have a function that uses mutex, and it is used inside tasks and in ISR function.
    In order to avoid OS error, mutex usage is under condition, checking if caller is in task execution or in ISR exection, using API OS_InInterrupt()
    See example code below

    C Source Code

    1. void doSomething(void)
    2. {
    3. bool isISR = FALSE;
    4. // check if it is called inside ISR
    5. isISR = (OS_InInterrupt()) ? TRUE : FALSE;
    6. // thread safe access if caller is NOT an ISR
    7. if ( isISR == FALSE )
    8. {
    9. OS_Use(&some_mutex);
    10. }
    11. // do something code
    12. // thread safe access if caller is NOT an ISR
    13. if ( isISR == FALSE )
    14. {
    15. OS_Unuse(&some_mutex);
    16. }
    17. }
    Display All
    This solution works fine and as expected from embos documentation for API OS_InInterrupt() in both scenarios

    BUT, instead, if the same function is used as callback for a timer SW (where caller is OS code that is called in OS sysTick ISR), API OS_InInterrupt() return WRONG value (it returns "NO isr"),
    so our code goes in OS_error function for invalid usage of OS API inside an ISR

    I didn't see any other way for our code to understand if caller is task code or SW timer, so i think this is an API bug

    Attached screenshot from debugging:
    (1) timer with callback and mutex create
    (2) debug inside function called by SW timer, where isISRtest from OS_InInterrupt() is showed with wrong value
    (3) after this, mutex function is called and code goes in OS_error

    The post was edited 2 times, last by pbizzarri ().

  • Hello,

    This is not an embOS bug, but it works as intended.

    OS_INT_InInterrupt() returns 1 only when called from an embOS interrupt routine.
    From any other context, like embOS software timer, it returns 0.

    With Cortex-M embOS software timers are executed within the PendSV() (not SysTick) interrupt, but that is just an implementation detail for embOS Cortex-M.
    From the embOS perspective, it is the software timer context, and you must not use any mutex API within an embOS software timer.

    You could use OS_TIMER_GetCurrent() to check whether a timer callback is currently being executed.

    Does that answer your question?
    You can also get support via our support email address and support ticket system: segger.com/doc/UM01001_embOS.html#Support

    Best regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi, thanks for quick reply

    Your explanation is very clear, and also help us in undertstanding better where OS timer SW are called ("Cortex-M embOS software timers are executed within the PendSV()")

    Your workaround seems works fine in my tests.

    I defined a macro like this:
    // check OS SW timer context
    #define OS_IS_SW_TIMER_CONTEXT() ((NULL != OS_TIMER_GetCurrent()) ? 1:0)

    and now our code tests both conditions using (OS_InInterrupt() || OS_IS_SW_TIMER_CONTEXT() )

    Let me suggest to add this macro or something similar also in EMBOS macros.

  • Hello,

    Thanks for your feedback. It's good to hear it's working for you.
    Yes, I would like to add such an API routine that returns the current context.
    Unfortunately, that would work for Cortex-M but not for all other CPUs.
    Anyway, I will add it to our wish list.

    Best regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.