View previous topic :: View next topic |
Author |
Message |
future
Joined: 14 May 2004 Posts: 330
|
How many of you are having ram allocation problems? |
Posted: Sun Feb 18, 2007 11:49 am |
|
|
Hi,
I would like to know how many of you, like me, start having problems with code that was previously working before the project gets bigger.
I have functions that worked fine for years and simple code addition to other sections makes them fail.
It seems that the compiler optimization is badly reusing its ram space.
The compiler version is 3.249 with a 18f452.
Code: | ROM used: 25038 bytes (76%)
Largest free fragment is 7726
RAM used: 646 (42%) at main() level
817 (53%) worst case
Stack: 10 worst case (5 in main + 5 for interrupts)
|
What did you do to work around the problem?
Thank you. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Feb 18, 2007 12:22 pm |
|
|
Have you looked at the Symbol Table ? Can you see if some RAM
locations are re-used when they should not be ? |
|
|
future
Joined: 14 May 2004 Posts: 330
|
|
Posted: Sun Feb 18, 2007 12:44 pm |
|
|
Yes, there is a major reusage here... but I don't know which one would be correct.
Lowering the optimization level does not seem to solve the problem.
Code: | char uinterp( char x, char x1, char x2, char y1, char y2 )
{
char x21, dx, r;
long temp;
...
}
|
Code: | 21D uinterp.x
21D-220 @MUL3232.P1
21D Pulse.@SCRATCH
21D TASK_Crank.@SCRATCH
21E uinterp.x1
21E Pulse.@SCRATCH
21E TASK_Crank.@SCRATCH
21F uinterp.x2
21F Pulse.@SCRATCH
21F TASK_Crank.@SCRATCH
220-223 @DIV3232.P1
220 uinterp.y1
220 Pulse.@SCRATCH
220 TASK_Crank.@SCRATCH
221 uinterp.y2
221-224 @MUL3232.P1
221-222 @MUL321616.P2
221 Pulse.@SCRATCH
221 TASK_Crank.@SCRATCH
222 uinterp.x21
222 Pulse.@SCRATCH
222 TASK_Crank.@SCRATCH
223 uinterp.dx
223-224 @MUL321616.P1
223 Pulse.@SCRATCH
223 TASK_Crank.@SCRATCH
224 uinterp.r
224 @DIV3232.@SCRATCH
224 Pulse.@SCRATCH
224 TASK_Crank.@SCRATCH
225-226 uinterp.temp
225 @MUL3232.@SCRATCH
225 @DIV3232.@SCRATCH
226 @MUL3232.@SCRATCH
226 @DIV3232.@SCRATCH
|
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Feb 18, 2007 1:00 pm |
|
|
It's normal for CCS to re-use RAM for local variables after their
existance has expired -- for example, when a function exits and
returns control back to main().
One place where it would a problem, would be if an interrupt routine
used RAM for local variables that was used by other routines in the
program. From just the little code that you posted, I can't really tell
if this is happening.
Some of your symbols are called "Task". Does this mean you're
using the CCS RTOS ? I don't have that, because I only have the
command line compilers. |
|
|
future
Joined: 14 May 2004 Posts: 330
|
|
Posted: Sun Feb 18, 2007 1:18 pm |
|
|
Yes, I am using the RTOS only to time these tasks.
I wonder how to trust the code having problems like this... How to know if another locations aren't being changed?
You seem to have a good experience with firmware writing. What kind of debugging tools do you use?
The icd gives me a great help while writing routines alone, but it is very hard to debug a more complex system. I have passed the 11k lines barrier and it is a headache that a already tested module starts failing. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Feb 18, 2007 2:08 pm |
|
|
The only time we use a commerical RTOS here at the company is for a
large project where the customer is willing to pay for it. Then, the
software guy here does all the coding. I'm not the one who does it.
I do the smaller projects that don't require a commerical RTOS. |
|
|
Ttelmah Guest
|
|
Posted: Sun Feb 18, 2007 2:08 pm |
|
|
Let me give you an example of the sort of thing that can cause problems.
The first would be, a subroutine that returns a pointer to a local variable. It will initially work, but will fail once RAM useage leads to re-use. Now this is not the compilers 'fault', but a failure in programming, the variable should be declared as static to prevent this.
A second example, would be a local routine, that 'assumes' a local variable is zero when it is called. Relying on 'zero RAM' to zero it in the first cal, and then clearing it itself before exiting. Again this will initially work, but will fail, if something else uses the area. Again the problem is the result of careless programming.
Key rules that avoid these problems are:
1) Always initialise variables on entry to routines.
2) Use static variables for any data accessed using pointers.
Now these are just two examples, but most problems of this sort, come from the same type of sources.
Best Wishes |
|
|
future
Joined: 14 May 2004 Posts: 330
|
|
Posted: Sun Feb 18, 2007 9:48 pm |
|
|
It seems that the compiler is having problems with temporary storage. If I simplify the code breaking big expressions in shorter ones the problem goes away.
I'll investigate what is exactly causing the problem.
Thank you for the tips. |
|
|
|