i am facing a wierd problem.. My MCU P89V51RD2BN resets during Execution... i am a college student and a beginner Here so i dont know the Advanced Programming methods i would also inform that..
i have a recursive function , a warning is issued by the compiler for the same. but....
earlier this was not a problem but since i have modified some of the Sub-Routines for 16Bit Data this Problem has come up, i need those functions to be 16 bit because of the limitation of the ALU i was earlier using 8bit and leaving most of the Task to Assumption which i cannot do so now..
i would also state that the Problem occurs in a fumction at a point when i call 2 functions in the same code, these themselves call around 5 sub-routines each but that wasnt a problem earlier (before i used the 16bit return type sub-routines).
now i found something in the manual stating reentrant Functions, but i really dont know how to use it
i used it like this
void Home_Screen_Instance() reentrant { ------------ } Do i need to use the keyword "reentrant" in the Function Decleration too? but that didnt help either but the compilers shows an error Home_Screen_Instance : redefinition. Target Not Created
this was the first of a kind problem that i encountered, my MCU is resetting itself for sure(i checked that with a dummy subroutine of blinking LED) and it is not because of the watchdog timer, i am sure about that too..
so whats the Problem here?
is the Stack overflowing??? or there is any other reason behind this? should i revert back to the 8bit versions of my subroutine (without any other choice)? is it because of the recursive nature of the function H0me_screen_instance?
Related Data:
The Program is Display intensive, i mean there are a lot of Strings to be displayed and they are stored beforehand in XDATA, message shown during sucessfull compilation, (still resets) Program Size: data 9.4 xdata 252 code 9514 creating hex-----blah blah blah---- 0 Error(s) 65 Warning(s)
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!