[SOLVED] Error 118 : OS_ERR_INTERNAL

Hello all,

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

#if OS_SCHEDULER_ACTIVATED_BY_EXCEPTION


  OS_Global.Counters.Cnt.Region = 1u;


#elif OS_DEBUG


  if (OS_Global.Counters.Cnt.Region == 0u) {


    OS_Error(OS_ERR_INTERNAL);


  }

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

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 Martin,

Our licence for embOS is [1.34.04.07] RX CCRX but I confirm that I use IAR.
We have adapted embOs to work with IAR because E2 Studio was not going to work for us.

Best regards,
Audrey

Martin,

I perfectly understand. I will talk to my boss about that point.
I will come back to you later on.

Best regards,
Audrey

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

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 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 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 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

Here is a screenshot of the problem :

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