[ECOS] running twothreads problem

Aaron Richardson aarichar@cisco.com
Tue May 27 22:39:00 GMT 2003


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?

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


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



More information about the Ecos-discuss mailing list