We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello, I have developed an application using the 8051 and c51, there is a external memory 93c46 which contains the control variables for the applcations, these variables are read at the start of the application and are used further in the application. The values read from the memory are stored in the global variables and are used in the different routiens for the control purpose These variable get corrupted in the middle of the application causing unpridictable results. How can i say these variable get Corrupted? There is a ruotien to update these variables. The value of variables are displayed on screen and can be changed, after all the values are scaned and the values are stored back in the memory and application runs with the updated variables. so if a variable gets corupted it is visible in the routien which updates these variables More over if we switch off the application after seeing the corrupted variables in the the updation routien, before saving the corrupted variables, then after switching on the variables are read from the external memory perfectely well and can be seen quite well in the updation routien I am using AT89c51 micro which means the global variables get corrupted, which gets displayed in the updation rouotien Any help will be highly appericiated Thanks in advance Kapil
i dont see any hardware faults as the application runs fine for some time and this thing start happning after some time. You're misleading yourself there, I think. Things that work fine for quite some time, then suddenly become unstable, is exactly the kind of behaviour that is a lot more easily caused by flaky hardware than by software. Is it possible to have a breakpoint or check when a particular variable is accesed or changed? Yes. See "Debug->Breakpoints", then notice the 'read' and 'write' checkboxes towards the lower right of the dialog box. Doing this with the in-system debugger (ISD51) is likely to completely throw off your timing though, so better restrict this to the simulator.