 |
|
|
MAEC TOOL NEWS:
MAECT-M3T-MR32R-020401D
Notes on Real-Time OS
M3T-MR32R
|
|---|
Please take note of the following problems in using real-time OS M3T-MR32R for the M32R family MCUs:
- On using the iwup_tsk, iset_flg, isig_sem, isnd_msg, irel_blf, and visnd_msg system calls
- On using the irel_blf system call
- Versions Concerned
M3T-MR32R V.3.00 Release 1 -- V.3.40 Release 1
-
Problem on Using the iwup_tsk, iset_flg, isig_sem, isnd_msg, irel_blf, and visnd_msg System Calls
- 2.1 Descriptions
- The descriptions of the problem are as follows:
- (1) Task A issues a system call B with a timeout period (see Table 1 below).
- (2) While M3T-MR32R is processing this system call that lets task A to enter the waiting state, an interrupt is generated.
- (3) To service the interrupt, the interrupt handler issues another system call C specific to B (also see Table 1 below), which immediately releases task A from the waiting state.
- (4) Then, task A enters the READY state or the RUN state.
- (5) However, task A remains in the timer queue as before. Therefore, the timer queue cannot properly be managed.
- (6) Consequently, the following symptoms may arise.
- The timeouts of other tasks do not occur at the specified time or cannot occur at all.
- Even though task A that issued a system call with a timeout remains in the timer queue (and in the waiting state), it joins the READY queue (from the RUN state in (4)) or rejoins the READY queue (from the READY state in (4)) to enter the READY state.
- M3T-MR32R cannot complete its timeout processing.
- 2.2 Conditions
- This problem occurs if the following four conditions are satisfied:
- (1) The value of data for holding a timeout value becomes negative immediately before system call B is issued. (See Notes 1.)
- (2) System calls B and C are issued in any of the pairs shown in Table 1.
- <Table 1. Pairs of System Calls B and C>
| System Call B with Timeout (See Notes 2.) | System Call C |
|---|
| tslp_tsk | iwup_tsk |
| twai_flg | iset_flg |
| twai_sem | isig_sem |
| trcv_msg | isnd_msg |
| tget_blf | irel_blf |
| vtrcv_mbx | visnd_mbx |
- (3) When system call B is issued, one or more tasks are waiting for their timeout periods.
- (4) The timeout of system call B is defined as the one that occurs after the last timeout of all the tasks in (3) above.
- Notes:
- In the following cases, the value of data for holding a timeout value becomes negative:
(1) Immediately before issuing system call B with a timeout period, a task issues a system call defined as permanent waiting and is already in the permanent waiting state. For example, twai_flg with a timeout value of TMO_FEVER or slp_tsk is issued, so that the task enters the permanent waiting state.
(2) When the first task is invoked after the system is launched, the value in the data area for holding a timeout value happens to be negative. Note that because the above data area need not be initialized at the system's launch, the value in this data area is undefined.
- If a negative timeout value is selected at issuing system call B (that is, the permanent waiting state selected), Condition 1 is not met. For example, if TMO_FEVR (its timeout value = -1) is selected at issuing tslp_tsk (system call B), or if slp_tsk is used in place of tslp_tsk with any timeout value, the problem will not occur.
- 2.3 Workaround
- Assign a 0 to the value of data for holding a timeout value of task A before issuing system call B with a timeout period.
[Example]
------------------------------------------------
extern INT _TCB_tmr[];
void task2(INT stacd)
{
:
_TCB_tmr[ID_task2-1]=0;
tslp_tsk(100);
:
}
------------------------------------------------
- 2.4 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
- Problem on Using the irel_blf System Call
- 3.1 Descriptions
- The descriptions of the problem are as follows:
- (1) Task A issues the tget_blf system call with a timeout period, which lets task A to enter the waiting state.
- (2) Then, another task issues such a system call with a timeout period as tslp_tsk and twai_flg.
- (3) While M3T-MR32R is processing the system call in (2) above, an interrupt is generated.
- (4) To service the interrupt, the interrupt handler issues the irel_blf system call, which immediately releases task A from the waiting state.
- (5) Then, task A enters the READY state or the RUN state.
- (6) However, task A remains in the timer queue as before. Therefore, the timer queue cannot properly be managed.
- (7) Consequently, the following symptoms may arise.
- The timeouts of other tasks do not occur at the specified time or cannot occur at all.
- Even though task A that issued a system call with a timeout remains in the timer queue (and in the waiting state), it joins the READY queue (from the RUN state in (5)) or rejoins the READY queue (from the READY state in (5)) to enter the READY state.
- M3T-MR32R cannot complete its timeout processing.
- 3.2 Workaround
- Modify the program in such a way that a combination of system calls rcv_msg and rel_blf and that of isnd_msg and rel_blf exist in task A to prevent the interrupt handler from issuing the irel_blf system call.
- [Example]
Task A issues the rel_blf system call, and the interrupt handler transmit a message that tells the beginning address of the memory area to be freed up.
------------------------------------------------
void task(void){
char * msg;
while(1){
rcv_msg((PT_MSG)&msg,ID_msg);
rel_blf(ID_mpf,(VP)msg);
}
}
void int_handler(void){
:
/* irel_blf(ID_mpf,gblf); */
isnd_msg(ID_msg,(PT_MSG)gblf);
:
}
------------------------------------------------
- 3.3 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
|
|
