Re: [ECOS] using threads causes exceptions

[Gary Thomas <gary at mlbassoc dot com>]

On Wed, 2005-08-03 at 19:03 +0200, Stefan Sommerfeld wrote:
> Hi,
> >> >> >> >>
> >> >> >> >> I'm using eCos on an XScale PXA270 and i have a problem using
> >> >> >> >> threads.
> >> >> >> >> My
> >> >> >> >> program does only start a thread from main() and after this
> >> >> >> >> function
> >> >> >> >> calls
> >> >> >> >> from thread causes ABORT DATA exceptions (MMU info: Imprecise
> >> >> >> >> External
> >> >> >> >> Data
> >> >> >> >> Abort). Even a printf causes this exception. The strange thing 
> >> >> >> >> is,
> >> >> >> >> the
> >> >> >> >> eCos
> >> >> >> >> thread tests are working, even the stress test. Do i have to do
> >> >> >> >> some
> >> >> >> >> initialisation? Should i better use cyg_start() instead of 
> >> >> >> >> main()?
> >> >> >> >
> >> >> >> > Using main() is just fine.  Most likely, you've not created the
> >> >> >> > stack for the thread correctly.  Or perhaps it's something 
> >> >> >> > within
> >> >> >> > your thread itself.
> >> >> >> >
> >> >> >> > Have you tried running the program using GDB?  Then you can 
> >> >> >> > catch
> >> >> >> > the culprit and know where to start looking.
> >> >> >>
> >> >> >> So ... made it through gdb which gave me:
> >> >> >> [New Thread 2]
> >> >> >>
> >> >> >> Program received signal SIGTRAP, Trace/breakpoint trap.
> >> >> >> [Switching to Thread 2]
> >> >> >> 0xa008c72c in main_stack ()
> >> >> >>
> >> >> >> This version is a bit smaller and does give me no exceptions like
> >> >> >> ABORT
> >> >> >> DMA, but only the gdb output. Any suggestions?
> >> >> >
> >> >> > It's pretty obvious that you've not set your thread up properly
> >> >> > since it's trying to execute from the stack!  Look carefully at
> >> >> > how you created the thread - compare it against the examples and
> >> >> > tests.
> >> >>
> >> >> >From gdb it looks like a corrupt stack, but i don't why.
> >> >>
> >> >> > If you still can't figure out what's wrong, you could send a
> >> >> > *fragment* of your code, showing how you are creating the thread,
> >> >> > etc.  Note: we don't want/need to see your whole program, just
> >> >> > this portion.
> >> >>
> >> >> #define STACK_SIZE (CYGNUM_HAL_STACK_SIZE_TYPICAL*2)
> >> >>
> >> >> static cyg_thread thread_data;
> >> >> static cyg_handle_t thread_handle;
> >> >>
> >> >> static void decoder_audio(cyg_addrword_t data)
> >> >> {
> >> >>  diag_printf("i'm here\n");
> >> >>  // more complex C++ stuff here
> >> >>  // and a endless loop calling some methods
> >> >> }
> >> >>
> >> >>
> >> >> int main(void)
> >> >> {
> >> >>  void *stack = malloc(STACK_SIZE);
> >> >>
> >> >>  cyg_thread_create(0,                // Priority - just a number
> >> >>   test_thread,          // entry
> >> >    ^^^^^^^^^^^
> >> >
> >> > What is this?  It should be the entry point to your thread - maybe
> >> > 'decoder_audio'?
> >>
> >> Yes, of course. I changed it to test_thread for the source snipp, but
> >> actual entry is decode_audio. I see the diag_printf from the thread.
> >
> > So that means that your thread is running, so it's probably not a
> > problem of how you've created the thread (it looks OK modulo your
> > editing change).
> >
> > Now, you'll need to do some debugging in the "more complex C++ stuff".
> > Have you tried stepping through that code with GDB?
> 
> So i removed all code from the thread, but now the exception comes after 
> the thread exit.

It sounds like your failure is interrupt related as that's all that runs
after your thread(s) exit.

> 
> Is it correct that the main() function which starts the scheduler doesn't 
> continue after calling cyg_scheduler_start()?
> 

Yes.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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