SV: SV: SV: SV: [Icc-avr] Stack problems

[Jim Patchell]

It comes with practice...

Where I work, first thing I tell C newbies:

Never put arrays on the stack (auto variables/local variables)...it is 
just bad practice, especially in an embedded controller.

Stack problems are very difficult to track down.

-Jim

Bengt Ragnemalm wrote:
> I understand the problem that only generating obvious errors could give you
> a false safety but all errors that can be generated is good errors in my
> point of view.
> 
> I still feel a little lost in what to do to check that I do not use too many
> local variables. 
> 
> The example below will be the same regardless if the array is used in a
> function or in main.
> 
> /Bengt
> 
> =============
> The code could be for example be this: (Full program)
> 
> #include <iom88v.h>
> #include <macros.h>
> 
> void Function(void)
> {
> 	unsigned char array[3000];	// RAM is 2k
> 	unsigned short index;
> 	array[index]=0;
> 	index = 3000;
> 	array[index]=0;	// Writing in cyberspace
> }
> 
> void main(void)
> {
> 	Function();
> }
> =============
> 
> The map file:
> 
> Map File Summary V3.2.3 for IccV7 AVR
> run at 2008-08-22 10:36:44
> on project "\\Annatar\benra\Projekt\Slask\SLASK"
> 
> Memory summary:
> 
> flash size is 8192 bytes (8KB)
> flash used for
> - int vectors     = 52 (0x34) bytes from 0x0000 to 0x0033 = 26 (0x1A)
> instruction words from 0x0000 to 0x0019
> - code            = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91)
> instruction words) from 0x001A to 0x00AA
> +- user code      : -52 (0x-,) bytes from 0x0034 to 0x000/ = -26 (0x/&)
> instruction words) from 0x001A to 0x000/
> +- <library>      : 342 (0x156) bytes from 0x0000 to 0x0155 = 171 (0xAB)
> instruction words) from 0x0000 to 0x00AA
> flash usage is 342 bytes or 4.2%, leaving 7850 bytes (7KB) free
> 
> sram size is 1024 bytes (1KB)
> sram used for
> - s/w stack = 994 (0x3E2) bytes from 0x0100 to 0x04E1
> - h/w stack = 30 (0x1E) bytes from 0x04E2 to 0x04FF
> 
> eeprom size is 512 bytes
> no eeprom area found
> 
> 
> Areas:
> (items sorted by name)
> 
> FLASH area "text" used for code
> FLASH area "text" = 290 (0x122) bytes from 0x0034 to 0x0155 = 145 (0x91)
> instruction words from 0x001A to 0x00AA
>   _Function =  110 (0x006E) words
>   __start   =   33 (0x0021) words
>   _exit     =    1 (0x0001) word
>   _main     =    1 (0x0001) word
> 
> FLASH area "vector" used for interrupt vectors
> FLASH area "vector" = 2 (0x02) bytes from 0x0000 to 0x0001 = 1 (0x01)
> instruction words from 0x0000 to 0x0000
> 
> <eof>
> 
> 
> 
>> -----Ursprungligt meddelande-----
>> Från: icc-avr-bounces at imagecraft.com [mailto:icc-avr-
>> bounces at imagecraft.com] För Richard Man
>> Skickat: den 21 augusti 2008 21:42
>> Till: icc-avr at imagecraft.com
>> Ämne: Re: SV: SV: SV: [Icc-avr] Stack problems
>>
>> Currently, the compiler does not do any check on the local variables,
>> because any checking would be at best a guess (unless it does full
>> call tree analysis and layout all the SRAM usage). While it can
>> clearly complain in the obvious cases, it will do a lousy job overall
>> and then people will complain about false security.
>>
>> If you look at the View->"Map File Summary" it gives you an estimate
>> on how big the software stack can be. Generally speaking, you
>> shouldn't be pushing the limit of the SRAM, so it should be farily
>> easy for you to see what your margins are. If you are really pushing
>> the limit, you would need to check and test carefully anyway.
>>
>> At 05:55 AM 8/21/2008, Bengt Ragnemalm wrote:
>>> One more question about this.
>>>
>>> If I declare a local array that is larger than the RAM, I do not get an
>>> error. Is that because the compiler can not be sure that this array will
>>> actually be placed in RAM as it can point to anything?
>>>
>> // richard (This email is for mailing lists. To reach me directly,
>> please use richard at imagecraft.com)
>>
>> _______________________________________________
>> Icc-avr mailing list
>> Icc-avr at imagecraft.com
>> http://dragonsgate.net/mailman/listinfo/icc-avr
> 
> 
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr
> 
> 

-- 
----------------------------------------------
Visit http://www.noniandjim.com
SDIY: http://www.noniandjim.com/Jim/index.html
----------------------------------------------