This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
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