View previous topic :: View next topic |
Author |
Message |
ye
Joined: 11 May 2005 Posts: 57 Location: london
|
Urgent! Strange LCD problem! Very Strange!! |
Posted: Tue Aug 02, 2005 4:22 am |
|
|
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! |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Aug 02, 2005 4:49 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
ye
Joined: 11 May 2005 Posts: 57 Location: london
|
|
Posted: Tue Aug 02, 2005 4:59 am |
|
|
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 ...
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 |
|
![](templates/subSilver/images/spacer.gif) |
ye
Joined: 11 May 2005 Posts: 57 Location: london
|
|
Posted: Tue Aug 02, 2005 5:09 am |
|
|
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? |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Aug 02, 2005 5:22 am |
|
|
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(); |
|
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Aug 02, 2005 5:36 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Tue Aug 02, 2005 6:57 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|