On 7/17/2014 4:57 AM, Hesham Moustafa wrote:
> Hi,
>
> I am trying to get ticker.exe working properly for or1ksim BSP but
> there is a problem. When I run ticker, I only get the following output
>
> "*** BEGIN OF TEST CLOCK TICK ***
> TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988
> TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
> TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988"
>
> And nothing else. I tried to debug this issue using the following methods:
>
> 1- Set a break point at "put_name( Task_name[ task_index ], FALSE );"
> line, it always reach this point (with different task ids each time)
> but does not produce any output.
>
> 2- Set a break point at _Watchdog_Tickle function, and it's reached
> every time and decreasing the interval successfully.
>
> 3- Set a break point at _Watchdog_Remove function, and it's always
> reached every time I hit continue.
Then it sounds like you are getting clock ticks, ending the thread
delay, but the
IRQ code does not handle the path when a thread is unblocked and there
needs to be a context switch/preemption at the end of the IRQ processing.
_Watchdog_Remove can be called when a blocking operation doesn't time out
and I think it happens in this test.
_Thread_Delay_ended is the routine which ends the wake after.
_Watchdog_Ticks_since_boot is a handy counter of clock ticks.
On sis, here is a gdb session showing me getting to this point:
(gdb) b Init
Breakpoint 4 at 0x2001328: file
../../../../../../../rtems/c/src/../../testsuites/samples/ticker/init.c,
line 33.
(gdb) r
Starting program:
/home/joel/rtems-4.11-work/b-sis/sparc-rtems4.11/c/sis/testsuites/samples/ticker/ticker.exe
Breakpoint 4, Init (argument=33659712)
at
../../../../../../../rtems/c/src/../../testsuites/samples/ticker/init.c:33
33 TEST_BEGIN();
(gdb) p _Watchdog_Ticks_since_boot
$1 = 0
(gdb) c
Continuing.
*** BEGIN OF TEST CLOCK TICK ***
TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988
Breakpoint 3, _Thread_Delay_ended (id=0, arg=0x201c790)
at
../../../../../../rtems/c/src/../../cpukit/score/src/threaddelayended.c:32
warning: Source file is more recent than executable.
32 _Thread_Clear_state(
(gdb) p _Watchdog_Ticks_since_boot
$2 = 500
(gdb)
What you are not doing is the code that is
>
> 4- Set a break point at "status = rtems_clock_get_tod( &time );" at
> ticker.c, and time.second is always 0, never incremented. I though
> Clock_driver_nanoseconds_since_last_tick is the problem, so I made it
> return a static value to test it (12345 for example), but I got the
> same problem.
>
> Please note that the previous break points always reached when I hit
> continue every time, the timer interrupt keeps arising and do its work
> never stops, and the problem enters IDLE task.
This definitely sounds like not handling the context switch necessary
part of the
IRQ processing properly so always returning to IDLE. I call this a
simple return.
All ports have a version of this code. no_cpu should have reasonable
pseudo-code.
m68k is likely the easiest to read as real code.
You need to do a simple return if:
(a) IRQ is nested, or
(b) DISPATCH_NEEDED is false
Otherwise, you need to some CPU specific magic to get our of the IRQ and
back to the thread. Make it look like it called _Thread_Dispatch with
sufficient saved registers (e.g. callee destroyed). This is usually called
_ISR_Dispatch. When the call from _ISR_Dispatch to _Thread_Dispatch
returns, you do the magic needed to return tot he interrupted thread
(IDLE in this case) as if nothing happened.
> I would appreciate any hints or solutions regarding this problem.
>
> Thanks,
> Hesham
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
