CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC18F252 software program

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Vovachess



Joined: 15 Mar 2004
Posts: 33
Location: Swiss

View user's profile Send private message Visit poster's website ICQ Number

PIC18F252 software program
PostPosted: Mon May 15, 2006 2:50 am     Reply with quote

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







PostPosted: Mon May 15, 2006 3:46 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon May 15, 2006 4:19 am     Reply with quote

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

View user's profile Send private message Visit poster's website ICQ Number

PostPosted: Mon May 15, 2006 5:33 am     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group