[ECOS] using threads causes exceptions
Gary Thomas
gary@mlbassoc.com
Wed Aug 3 16:37:00 GMT 2005
On Wed, 2005-08-03 at 18:27 +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?
--
------------------------------------------------------------
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
More information about the Ecos-discuss
mailing list