It seems unlikely that it is an issue with the version of GCC (or at
least this is the least likly cause). It is more likely that your code
has memory error. When a memory corruption occurs the results are
non-deterministic; it will depend what gets corrupted and when and how
the corrupted data is subsequently used. By building with a different
tool, the code is likely to have a different memory organisation and
timing. So wheras before the corruption was benign or unobservable, it
is now causing a failure.

Causes of such errors include;

   * stack overflow,
   * buffer overrun,
   * array bounds error,
   * unitialised pointer,
   * unchecked memory allocation error.

They are amongst the hardest to erors to debug. You may need to post
your code to get more help. You should at least check that each task has
sufficient stack allocation, taking into account any library calls you
make; printf() for example requires a significant ammount of stack. If
your stacks are allocated dynamicaly, you need also to ensure that you
have a working sbrk_r() implementation, and that you have sufficient
heap space.

Clifford

pragnesh wrote:
>  what should i do for my code should i change the linker file for the
> code?

What for!? We have not yet determined what the problem is.

If as I suggested it is an error in your code, then you need to find and
fix the error. The linker script is unlikely to be the issue. The size
of the interrupt stack will be important when using an RTOS since the
system tick and sheduling will run in the interrupt context.

Depending on your BSP the kernel may switch from IRQ to Supervisor mode
during interrupt processing, so you will need to ensure you have enough
of both - check teh documentation for the processor port you are using;
in uC/OSII most processor specific ports are provided by third parties,
so it is not possible for me to determine teh requirements in your case
- unless you provide details of the port you are using.

Task stacks are separately allocated at run time, rather than being set
by the linker or the C runtime startup code - the system stack is only
important for the code that runs before you start the sheduler. Of
course, if you allocated these stacks from the system stack as local
array variables(a bad idea) then the system stack is important. Normally
you would use a static array or dynamically allocate the stacks from the
heap. For small systems with tight memory resources where tasks are not
dynamically created and destroyed, static allocation is normally
prefereable.

As I suggested before, it is impossible to say what the problem might be
unless you post the code. Have you tried just starting one task at a
time?

Of course if you are sure the code is fine (which I still doubt), then
you could always just stick with 4.0.1. There is probably no real
justification for migrating on such a minor increment. Martin Thomas has
worked hard to produce leading edge GCC builds (a service that most
other distributions charge for), and for some this is essential; but the
embedded systems market is rather conservative; most commercial
distributions are still based on 3.2 or 3.4, because for mission
critical tasks you want a mature release that has had all necessary
target specific patches applied.

Clifford