Some issues about stack in microcontroller programming

The compiler uses two stacks when generating code: one is the hardware stack for subroutine calls and interrupt operations, and the other is the software stack for parameter temporary variables and local variables passed in the stack structure. The hardware stack is allocated from the top of the data memory, and a certain number of bytes are allocated below the hardware stack as the software stack. Both the hardware stack and the software stack are downward-growing stacks (note: this is opposite to the 51 microcontroller).

Usually if your program does not have subroutine calls nor calls library functions like printf() with %f format, then the default of 16 bytes should work well in most cases. In most programs except for very heavy recursive calls to reentrant functions, a maximum of 40 bytes of hardware stack should be sufficient.

If the function call level is too deep, the hardware stack may overflow into the software stack, changing the content of the data in the software stack. Similarly, when too many local variables are defined or too many local collection variables are defined, the software stack may overflow into the dynamically allocated data area. Both stacks may overflow. If the stack overflows, unpredictable errors may occur. You can use the stack check function to detect whether the two stacks have overflowed.

There is a Return Stack Size option in the Target page, which is used to specify the size of the hardware stack (to store function return values). Usually, if the subroutine call nesting is not deep (no more than 4 layers), the default 16 bytes is sufficient. If floating-point functions are used, it should be set to at least 30 bytes. In general, except for deep recursive calls and the use of the %f format specifier, setting it to 40 bytes is sufficient.

The hardware stack is allocated starting from the top of data memory, and the software stack is allocated a certain number of bytes below it. The size of the hardware stack and data memory is limited by the target device setting in the compiler options. The data area is allocated starting at 0x60. This is right after the IO space. The data area and software stack are allowed to grow towards each other.

If you choose a target device with 32K or 64K of external SRAM, the stack is placed at the top of the internal SRAM and grows toward lower memory addresses. See Program and Data Memory Usage. An important reason for any program failure is stack overflow into the range of other data memory. Either stack can overflow, and bad things can happen occasionally when one stack overflows. You can use the stack check functions to detect overflow conditions.

About stack checking functions:

The startup code writes a code (0xaa) in the lowest byte of the hardware stack and the software stack, respectively. This code is called the warning line. If the hardware stack and the software stack have overflowed, the code (0xaa) of the warning byte will be changed. The stack check function determines whether the two stacks have overflowed by checking whether the code of the lowest byte of the two stacks has been changed. The stack overflow is checked by calling the _StackCheck(void) function. If the code in the warning line byte still maintains the correct value, the function check passes and there is no overflow. If the stack overflows, the warning line byte may be destroyed. The _StackCheck(void) function detects that the code in the warning line judgment byte has been changed, and determines that the corresponding stack overflows (when the program stack overflows, the program may not run normally or crash occasionally). The function then calls the function _StackOverflowed(char c). If the parameter is 1, the hardware stack has overflowed; if the parameter is 0, the software stack has overflowed.

The following points should be noted when using the stack inspection functions:

1. When using the stack check function, you must use #include "macros.h" to preprocess it.

2. If you use your own startup file, in versions after ICCAVR6.20, if there is no warning line in the startup file, ICCAVR will automatically add the warning line. In versions before ICCAVR6.20, you must add this part yourself, otherwise the stack allocation in the generated code will not have a warning line.

3. If you use dynamic memory allocation, you must skip the warning line byte _bss_end to allocate your heap (that is, add one byte). For details, see the memory allocation function description

4. When the _StackCheck(void) function detects that the warning line byte has been changed, it will call a default _StackOverflowed function to jump to the location of program memory 0 (reset vector address). You can specify or rewrite a new function to replace it, for example, you can use the new function to indicate which stack overflowed, etc., but this function cannot perform too many functions or restore the program to normal state. Because after the stack overflows, some useful data will be changed, causing unpredictable errors and even causing the program to crash.

The following is a simple example to illustrate the role of the stack check function:

main( )

{

init() //Call the initialization program

float a,b;

a=1.0;

b=1.0;

printf("a = %fn", a);

printf("b = %fn", b);

_StackCheck(); //Call stack check function

}

_StackOverflowed(char c)

{

if (c == 1)

puts("trashed HW stack"); //Hardware stack overflow

else

puts("trashed SW stack"); // software stack overflow

}