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

Urgent! Strange LCD problem! Very Strange!!

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



Joined: 11 May 2005
Posts: 57
Location: london

View user's profile Send private message

Urgent! Strange LCD problem! Very Strange!!
PostPosted: Tue Aug 02, 2005 4:22 am     Reply with quote

Dear all,

I desperately need you help here!

I am working on a project with 18f8722 which communicates with DSP and display all necessary data on a dot matrix LCD.

OK, here comes the main problem. Yesterday when I tried to add on global array with 4 elements(int) into the code, just a signle global array, the LCD crashed!!! The code was running, and I could still select options on the LCD via a keypad but there were hash on the display!

At the first sight of it, I thought there could be some dodgy connections on the hardware board but I quickly got rid of it because I then found the LCD worked with an old code.

The memory could be suspecious but the memory usage given by the LIST file is like



Filename: run.LST

ROM used: 42568 bytes (32%)
Largest free fragment is 65536
RAM used: 787 (20%) at main() level
2315 (60%) worst case
Stack: 14 worst case (10 in main + 4 for interrupts)


It doesn't appear with any problems here with the memory.




Could anybody think about that for me, please. I really need to figure it out before continue.


Sorry to say I am not able to give the code here because it has nearly 5k lines and neither the related sections because of the complication of the code structure.


Thanks in advance!
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Tue Aug 02, 2005 4:49 am     Reply with quote

Often errors like this occur because of buffer overflows.
You added a new variable which causes the memory map to change. A buffer that was previously overflowing into an unused memory region is now affecting one or more of your other variables.

Sometimes these errors can be in your code for a long time without causing troubles, i.e. it is not always related to the new code you added.

Try to figure out which variables are affected, then check the symbol file (*.sym) for the variables that are directly in front of these affected variables. Very likely that will point you to the code causing the buffer overflow.
ye



Joined: 11 May 2005
Posts: 57
Location: london

View user's profile Send private message

PostPosted: Tue Aug 02, 2005 4:59 am     Reply with quote

ckielstra,

Thank you very much for your explanations first.

I feel quite interested in the SYM file when saw it because I didn't really know there was such a file to look at Embarassed ... Razz

Can I raise some questions here?

Is SYM file a simple list of all the variables that exist in the code and what the number is in front of each variable?

.....


By the way, what could cause overflow? Or more explicitely how could I define an overflow error if it happens?


Cheers mate
ye



Joined: 11 May 2005
Posts: 57
Location: london

View user's profile Send private message

PostPosted: Tue Aug 02, 2005 5:09 am     Reply with quote

You know what, I've "figured out" the problem by moving the global array to another place!

Certainly the buffer overfloading problem is still hidden in the code! But how can I drag it out???

I admit the fact that the buffer overfloaded into an unused memory area but I don't think you can find it out by looking at the variables directly in front of the affected variables. What do you think?
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Tue Aug 02, 2005 5:22 am     Reply with quote

Quote:
Is SYM file a simple list of all the variables that exist in the code and what the number is in front of each variable?
The numbers are the address or address range of the variable in memory. Now there is one thing to be noticed: The CCS compiler is very efficient in re-using memory, for example local variables in a function will be located at a certain address, but when the compiler sees no conflicts it will locate local variables of another function at the same addresses. That's why you will see many variable names with the same number (address) in the symbol file.

example of common buffer overflows:
Code:
char MyString[5];

MyString[5] = 'a';          // Overflow error, the array starts counting at position 0
strcopy(MyString, "12345") // Overflow error, the terminating zero will also be copied
for (i=0; i<=5; i++)       // Overflow error, use '<' i.s.o. '<='
  Mystring[i] = getc();
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Tue Aug 02, 2005 5:36 am     Reply with quote

ye wrote:
You know what, I've "figured out" the problem by moving the global array to another place!

Certainly the buffer overfloading problem is still hidden in the code! But how can I drag it out???

I admit the fact that the buffer overfloaded into an unused memory area but I don't think you can find it out by looking at the variables directly in front of the affected variables. What do you think?
This kind of behavior is almost a certain proof of a buffer overflow problem. In general these are the more difficult to find problems. Now you are lucky to have a good and a bad version. Compare the symbol table for the two versions and the error will be in one of the variables that acquired a new address. When lucky only a few addresses are changed, but often you will find that the new global variable is placed in one of the lower addresses and all variables will have new addresses in the error version.

If you can't find the problem this way there are several methods to continue digging, but be aware it will be hard work.
1) Using the debugger step through the code part controlling the LCD and figure out what goes wrong.
2) Do a code review. Read your source code and pay special attention to buffer allocation and routines manipulating the buffer contents. Even better have someone else check your code, the other person will look with 'new eyes' to your code.
3) Play a bit more with the symbol table. Move variables to other addresses and see when behavior changes.

Please continue looking for the cause of the error and don't continue because you found a workaround. Currently you are capable of repeating the error situation, if you continue the error will return in the future but might then not be as easy to spot as it is now.
Guest








PostPosted: Tue Aug 02, 2005 6:57 am     Reply with quote

ckielstra, many thanks for your ideas.

I will look at the code and see what i can do to get rid of overflow errors

cheers
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