This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: running twothreads problem


On Thu, 2003-05-22 at 16:20, Aaron Richardson wrote:
> 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?
> 

Looks pretty serious.  Have you had a look around the failure point to
try and see what's going on and why you got this trap?  Try something
like this:
  (gdb) x/10i $pc-8
  (gdb) info regs

Of course, if you're not comfortable with ARM assembly code, this will
be a new experience for you.

> 
> 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
-- 
Gary D. Thomas <gary.thomas@mind.be>


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]