[SOLVED] Error 118 : OS_ERR_INTERNAL

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

  • [SOLVED] Error 118 : OS_ERR_INTERNAL

    Hello all,

    I use embOS v4.02a, in OS_DEBUG mode, and my application stops line 9 :

    C Source Code

    1. #if OS_SCHEDULER_ACTIVATED_BY_EXCEPTION
    2. OS_Global.Counters.Cnt.Region = 1u;
    3. #elif OS_DEBUG
    4. if (OS_Global.Counters.Cnt.Region == 0u) {
    5. OS_Error(OS_ERR_INTERNAL);
    6. }
    Display All

    In documentation it is written that this error appears when : OS_ChangeTask() called without Region Counter set (or other internal error).

    In which cases the region counter could be equal to zero, since before OS_ChangeTask() is called, the counter is either incremented, either set to 1.
    What could be the "other internal error" ?

    Thanks in advance,
    Audrey
  • Hello Audrey,

    Thanks for your inquiry. While we're not aware of any issues with embOS V4.02a for RX and CCRX, we of course would like to assist you in finding the root cause for the observed problem.

    AudreyD wrote:

    In which cases the region counter could be equal to zero, since before OS_ChangeTask() is called, the counter is either incremented, either set to 1.
    What could be the "other internal error" ?
    With embOS V4.02a, OS_ERR_INTERNAL is issued exclusively when the region counter is equal to zero during OS_ChangeTask().
    Also, as you have noticed correctly, the region counter should never be zero at that stage of program execution, for it is incremented by embOS immeditely before calling OS_ChangeTask(). If it is zero nonetheless, that could e.g. indicate that it was overwritten after being incremented, e.g. by a stack overflow or similar erroneous operations. You could therefore set a data watch point on the counter to check if and when it actually is overwritten. However, since the region counter gets modified quite frequently by embOS, this could be a tedious task to perform if the error doesn't occur early on, but after some time only.

    Hence, even though your support and update agreement has expired in 2014 already, I would like to ask if it's possible for you to provide us with a reproduction project so we can take a closer look at the problem on your behalf?
    Also, could you kindly tell me which exact device you're using with which exact embOS library mode? Which compiler version was used to build the project?

    Best regards,
    Martin
  • Martin,

    Thanks a lot for your response ! This guides us through our investigation.

    This error appears randomly, sometimes after 2 hours of run, sometimes after 7 days. However, it appears every time.
    I'm not sure that providing the sources will help you because the software is quite big, and it requires sensors to work.

    The device we use is R5F563NE in OS_LIBMODE_DP.
    The compiler we use is IAR C/C++ Compiler for RX v1.09, in IAR Embedded Workbench IDE - RX 3.10.6.

    Any idea is welcome !

    Best regards,
    Audrey
  • Hi Audrey,

    Thanks for providing further information.

    AudreyD wrote:

    The device we use is R5F563NE in OS_LIBMODE_DP.
    The compiler we use is IAR C/C++ Compiler for RX v1.09, in IAR Embedded Workbench IDE - RX 3.10.6.
    Could you please confirm that it's actually IAR? I'm afraid I can't find a license for your company for embOS for RX and IAR in our database, but for embOS for RX and CCRX only. Or, are you currently using the CCRX port with IAR?

    Best regards,
    Martin
  • Hi Audrey,

    Please understand we can't give support on a customized embOS. However, we do offer an official embOS port for RX and IAR compiler as well.
    Please refer to our website for further information. If you're interested in obtaining that port, please let me know and I will ask my sales colleagues to provide you with an official quote.

    Best regards,
    Martin
  • Hi Martin,

    I come back to you since the order has been processed.

    We have used the "Trace" tool from IAR and we get the following behavior :

    1. One task was running and it is now waiting for a message in its mailbox

    2. embOS calls "OS_Deactivated()" function to switch to another task

    3. When the "OS_Switch()" of "OS_Deactivated()" is performed, the instruction after, we do not return to "OS_Deactivated() to execute "OS_RegionCnt = r"
    We return in "_OS_SwitchAfterISR_RX" assembler function, at the instruction "bsr.a _OS_DecRegionCnt"

    4. _OS_SwitchAfterISR_RX function continues until the end

    5. When the "RTE" instruction is called, the next instruction which is executed is the first instruction ("pushm R14-R15") of "_OS_SwitchAfterISR_RX" function (again !)

    6. As the region counter was decremented in the last "_OS_SwitchAfterISR_RX" call, when we perform the switch of the current "_OS_SwitchAfterISR_RX", the region counter is equal to 0 and we get the error

    We have noticed that the reason why "RTE" makes the program go back to "_OS_SwitchAfterISR_RX", is that U bit (for USTACK use) is set to 0.
    We think that there is maybe, not a bug, but a weakness in embOS.
    If we have well understand how it works, when we go to "_OS_SwitchAfterISR_RX" function, the U bit should always be equal to 1, right ?
    All ISR have been performed and it is time to execute task. Do you agree ?

    However we assume that there is probably a weakness in our application too.
    We can add an instruction (U = 1) in "_OS_SwitchAfterISR_RX" as a patch to our bug. What do you think about that ?
    Is there a risk of breaking something else by doing this?

    However I would like to find out why the U bit is not set correctly.
    Do you have any idea of tests we could do, register we should look, any idea is welcome :)

    Best regards,
    Audrey
  • Martin,

    Here are some news.

    We have performed other tests and we were actually wrong concerning the U bit to 0.
    It is well set to 1 but however there is a bug in embOS.

    This bug appears when two interrupts (nested or with different priorities) run at same time (one interrupts the other) and both have to call "_OS_SwitchFromInt".

    So that the destacking of ISTACK and then USTACK make the function "_OS_SwitchAfterISR_RX" to be called twice following.

    The first one decrements the region counter and when the second one performs its switch, the region counter is equal to 0 and we get the error.

    We will add a patch to resolve the problem.
    This patch will prohibit coping ISTACK in USTACK if "_OS_SwitchFromInt" has already been added in ISTACK.

    If you need more information, we can call to talk about this.

    Best regards,
    Audrey
  • Dear Audrey,

    in my understanding you are using the embOS RX CCRX sources with the IAR EWRX compiler and implement the necessary changes by yourself instead of licensing embOS RX IAR, right?
    Most likely there is no bug in embOS but in your implementation.
    What you are currently using is no embOS provided and tested by SEGGER!
    embOS RX IAR is used in a lot of products without any issues.

    > This bug appears when two interrupts (nested or with different priorities) run at same time (one interrupts the other) and both have > to call "_OS_SwitchFromInt".
    This will not happen since only the first interrupt calls OS_SwitchFromInt().

    Please understand we can't give support for your customized embOS and your license agreement does not cover the usage of the IAR compiler. The simplest solution is to license embOS RX IAR. If you want to give it a try you could download the embOS RX IAR trial version from segger.com.

    Best regards,
    Til
  • Hello Til,

    > in my understanding you are using the embOS RX CCRX sources with the IAR EWRX compiler and implement the necessary changes by yourself instead of licensing embOS RX IAR, right?
    Yes, you are right.

    > This will not happen since only the first interrupt calls OS_SwitchFromInt()
    Yes, you're right again.

    > Please understand we can't give support for your customized embOS and your license agreement does not cover the usage of the IAR compiler.
    I perfectly understand. The order of lastest embOS version has been delivered yesterday. I am going to implement it on our IAR project and then, if the problem still persists, I will contact you again.

    > Most likely there is no bug in embOS but in your implementation.
    Yes, it is actually the most likely, but maybe your experience with embOS will be useful to understand our problem.

    Best regards,
    Audrey
  • Hi all,

    embOS v5.02a is now implemented in our software.
    We are trying to use embOSView but we get some troubles.
    With our software project, it works only when we reset the debug session, while it works very well using our board, but having loaded the project of the RX63 evaluation board (only two tasks running, very small program).

    The main difference is that a part of our software is stored in external memory.
    Is there any additional configuration, or something to do in order to use embOSView with a part of code stored in external memory ?

    Thanks in advance,
    Audrey
  • Hi Audrey,

    Generally, no additional configuration is required even when part of the code is stored in external memory.

    Can you tell in more detail which problems do occur?
    Are you using J-Link as communications interface between target and host, or are you e.g. using UART instead?
    Does the embOSView log ("View" -> "Log" from the menu) show any error conditions?

    Best regards,
    Martin
  • Hi Martin,

    Yes, you're right.
    embOSView is working fine even if we put all code in external memory (except stacks).

    However, we have a problem by using SystemView.
    SystemView works correctly when all the code is in internal memory but, when we put all code in external memory (except USTACK and ISTACK which are stored in internal RAM), we get this error message :

    Failed to start recording
    RTT Control Block not found

    It seems that if "RTT Control Block" is in external memory, it cannot be found...
  • Hi Audrey,

    Okay, so it's not embOSView but SystemView that fails to start.
    This, however, is somewhat expected: Auto-detection of the RTT control block will typically search through internal memory only, since J-Link cannot know the exact layout of your external memory. Hence, if the control block is located in external memory, its adress needs to be explicitly specified in the connection dialog, e.g.:



    If you don't know the adress of the RTT control block with your application, you may simply search for "_SEGGER_RTT" in a map file.

    Does this solve the observed problems? Please let me know if I can be of any further help.

    Best regards,
    Martin
  • Hi Martin,

    Yes, this has solved the observed problem. We are now able to use SystemView in "live mode" and it works correctly.

    But now, to understand our bug, we would like to use SystemView in "Post mortem mode".
    We have put the associated flag to 1, set the buffer to 8192 and call the start function in the init function of our application (before the os_start function).

    The problem we get by doing this is that embOS crash in OS_Error() with the code OS_ERR_ILLEGAL_IN_ISR.

    Do we have forgotten something ?

    Best regards,
    Audrey
  • Hi Audrey,

    I've quickly tried to reproduce the observed issue, but to no avail.

    Does your application utilize ISP or USP when the SystemView init function is called? This is for the reason that, generally speaking, OS_ERR_ILLEGAL_IN_ISR will only be issued when an embOS API function that mustn't be called from an ISR was called from an ISR. However, main() will initially utilize the interrupt stack as well, which may have resulted in a false-positive detection if any embOS API function was called before embOS could switch to USP.

    Therefore, I'd like to ask if you could share your initialization routine with us? Also, could you please send me a screenshot of the call stack when the application enters OS_Error()? Please feel free to use our ticket system (or our official support email address) if you don't want to share that information on a public forum.

    Best regards,
    Martin
  • Hi Martin,

    We have modified the link file to store the USTACK in internal memory, so that the application can start using USTACK, and not ISTACK as it was before.
    Now, the "post mortelm mode" works perfectly, but we still have a problem...

    Since we have a lot of tasks running, the syncho made by SystemView takes a lot of time.
    We have configured the OS_tick to trigger every 1 ms.

    When the SystemView synchro is done during an OS_tick interrupt, if another OS_tick interrupt appears (it can be because it is a nested interrupt) while we are still doing the synchro, we observe in SystemView log that an ISR_exit is missing (only one is done instead of two).

    As a consequence, the application crashs in OS_ERR_ILLEGAL_IN_ISR (again).
    Do you have any idea ?

    Best regards,
    Audrey
  • Martin,

    We have observe the same problem on another run but this time, the application didn't crashed.
    I attached the associated screenshot.

    It appears that, this time, when the OS_tick interrupt is finiched, no other change task is required. We return to the initial one and then, there is a weird thing : the scheduler restarts, the second Exit_ISR is performed, so that we don't crash.

    On the previous screenshot, the scheduler wanted to change task, that's the difference...

    Don't you think there could be a problem with the region counter ?

    Best regards,
    Audrey
    Images
    • 37e31bec-b2f8-456e-b375-6750abec231a_2.jpg

      190.35 kB, 1,189×812, viewed 134 times