Problem with ticker.exe for or1ksim/OpenRISC BSP

[Hesham Moustafa]

On Thu, Jul 17, 2014 at 3:10 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
> 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.
>
The same problem, it's called the varying 3 task IDs every time I hit continue.
> _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)
>
I followed this procedure and I got the same results.
> 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
>
This is a macro that defines the address of the corresponding variable
within the per cpu config table right? Please correct the following if
I it's wrong. From assembly (when doing restore after C ISR handler is
executed), I have to load this variable value, check if it's true
(greater than zero), and if yes, jump to _ISR_Dispatch. I am a little
confused what context should be loaded in both cases of: simple
return, and _ISR_Dispatch; In case of _ISR_Dispatch, should I save
stack pointer and return address and other context like normal context
switch (function call)? While in interrupt context (simple return), I
am saving almost all registers with some other necessary registers
related to exceptions.

One thing I have a problem with, is when using some macros like
DISPATCH_NEEDED (it's a variable address right?) I am normally
including rtems/score/percpu.h from the assembly file (which does the
magic) to get these definitions but the compiler suffers. I think I
have to provide compiler option or something to just include #define
macros? If yes, where to add it?

> 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>