Stack over flow problem....

prayami · Joined: 22 Dec 2004 Posts: 78

Dear all....

This time very bad experiences, I have passed through. And in big trouble. As our project is finished and about to release and just come to know that sometimes values of the variables are changed themselves.

To test that, I have declared one #locate function register in my program and just assign value 10 to it and display it, rest of the huge code is as it is. When I turn the power off and on then everytime the value displaying is different.

asmallri · Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia

The 18F family has a 31 level stack. So it does not look like stack overflow is your problem however you have an option to set a fuse to cause a PIC reset in the event of underflow or overflow so you could use this fuse to help debug this issue.

If you variables are being overwritten, ignoring a compiler bug, a few of common cultrits are:

_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks for replay....

Here with I come with more detail. I have reduced around 32 bytes of variables' in my program now. Everything is same....And now it seems working. This means in the case of previous program it was using more RAM.

The RAM of 18F4525 is 3980 bytes. And compiler is showing that it is using max of 9% then, why it is over written perticular address. The #locate test_display = 0x0069 variable was totally newly introduced for testing and it was not using any where in the program. The same variable for less RAM, it is preserving its value.

When I compile the old program then it was giving following :

Ttelmah · Guest

Without seeing what you are doing, it is impossible really to answer. But the most likely culprits, are code dealing with the arrays 'sample_values', 'input_str', 'int_str', and 'scroll_text'. Common things to forget, are that a 14 character string, will need a 15 character array, and that arrays in C are zero referenced (so indexes are 0 to 13, not 14). Any code accessing this type of variable, can walk over other variables. The PIC, does not have any form of hardware memory protection. Asmallri, has given a good list of the likely problems.
Posting a list of variables, is pretty nigh pointless. If you know that address 69, is being affected, then look in the symbol map for anything using addresses close to this, which you access using pointers or arrays. You need to identify what part of your code actually changes the value.

Best Wishes

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks Ttelmah and asmallri.....

I have increased the size of arrays for null termination. And it is still doing the same. I have looked at the manual but couldn't find such things. I have still few questions which might solve the problem....

(1) Just want to confirm:
Upto this, I know that it is require to have (required array size+1) for sprintf function. But is it require for any array no mater it is constant or simple array (i.e. one not gonna used with sprintf).

(2)
Is it fine if I only declare one size greater than I require. Or I require to assign it null terminated value.
e.g. I require only SampleValues[10] but declared

unsigned int16 SampleValues[11] ;

Is it require to assign SampleValues[10] = '\0';

(3)
I have two more constant array in one function like under. Which are declared like below.

BYTE CONST LED_MAP[10] = {0x81,0xBD,0xC8,0x98,0xB4,0x92,0x82,0xB9,0x80,0xB0}; // 0 to 9
BYTE CONST LED_DOTMAP[10] = {0x01,0x3D,0x48,0x18,0x34,0x12,0x02,0x39,0x00,0x30}; // 0 to 9

But as you said, is it require to declare like under. Please let me know if below declaration is not OK...see last element is null terminated.

BYTE CONST LED_MAP[11] = {0x81,0xBD,0xC8,0x98,0xB4,0x92,0x82,0xB9,0x80,0xB0, '\0'}; // 0 to 10
BYTE CONST LED_DOTMAP[11] = {0x01,0x3D,0x48,0x18,0x34,0x12,0x02,0x39,0x00,0x30,'\0'}; // 0 to 10

(4)
In the previous program, as you said to see the File Registers' symbol mapping. I can see that before #locate test_display 0x0069 address there is no array assingned. The sequence is as under

BarLbKpa
SetDC1
test_display
SetDC2
Memory

Then how can the arrays effect to address 0x0069. I have checked that there is no incorrect type casting. Is there any way they can affect that address?

(5)
If it was the problem of array with null termination. Then why it was working when I had reduced some variables and code but the arrays' size was still the same.

(6)
As I have 16 functions in my program + two ISR. And wright now I have written #SEPARATE before three small functions. And before rest of the functions nothing written. Is it fine if I don't write anything. Because I just tried to make total 5 #SEPARATE for function and 2 #SEPARATE for two ISR then my memory is full. So leave it as it is and let compiler to do it.

(7)
Is there any book or manual available from which I can know these kind of things.....

Thanks......

asmallri · Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia

The string length + 1 applied to any string related function. You do not need the terminator for non string related functions.

When using string related functions in C, For example puts(mystring), The puts function extracts characters byte by byte from mystring until it gets to the string terminator with is the value 0x00.

When you use any of the C functions that assign contents to the string they will automatically add this terminator.

Lets say the string test (previously declared as char test[10];) was initialised with the strcpy to contain "Hello" If we examine the contents of test we have
test[0] = H
test[1] = e
test[2] = l
test[3] = l
test[4] = o
test[5] = 0x00 or \0
test[6] .. test[9] = undefined (has not been initialized)

If we puts(test) we get Hello

If we now set test[2] = 0 we get
test[0] = H
test[1] = e
test[2] = 0x00 or \0
test[3] = l
test[4] = o
test[5] = 0x00 or \0
test[6] .. test[9] = undefined (has not been initialized)

If we now puts(test) we get He

So the string functions will stop when they hit to string terminator but if I access the array contents individually I can read all elements. If there is no terminator the string functions we attempt the continue printing the contents of memory until they eventually find one.

If I have a character array that will not be access by string functions then I do not need a terminator. If I create an array and initialize it by placing by putting values into each location manually but want to use printf type functions to print the string then I need to have a NULL terminator at the end of the string.

Another problem (the most common for beginners of C) is they declare a string that is too short. Often by 1 because they forget the terminator, but also when they make changes to the code (send longer stings to functions like gets()) without increasing the size of the variable. In this case variable that are place in memory after our string get overwritten by the string.

The stuff mentioned above is standard C behaviour as documented by K & R
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks...asmallri....

My array declaration is OK.

Still question, I have reduced some code in my program. And now I have declared #SEPARATE or #INLINE statement before all the function. And it seems working.

Now it is not modifying any variable. When I say reduced the code means I have reduced some of the variable declared and wrote it with direct value.

Where can I see int1 variable mapping in the memory?

I got type casting at many places in my program can it create problem....

e.g.

prayami · Joined: 22 Dec 2004 Posts: 78

Hi...

Here there was my code....But as it is too long I have deleted it. As I come to know what was the problem.

Check the last post which can be useful to many and give comments if you want......

asmallri · Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia

The problem with type casting over writing variables typically occurs when a pointer of one type is cast to be a pointer of another type. When this mechaism is used incorrectly it can trash adjacent variables.

This is why strict type casting languages such as PASCAL were developed. PASCAL is a far better language to use for developing applications that need to be brought to market quickly because it is very hard for an application developer to make these types of errors. By contrast, PASCAL lacks the flexibility of C for allowing a developer to get down and dirty with the hardware.

Giving guidance is oone thing but I don't have the time to wade through your code (sorry) I have my own fires to put out :-)
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

Ttelmah · Guest

Like Asmallri, the amount of code is just too long to spend time looking through. You need to use a debugger, or some simple tests internally, to 'narrow down' what part is going wrong. However looking at the interrupt handler, a couple of things 'leap out:

prayami · Joined: 22 Dec 2004 Posts: 78

Thanks....Ttelmah and asmallri....

First the if statement Ttelmah have written was comment and shifted to next line so just i gnore it. You guys wright that code is too long to debug. And My actual code is longer than that but when I post it some portion is not displaying, I don't know why...might be some character in the code preventing to display.

My problem is some register values are over written and changed unexpected. Timer thing is fine.....I can't figure out why..?? I got lots of RAM left....then why..?? Only one array is associated with sprintf function and thus declared one element more for null termination.

I want to let you know that I have used following kind of casting code in my program...if you find to take care of something then let me know...

prayami · Joined: 22 Dec 2004 Posts: 78

Hi...Thanks everybody.....

Here with I come to know what was the problem. And I would like to share it to all so can be useful for other. Masters' comments are welcome.

In my variable declaration there was following line:

Ttelmah · Guest

You can make all variables default to zero on power up, by using #zero_ram
However this takes significant time to execute.
Normally the data sheet definition of what to expect in a RAM cell, is 'xxxxxxxx' after power on (undefined).
Safest, and quickest, is to do what you are now doing, and initialise everything, that is not inherently initialised before use.
Glad you have found it.

Best Wishes