 |
|
|
MESC TOOL NEWS:
MESCT-MR32R-000216D
Please take note of the following problem in using real-time OS MR32R for the M32R family of microcomputers:
-
Versions Concerned
MR32R V.1.00 Release 1 -- MR32R V.3.10 Release 1
-
Problem
When a system call issued in the interrupt handler causes a task switch to be generated, the switch operation may be delayed depending on when an interrupt is generated until:
- * the interrupt handler starts servicing; or
- * another system call for invoking the scheduler is issued.
- 2.1 Conditions for a task switch being generated
- A task switch will be generated if any of the following conditions is satisfied:
- (1)Any of the following system calls is issued, so that a higher priority task than the current one is placed in the READY state:
- irsm_tsk, iset_flg, irel_wai, isnd_msg, isig_sem, iwup_tsk, ista_tsk, irel_blf, ichg_pri
- (2)Any of the following system calls is issued, so that a task that is waiting for time-out (with a higher priority than the current one) is timed out to be placed in the READY state:
- tslp_tsk, twai_flg, twai_sem, trcv_msg, trcv_mbf, tsnd_mbf, tcal_por, tacp_por, tget_blf, tget_blk, dly_tsk
- (3)The current task is placed in the SUSPEND state by the isus_tsk system call.
- (4)The current task is moved to the last of the ready queue by the irot_rdq system call.
- 2.2 Timing of interrupt generation affecting task switching
- A task switch operation may be delayed in either of the following cases of interrupt generation:
- (1)An interrupt is generated during processing of terminating the current interrupt (the same processing as of the ret_int system call).
- (2)An interrupt is generated during processing of such a system call that is allowed to be issued only from tasks and thus followed by no task switch requests.
- 2.3 Examples
- If an interrupt is generated and a task is waked up in the sequence described below, the switch operation to the task (here, task1) is delayed until the subsequent interrupt is completed:
- (1)An snd_msg system call is issued in task2 that is of a lower priority (however, there are no tasks waiting for messages at this time, so they are accumulated in the mailbox).
- (2)An interrupt is generated during processing of the snd_msg system call.
- (3)During servicing this interrupt an iwup_tsk system call is issued to wake up task1 that is a higher priority than task2.
- (A task switch should occur at the point indicated by * in the following illustration to execute more privileged task1.)
-
Workaround When CC32R Used
Modify startup routine "crt0mr.ms" as follows:
* In MR32R V.1.10 Release 1 or earlier
[Modified]
----------------------------------------------------------------------------
bra __SYSCALL0_TMP ;TRAP7 <--- Modified
bra __SYSCALL1_TMP ;TRAP8 <--- Modified
rte ;TRAP9
nop
rte ;TRAP10
nop
rte ;TRAP11
nop
rte ;TRAP12
nop
rte ;TRAP13
nop
; rte ;TRAP14
; nop
; rte ;TRAP15
; nop
.section Int_Vector,code,align=4
bra __int_entry_TMP ; <--- Modified
; Add the following lines to the program
.section MR_KERNEL,code
.global __enq_dsp
__SYSCALL0_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __SYSCALL0
__SYSCALL1_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __SYSCALL1
__int_entry_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __int_entry
----------------------------------------------------------------------------
[Original]
----------------------------------------------------------------------------
bra __SYSCALL0 ;TRAP7 <--- To be modified
bra __SYSCALL1 ;TRAP8 <--- To be modified
rte ;TRAP9
nop
rte ;TRAP10
nop
rte ;TRAP11
nop
rte ;TRAP12
nop
rte ;TRAP13
nop
; rte ;TRAP14
; nop
; rte ;TRAP15
; nop
.section Int_Vector,code,align=4
bra __int_entry ; <--- To be modified
----------------------------------------------------------------------------
* In MR32R V.2.00 Release 1 or later
[Modified]
----------------------------------------------------------------------------
.AIF /&__Dbg_flg eq 0
bra __SYSCALL0_TMP ;TRAP7 <--- Modified
bra __SYSCALL1_TMP ;TRAP8 <--- Modified
.AELSE
.global __Dbg_entry0,__Dbg_entry1
bra __Dbg_entry0_TMP ;TRAP7 <--- Modified
bra __Dbg_entry1_TMP ;TRAP8 <--- Modified
.AENDI
rte ;TRAP9
nop
rte ;TRAP10
nop
rte ;TRAP11
nop
rte ;TRAP12
nop
rte ;TRAP13
nop
; rte ;TRAP14
; nop
; rte ;TRAP15
; nop
.section Int_Vector,code,align=4
bra __int_entry_TMP ; <--- Modified
; Add the following lines to the program
.section MR_KERNEL,code
.global __enq_dsp
.AIF /&__Dbg_flg eq 0
__SYSCALL0_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __SYSCALL0
__SYSCALL1_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __SYSCALL1
.AELSE
__Dbg_entry0_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __Dbg_entry0
__Dbg_entry1_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __Dbg_entry1
.AENDI
__int_entry_TMP:
st r0,@-r15
st r1,@-r15
ld24 r0,#__enq_dsp
ldub r1,@r0
or3 r1,r1,#0x80
stb r1,@r0
ld r1,@r15+
ld r0,@r15+
bra __int_entry
----------------------------------------------------------------------------
[Original]
----------------------------------------------------------------------------
.AIF /&__Dbg_flg eq 0
bra __SYSCALL0 ;TRAP7 <--- To be modified
bra __SYSCALL1 ;TRAP8 <--- To be modified
.AELSE
.global __Dbg_entry0,__Dbg_entry1
bra __Dbg_entry0 ;TRAP7 <--- To be modified
bra __Dbg_entry1 ;TRAP8 <--- To be modified
.AENDI
rte ;TRAP9
nop
rte ;TRAP10
nop
rte ;TRAP11
nop
rte ;TRAP12
nop
rte ;TRAP13
nop
; rte ;TRAP14
; nop
; rte ;TRAP15
; nop
.section Int_Vector,code,align=4
bra __int_entry ; <--- To be modified
----------------------------------------------------------------------------
-
Schedule of Fixing Problem
We plan to fix this problem in our next release.
|
|
