View previous topic :: View next topic |
Author |
Message |
Vovachess
Joined: 15 Mar 2004 Posts: 33 Location: Swiss
|
PIC18F252 software program |
Posted: Mon May 15, 2006 2:50 am |
|
|
I have one nice problem with my software on PIC18F252.
In the software I have parameters defined in ram:
unsigned char inbuffer[60];/*input/output buffer*/
unsigned char Mode_Power1=2;/*Working state of server1*/
unsigned char Mode_Power2=1;/*Working state of server2*/
unsigned char supcyc=0;
unsigned char cyctime=20;
unsigned char init_webparamerets_count=0;
The Software works correctly over 20-24 hours. And once some parameters will be changed by controller! I can control data traffic between controller and PC on RS232. I see that controller makes once:
Mode_Power1=38;
Mode_Power2=13;
What could it be, that controller changes parametes values during execution? My software can not set so strage values! The most strage thing, that the software works hours correctly and suddenly changes!
Could it be stack overfull? Compile problem�.Something else?
Thanks for ideas. |
|
|
Ttelmah Guest
|
|
Posted: Mon May 15, 2006 3:46 am |
|
|
The 'most likely' cause is that 'inbuffer' is overflowing somewhere. This would then corrupt the values immediately latter in the memory, and since the compiler will normally store variables 'as they are declared', this really is the highest probability. You need to look at the .sym file, and find where the variables are actually declared in memory, and then look at the code that accesses the thing immediately 'in front' of this (probably inbuffer'). Remember that a 60 element array can only hold values from 0-59.
The second most likely cause, is a power spike. RAM is about the most sensitive thing to variations in the supply.
The stack, has no relation/connection to the main RAM, but a stack overflow (if you don't trap this - on most processors you can force a restart if this occurs), can lead to the processor jumping anywhere in memory, and 'unexpected' results. The .LST file, shows how close to the stack limits your code goes.
Best Wishes |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon May 15, 2006 4:19 am |
|
|
Sounds like a buffer overflow problem. This happens for example when you write to an array using an index larger than the array size, the variables in memory directly following the array will be corrupted.
Buffer overflows are often difficult to debug because they only happen once in a while, often after running successfully for several hours, days or even years. Therefor don't try to find the cause of the error by testing, but try finding it by studying your source code.
You already have a strong clue by noticing that two of your variables changed values. Have a look at the symbol file for your project (*.sym). It will look something like Code: | 000 @SCRATCH
001 @SCRATCH
001 _RETURN_
002 @SCRATCH
003 @SCRATCH
004 @SCRATCH
005-040 inbuffer
041 Mode_Power1
042 Mode_Power2
043 supcyc
044 cyctime
045 init_webparamerets_count | The buffer to suspect will be in memory somewhere before the corrupted variables. Have a look at the variables placed in memory before your first damaged variable. Assuming the example memory map of above is similar to yours, it is very easy to point out the suspect: only inbuffer is placed before Mode_Power1 (the scratch variables are compiler internal and can be neglected).
Check all locations in your program where you write data to the inbuffer array. Make sure you have added checks to prevent writing data at inbuffer[60] or above. |
|
|
Vovachess
Joined: 15 Mar 2004 Posts: 33 Location: Swiss
|
|
Posted: Mon May 15, 2006 5:33 am |
|
|
Hello
Thank you very much for your answers! It looks like really this problem.
I ll check it. It is really strong error......!!!!
Thanks you |
|
|
|