EmbDev.net

Forum: ARM programming with GCC/GNU tools problem of gcc version


Author: pragnesh (Guest)
Posted on:

Rate this post
0 useful
not useful
i am working with the U-cosII and i create a simple four tasks that
blink the led at the different rate, i had sucessfully build the hex and
downlod on the lpc2148 target board. and i had achive my o/p. for the
above  build  i have used the arm-elf-gcc 4.0.1.

Now after some time i download the newer version of the arm-elf-gcc
4.0.2 and i tried to build the above porject. I didn't get0 any error
while compliing and hex is also generated. and  i download the hexfile
to the same target but i didn't get the o/p,means all leds are set at
their default state.

please help me to resolve the above porblem.

hoping for the reply,

thankyou

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
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

Author: pragnesh (Guest)
Posted on:

Rate this post
0 useful
not useful
Thankyou for reply

 what should i do for my code should i change the linker file for the
code?

and again complie?




hoping for reply

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
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

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
Just an additional idea: Newer versions of a compiler usualy have better
optimization strategies. For example: maybe a forgotten volatile in the
source has never been noticed before because the optimizer of an older
version did not use a "core-register" as temporary storage but created
instructions to always read/write the memory.

Martin Thomas

Author: pragnesh (Guest)
Posted on:

Rate this post
0 useful
not useful
Martin Thomas wrote:
> Just an additional idea: Newer versions of a compiler usualy have better
> optimization strategies. For example: maybe a forgotten volatile in the
> source has never been noticed before because the optimizer of an older
> version did not use a "core-register" as temporary storage but created
> instructions to always read/write the memory.
>
> Martin Thomas


Thank you sir

your suggestion is very helpful to me. i have solved my problem in my
previous code i change the variable to the "volatile".

Thank you very much for your suggestion.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.