RealOS task switching on the TMP19

[Vicne]

Hi, all (and particularly leegong ),

I'm still debugging a very intriguing behaviour that sometimes keeps the interrupt level in the emulator too high, making the TMP19 irresponsive to task switching etc. - I'm going to post my current state in the emulator thread.
In the process, I'm particularly digging in the Task switching logic and I observed that many functions fiddle with the 16-bit bitmap stored at 0xFFFFFFE8 (either directly, like sub_BFC031BC_, or indirecly via the table @BFC04688, like sub_BFC02BE8_ or sub_BFC03948_, for example).

Do you have an idea what 0xFFFFFFE8 represents ?

Best regards,

Vicne

[leegong]

Do you have an idea what 0xFFFFFFE8 represents ?

Hi ,Vicne ,
Sorry ,no idea about @FFFFFFE8 .
Lots of sub functions call sub_BFC12E7C , so i would dig in code related to @ FFFFFFE8 .
Well ,the first step is to find who sets or clears @FFFFFFE8 .
EDIT : regarding sub_BFC12E7C , i tend to think it is a RTOS service call , which is called without input parameter ,returns one bool output in v0 , it might be one of
the following RTOS service calls ,maybe this could provide some help with us :
sns_dsp
sns_ctx
sns_loc
sns_dpn

Best regards
Leegong

[Vicne]

Well ,the first step is to find who sets or clears @FFFFFFE8 .

Well, not easy as it's mostly accessed indirectly. That address appears 21 times in the table @BFC04688.
Apart from that, it is also the initial value of the $SP in register sets 1-7, but as $sp is decremented before writing to it, that memory is probably never written to by writing to the stack.

But it is the very first value read by TaskDispatch(). I think I'll have to take a deeper look at it...

EDIT : regarding sub_BFC12E7C , i tend to think it is a RTOS service call , which is called without input parameter ,returns one bool output in v0 , it might be one of
the following RTOS service calls ,maybe this could provide some help with us :
sns_dsp
sns_ctx
sns_loc
sns_dpn

Indeed, I named the following functions:
-s 0xBFC02BE8=clear_bit13_of_FFFFFFE8_and_Task_Dispatch
-s 0xBFC03984=set_bit5_of_FFFFFFE8_and_Task_Dispatch
-s 0xBFC03948=reload_low8_FFFFFFE8_and_Task_Dispatch
-s 0xBFC031BC=check_FFFFFFE8_low11b_nonzero($v0 [OUT is_non_zero])

They are "rewrapped" into functions at higher addresses:
-s 0xBFC12E58=clear_bit13_of_FFFFFFE8_and_Task_Dispatch_00
-s 0xBFC12E64=set_bit5_of_FFFFFFE8_and_Task_Dispatch_00
-s 0xBFC12E70=reload_low8_FFFFFFE8_and_Task_Dispatch_00
-s 0xBFC12E7C=check_FFFFFFE8_low11b_nonzero_00($v0 [OUT is_non_zero])

The latter being called very frequently indeed. I thought about a "sanity check" but I'll have to check the syscalls you indicated.

Thanks, and don't hesitate to comment of course.

Best regards,

Vicne

[leegong]

Hi ,Vicne ,
I think that sub_BFC031BC might be one of the four service calls above , have you found more other subs which check different bit position @ FFFFFFE8 ?
or i have to search for them myself .
Best regards
Leegong

[Vicne]

I think that sub_BFC031BC might be one of the four service calls above , have you found more other subs which check different bit position @ FFFFFFE8 ?

Yes but I didn't go much further.
Subs that deal with that address in a direct way (not through the table @BFC04688 indirection) often reach it through the math "0x0 - 0x18", such as sub_bfc031d8_ which checks bit 13.
Similarly, bit 11 is set at 0xBFC005F4
The value is also incremented (!) at 0xBFC00EAC.
Bit 11 is tested at 0xBFC00FAC
etc.

It clearly is a key variable at a very low level...

Best regards,

Vicne

[leegong]

Hi ,Vicne ,
If we are sure that sub_BFC12E7C is one of the four service calls ,then i think @ FFFFFFE8 might be a combination of bits flags
related to dispatch enable/disable ,cpu lock/unlock ... etc , there is a similar one in lower version RTOS in FR .
EDIT : @(FP+0x4D) in this post http://nikonhacker.com/viewtopic.php?f=2&t=86&start=30

[Vicne]

If we are sure that sub_BFC12E7C is one of the four service calls ,then i think @ FFFFFFE8 might be a combination of bits flags
related to dispatch enable/disable ,cpu lock/unlock ... etc , there is a similar one in lower version RTOS in FR .
EDIT : @(FP+0x4D) in this post http://nikonhacker.com/viewtopic.php?f=2&t=86&start=30

I see. That's something like that for sure, but hard to give a precise meaning to individual bits.

Anyway, I stumbled upon a outstanding Emulator bug . Posting in Emulator thread right now...

Vicne

[leegong]

Hi ,Vicne ,
sub_BFC12E70 might is service call "sys_get_tid ", this service call gets called by sub_BFC1FF64 and sub_BFC17296 , "sys_get_tid" is logical for code behaviour of
these two subs , and another evidence : The input and output parameter of sub_BFC12E70 are same as that defined in service call "get_tid " in μITRON4.0 specification .
It is confirmed by sys_ref_tsk service call also .
Key instructions :
ROM:BFC0396A lbu $v0, 3($a3) # read @0xFFFFFFEB ; a3 = 0xFFFFFFE8
ROM:BFC0396C sw $v0, 0($a0) # OUT parameter
Edit: more service call decoding
BFC03818 ,BFC12C8C "sys_get_ixx"
BFC02BE8 might be "sys_dis_dsp"
BFC03984 might be "sys_ena_dsp"
BFC12C2C "sys_dis_int" ; set CMASK = 7 to disable all interruptions
BFC12C14 might be sys_loc_cpu ; a little different from definition in RTOS specification , it disables all interrupt ,store current interrupt level ,and disables dispatch
by means of clearing bit13 .
BFC12C5C , BFC12C68 , BFC12C74 , "sys_change_ixx"
BFC12C40 might be sys_unlock_cpu ; a little different from definition in RTOS specification , it restore previous interrupt level ,and eables dispatch by means of setting bit13 .

Best regards
Leegong

[leegong]

Hi , Vicne ,
I traced booting progress with version2.16 and took a look at the status table of each task , 0xD structures from 0xFFFFF244 to 0xFFFFF314 with length = 0x10 bytes for
each top task :
00000000 struc_task_attr struc # (sizeof=0x10)
00000000 task_Priority: .byte ?
00000001 activates_request_queue_count:.byte
00000002 wakesup_request_queue_count:.byte
00000003 suspend_request_queue_count:.byte
00000004 task_current_state:.byte
00000005 field_5: .byte ?
00000006 field_6: .byte ?
00000007 field_7: .byte ?
00000008 ptr: .word ?
0000000C field_C: .byte ?
0000000D field_D: .byte ?
0000000E field_E: .byte ?
0000000F field_F: .byte ?
00000010 struc_task_attr ends
I'm wondering about why no task is in state of running according to RTOS specificication :
tskstat: Task State
= TTS_RUN (0x01): RUNNING state
= TTS_RDY (0x02): READY state
= TTS_WAI (0x04): WAITING state
= TTS_SUS (0x08): SUSPENDED state
= TTS_WAS (0x0c): WAITING-SUSPENDED state
= TTS_DMT (0x10): DORMANT state
Best regards
Leegong

[Vicne]

I traced booting progress with version2.16 and took a look at the status table of each task , 0xD structures from 0xFFFFF244 to 0xFFFFF314 with length = 0x10 bytes for
each top task

Excellent.
If we can find the sys_ref_task, I should be able to call it and display state, like on the FR side.

I'm wondering about why no task is in state of running according to RTOS specificication

Well, they are all in either READY, DORMANT or WAITING states, if I'm not mistaken.
One could say that it's just the way it is when power is OFF... Reminds me of another CPU...

Vicne