On Thu, Jul 17, 2014 at 3:10 PM, Joel Sherrill <joel.sherr...@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@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
