[ECOS] running twothreads problem

Aaron Richardson aarichar@cisco.com
Wed May 28 09:16:00 GMT 2003


I cant seem to get back to where I had this problem.  I still get a SIGTRAP, 
but I think the processor is off in lala land.  Here is what I get when I try 
and get the code:


Program received signal SIGTRAP, Trace/breakpoint trap.
Ignoring packet error, continuing...

Error: Reply contains invalid hex digit 116

(gdb) x/10i $pc-8
0x222d2c:	Ignoring packet error, continuing...

Error: Reply contains invalid hex digit 116

(gdb) 



Also by getting the twothreads program to work, doesnt this mean that 
interrupts are working?  This program uses the timer to tell it when to wake 
up.

thanks,
Aaron




On Tuesday 27 May 2003 02:49 pm, Gary D. Thomas wrote:
> 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

-- 


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