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 Tue, 2003-05-27 at 13:28, Aaron Richardson wrote:
> So, I traced the problem to a line of code that is written in asm.  It says 
> that it is enabling interrupts.
> 
> void hal_unmask_all_int()
> {
>     unsigned rtmp = 0;
> 
>     // enable IRQ
>     asm volatile("mrs %0,cpsr\n"
>         "bic %0,%0,#0x80\n"
>         "msr cpsr,%0\n"
>         : "=r"(rtmp) : );
> }
> 
> But I dont do ARM asm yet....
> 
> any ideas what this does?

Just what the function name implies - it enables (unmasks) all
interrupts, allowing them to happen.  Once this instruction
executes, interrupts will occur which is how you got to the code
below.

Did you look around the instruction mentioned below to see what's
there?

> 
> thanks,
> Aaron
> 
> 
> 
> On Thursday 22 May 2003 06:07 pm, Gary D. Thomas wrote:
> > 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>
> 
> -- 
> 
> 
> 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]