This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: clock interrupt fails to call unlock_inner()
well, i am currently testing clocktruth.cxx program, and i m stuck in
this problem past 2-3 weeks..my timers are working perfectly fine, they
generate an periodic interrupt as required, and the ISR routine is
called but not the DSR routine. this fails to intialize the rtc->tick
and my rtc->counter is always 0 when read.
well, now i have even changed my clock to run at 10ms, instead of
10us as stated earlier..i just don`t get where could be the problem..i
tried all possibilities..but still not able to solve this issue.
i even upgraded my gcc to 3.3, but still no success.
some one plz help,
thanks,
satish
On 23 Sep 2003 11:01:16 +0100
Nick Garnett <nickg@ecoscentric.com> wrote:
> Satish Kumar <satish@bvt.sc.sanyo.co.jp> writes:
>
> > Hi,
> > when the clock interrupt takes place, my
> > hal_interrupt_stack_call_pending DSRs func is not called. following is
> > the intermediate path when an clock interupt takes place.
> > i.e
> > when i enter into the interrupt_end() func, following steps are
> > followed:
> > Set_Save_Context()--|
> > post_DSR()
> > Set_Save_Context()--|
> > |
> > Get_Current_Thread()----|
> > | Set_Save_Context()
> > |
> > Get_Sched_lock()
> > |
> > unlock()(fails to call unlock_inner() func)
> > |----
> > |
> > Set_Sched_lock()...!!!!!
> > |
> > |-----
> > unlock()
> > Get_Current_Thread()----|
> > |
> > Set_Save_Context()
> >
> >
> > Now the problem is that when the unlock() func is stepped in the
> > identifier "__lock" is undefined and hence Set_Sched_lock()
> > is called..instead of unlock_inner() func which is responsible for
> > invoking hal_interrupt_stack_call_pending_DSRs.
> >
> > this fails to call the DSRs from RealTimeClock and hence i fail to test
> > any of my program which is dependent on the clock interrupt.
> >
> > well my dsr_list contains the data entry for the clock interrupt
> > generated and also the interrupt vector no: are all correct.
> >
> >
> > so, is there somethin which i m failin to understand.
>
> Just because in the particular instance of a call to interrupt_end()
> that you traced the scheduler lock was >0 does not mean that this is
> always the case.
>
> Instead of wasting time trying to trace through the kernel, I suggest
> you look hard at the code you have written to program the timer
> device. The bug is almost certainly in there. You have already told us
> that you are trying to run the clock at a ridiculously high
> frequency. Try running it at the standard 10ms rate rather than
> 10us. At 10us per tick the CPU is probably just taking one
> interrupt after another and not making any other progress.
>
> Also try running some of the standard test programs such as tm_basic
> and clocktruth. These are much better tests of system behaviour than
> the examples.
>
> --
> Nick Garnett eCos Kernel Architect
> http://www.ecoscentric.com The eCos and RedBoot experts
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
--
Satish Kumar <satish@bvt.sc.sanyo.co.jp>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss