Posted on: 2009-03-20 10:22
Hello, I m using YAGARTO Tool to compile my code for CPU-AT91SAM7X512.
This tool provide ECLIPSE as editor and GCC VERSON 4.2.1 as compiler. I
developed one project which is consuming code memory around 265KBytes
and 33KBytes of RAM. When i m runing this code it works ok. Now i add
other .c & .h files. But i m not calling any function or not using any
variables out of these last added files. I just add these files in
project and then compile those files. But i m not using any file out of
last added files. Now when i run, succesfully build code on cpu it
executes some part of code and than what its doing not able to
understand. When i debug code i found that when it find devision
operation, than cpu will go somewhere else and not run next remaining
code. After adding .c & .h files my code size becomes around 353KBytes
and RAM around 66KBytes. So, i want to know why my code is not running
proper if i add others .c & .h files, even i m not using those files in
my code ? I need those last added files but right now i just compile
those files. I think there may be some MAKEFILE problem. Because right
now i found that i just compile code not using added code. So, just
compilation make this difference.
In my MAKEFILE i provide option " -fno-common -O2 -g " for
compilation.
In devision operation i m deviding WORD(2 Byte Unsigned Data) by
1000.0 and saving result in float type variable. Even i tried with
adding casting for WORD to FLOAT. At time of executing division
instruction it is generating Undefined Exeception Interrupt.
Posted on: 2009-03-28 20:21
Bhavin Tailor wrote: > I think there may be some MAKEFILE problem. Because right > now i found that i just compile code not using added code. So, just > compilation make this difference. Blaming the makefile for a run-time error is not really applying Occam's razor is it? The chances are that there was always a bug in your original code but by adding additional files you have changed the memory context in which the code runs. For example the result of dereferencing a bad pointer for example depends on the content of the location it points to, by adding code you may have changed that content from something benign that appears to work, to something that now show symptoms. > In my MAKEFILE i provide option " -fno-common -O2 -g " for > compilation. The first thing to do if you are having code errors is switch off optimisation. You cannot sensibly debug code with optimisation switched on since the compiler will often perform out of order execution. It is even possible that you are blaming the divide operation when it has nothing to do with it. Debugging at source level with optimisation switched on makes no sense, there is no longer a one-to-one in order relationship between the machine instructions and source lines. If you find that your code runs without optimisation, but fails with optimisation, it is almost certainly your code at fault and not the optimiser. Unsafe but valid code will often run with the simple parsing rules used by the normal compilation but not by optimisation, because the optimiser assumes that the code is good. Lack of volatile where needed is often the cause: http://www.embedded.com/columns/beginerscorner/990... You should also use the -Wall -Werror compiler options and fix all warnings. It will improve your code quality. > In devision operation i m deviding WORD(2 Byte Unsigned Data) by > 1000.0 and saving result in float type variable. Even i tried with > adding casting for WORD to FLOAT. At time of executing division > instruction it is generating Undefined Exeception Interrupt. By dividing by a double precision floating point value you are in fact pulling in a considerable chunk of library code. It is probably best to just avoid floating point on hardware that does not have an FPU. It isn't usually hard to avoid.