This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using threads causes exceptions


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.


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

Bye...


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]