Automatic RESET during operation

"my recursive function has no local DATA, it just Prints Text on an LCD, and calls another sub-routine depending upon the input from a keypad,"

I'm not sure we are using the same definition of "recursive function".

A recursive function is a function that calls itself, or calls other functions in a call chain where one of the directly or indirectly called functions will call the original function again.

So recursion means that the call chain forms a loop.
With a non-recursive design, you can still call several levels deep, but the call sequences just forms trees.

The compiler/linker explicitly analyses the call sequences by the code, to figure out the branches of the call tree - functions that are never part of same path from root (main) to leaf of the call tree can use the same memory locations for storing local data or parameters. So the variables/parameters gets overlayed in global data space because the 8051 don't have a real stack powerful enough.

With more general processor architectures, the compiler don't need to perform this optimization. It's enough to just push parameters and local (auto) variables on the stack, and pop when the function returns.

"my recursive function has no local DATA, it just Prints Text on an LCD, and calls another sub-routine depending upon the input from a keypad,"

I'm not sure we are using the same definition of "recursive function".

A recursive function is a function that calls itself, or calls other functions in a call chain where one of the directly or indirectly called functions will call the original function again.

So recursion means that the call chain forms a loop.
With a non-recursive design, you can still call several levels deep, but the call sequences just forms trees.

The compiler/linker explicitly analyses the call sequences by the code, to figure out the branches of the call tree - functions that are never part of same path from root (main) to leaf of the call tree can use the same memory locations for storing local data or parameters. So the variables/parameters gets overlayed in global data space because the 8051 don't have a real stack powerful enough.

With more general processor architectures, the compiler don't need to perform this optimization. It's enough to just push parameters and local (auto) variables on the stack, and pop when the function returns.

we are using the same definition of recursive function

i have got a "chain" in which one function calls another and so on till one another function in the chain calls the initial function... so let me put the code here

home_Screen()
{ ---------
Lock_Screen();
-------
--------
}

Lock Screen() //Checks the Password
{ if(yes)
Main_Menu();
else return;
}

main_menu()
{ ---------
---------
switch()
{ ----
---
- -
- --
case 4:Home_Screen(); //when user presses the "Home" Button

// Here is the recursion. this is just one of the recursion,s there are other functions too
} }

i am working on getting this code into a non-recursive format...
and once more
im just a beginner in embedded C, i am not as learned as you guys !!

Your issue is that you mix the code for displaying a menu with the code that processes it.

So you handle one menu, then jump to screen-lock then have the screen-lock once more call the function to handle the same menu, after unlock. That is wrong.

With the draw function separated, you don't need a recursive call to redraw the main menu after unlock.

current_display = x;
wanted_display = y;
locked = false;
pwd_input_state = 0;

void handle_display() {
    if (idle_time > AUTO_LOCK) {
        locked = true;
        pwd_input_state = 0;
    }
    if (locked) wanted_display = DISP_LOCKED;
    if (current_display != wanted_display) {
        switch (wanted_display) {
            ...
            case DISP_LOCKED:
                saved_display = current_display;
                draw_screen_lock();
                break;
            case DISP_MAIN:
                draw_screen_main();
                break;
            case DISP_SUBMENU_1:
                 draw_submenu_1();
                 break;
            default:
                ; // should not happen - do some repair
        }
        current_display = wanted_display;
    }
    input = check_input();
    if (input) {
        clear_idle_time();
        switch (current_display) {
            ...
            case DISP_LOCKED:
                if (is_unlock(input)) {
                    wanted_display = saved_display;
                }
                break;
            case DISP_MAIN:
                switch (input) {
                    case BUTTON_1: do_main_1(); break;
                    case BUTTON_2: do_main_2(); break;
                    ...
                 }
                 break;
             case DISP_SUBMENU_1:
                 switch (input) {
                     ...
                 }
                 break;
             default:
                 ; // should not happen - do some repair
        }
    }
}

void main() {
    for (;;) {
        ...
        handle_display();
    }
}

So you handle one menu, then jump to screen-lock then have the screen-lock once more call the function to handle the same menu, after unlock. That is wrong.
wrong whether embedded or not, it is just bad design

Erik

"wrong whether embedded or not, it is just bad design"

It's more interesting than that. What if the second stacked main menu also gets a timeout and locks the screen. Or the 100th nested call to the main menu? Then we have the situation:
menu -> lock -> menu -> lock -> menu -> lock -> ....

Any processor with a finite state storage area would run out of state space (wither a hw stack or a software-implemented stack) for such a design.

Any processor with a finite state storage area would run out of state space (wither a hw stack or a software-implemented stack) for such a design.
I have actually seen that one, a frustrated used pressing the button umpteen times and SPLASH!

Erik