Re: [ECOS] running twothreads problem

[Aaron Richardson <aarichar at cisco dot com>]

Well, it looks like the code that implemented the hal_interrupt stuff was 
#defined out and it didnt do anything.  I have now turned on the interrupt 
code and I get this when I run under GDB:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x002003b0 in handle_IRQ_or_FIQ ()

Any idea what this means and why I got it?


thanks,
Aaron



On Thursday 22 May 2003 04:45 pm, Gary D. Thomas wrote:
> On Thu, 2003-05-22 at 14:35, Aaron Richardson wrote:
> > Gary was right in saying that my problem was that I not getting system
> > clock interrupts.  I enbled the test code in thread.cxx to force a clock
> > tick and now twothreads is running.
> >
> > Where do I find the system clock code for debugging.  Shouldnt this be in
> > the HAL layer somewhere?  I cant seem to find it.
>
> It is indeed.  Since the clock is so fundamental, there are macros
> which define its behaviour.  Look at how these are implemented:
>   HAL_CLOCK_INITIALIZE( _period_ )
>   HAL_CLOCK_RESET( _vec_, _period_ )
>   HAL_CLOCK_READ( _pvalue_ )
>   HAL_CLOCK_REINITIALIZE( _freq, _period, _old_hz )
>   CYGNUM_HAL_INTERRUPT_RTC
>
> > thanks,
> > Aaron
> >
> > On Thursday 22 May 2003 11:21 am, Aaron Richardson wrote:
> > > Well, I have done a few things and learned a few lessons:
> > >
> > > I have upgraded the toolchain to the ecos 2.0 toolset.  While doing
> > > this I have figured out that I need to wipe out my .eCosPlatforms dir
> > > and build a new platform for my target.  For soem reason using the old
> > > dir and the 2.0 configtool had problems together.  This caused problems
> > > running the tests. After that things were up and running again.
> > >
> > > Now that I have determined that I need to turn off tracing I am failing
> > > on the following tests(I didnt run any tests after clocktruth):
> > >
> > > bm_sem2
> > > clock1
> > > clocktruth
> > >
> > > All these tests timedout (although I turned the timeout down to 5 mins
> > > from 15).  So I think this problem is related to the twothreads problem
> > > that I am having.  The twothreads calls the delay function, which I
> > > assume would be using some clock fuction that the tests above are
> > > failing on.
> > >
> > > I guess I should start looking at the clock interrupt?  Any good way to
> > > look for this?  What am I looking for?
> > >
> > > Any other place to start looking?
> > >
> > > thanks,
> > > Aaron
> > >
> > > On Wednesday 21 May 2003 04:15 pm, Aaron Richardson wrote:
> > > > Ok, so I figured out my problem with the context test.  I had tracing
> > > > on in the ecos build and this threw off the test because of all the
> > > > output that was being sent to the screen.  I will need to re-run all
> > > > the tests again without tracing turned on.  However, this was not the
> > > > problem with the twothreads, because I initially tried this without
> > > > tracing (and prompty found tracing to help debug).
> > > >
> > > > Aaron
> > > >
> > > > On Wednesday 21 May 2003 03:31 pm, Gary D. Thomas wrote:
> > > > > On Wed, 2003-05-21 at 14:17, Aaron Richardson wrote:
> > > > > > Ok.  I am able to build, load, and run an ecos application.  The
> > > > > > hello world application is running just fine.  However, when I
> > > > > > run the twothreads program the code gets locked up.  I get the
> > > > > > following on the console:
> > > > > >
> > > > > > Entering twothreads' cyg_user_start() function
> > > > > > Beginning execution; thread data is 0
> > > > > > Beginning execution; thread data is 1
> > > > > >
> > > > > > I turned on tracing and it doesnt ever come back from
> > > > > > idle_thread_main.
> > > > > >
> > > > > >
> > > > > > Also I was able to get some tests running (although not all
> > > > > > compile) and several of the first few failed.  Perhaps this
> > > > > > points to the same problem? Here are the tests that failed.
> > > > > >
> > > > > > context
> > > > > > bm_sem1
> > > > > > bm_sem2
> > > > > > clock0
> > > > > > clock1(never finishes)
> > > > > > clocktruth(never finishes)
> > > > >
> > > > > First guess is that you're not getting any system clock interrupts.
> > > > > This would prevent the clock tests from working, as well as any of
> > > > > the others that require multiple threads to be scheduled.
> > > > >
> > > > > If 'context' doesn't work, you have fundamental scheduling
> > > > > problems. I'd get it fixed first.  Then try and see if interrupts
> > > > > work at all, etc.  GDB is a handy tool for this.
> > > >
> > > > --
> > > >
> > > >
> > > > Aaron Richardson
> > > > aarichar@cisco.com
> > > > 512-378-1286
> > >
> > > --
> > >
> > >
> > > Aaron Richardson
> > > aarichar@cisco.com
> > > 512-378-1286
> >
> > --
> >
> >
> > Aaron Richardson
> > aarichar@cisco.com
> > 512-378-1286
>
> --
> Gary D. Thomas <gary.thomas@mind.be>

-- 


Aaron Richardson
aarichar@cisco.com
512-378-1286


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss