PIC18F1220 - Variables initialisation placement makes a change

Hi all,

I'm struggeling for hours trying to find out why my program is working or not working depending on where I place the variables initialisation in my program. It's about to send an SMS and the destination mobile number is stored in an array of 12 elements.

After numerous tests, I found out that if I place my variables declaration at the beginning of my program (almost the top), the variables are wrongly initializied. If I put my variables far down in my code, juste before I have to use them, everything is working fine :confused:

I use a 18F1220 for the first time and chose this PIC because it was in my drawer and more precisely, because I can declare an array of 160 elements allowing me to store a full SMS in one single array.

But does this PIC has some particular specs that makes him tricky to me? Is there something I should learn about memory organisation?

Are you using a clear command after you initialize the array?

Ioannis

No, I actually never use CLEAR.

This is extremely strange.

If you have other 18F series chip, can you try it also?

Then maybe on support.melabs.com forum, Charles can see if this is a 18F specific bug.

Can you post your test code to have a look?

Ioannis

I have found in the past that whenever I see something like this in my program, I have not defined the array correctly - one less element than I need, or bytes instead of words. Just because it's not defined correctly, does not mean you can't write to it as if it was, and then overwrite something. Where you put the definition in the program defines whether or not you end up overwriting useful code, or unused space. That's why it is helpful to post the code, rather than a generic question. Somebody will spot this condition and point it out, rather than guessing about device bugs. Maybe you have found a bug... maybe not.

Further, variables aren't automatically initialized (ie set to a specific value).

Where in your code you put the declaration of the variable can change the ORDER of the variables in RAM so if, like Charlie says, you're somewhere writing outside of an array it's possible that the order in which the variables are declared makes important variables get corrupted in one case and not so important varaibles get corrupted in the other. In either case you have a potential problem that you need to find - provided that IS indeed what's happening of course.

For example

Code:

---

SMS VAR BYTE 160
Index VAR BYTE
SMS[160] = "A"

---

Classic error there, arrays are zero indexed so the last element of the SMS array is SMS[159]. In this case Index will be assigned the value "A" because Index is declared right after the SMS array. Now, that might not ALWAYS be the case depending on where it all ends up relative to RAM banks and such.

Try to cut the code down to a minimal that still shows the error and post it.

/Henrik.

Hi, Flotul

From the very far I remember ...

ALL Variables have to be initialized before using them ....

Only one exception : IF you write variables the first time you use them ...

Say :

Code:

---


Flotul VAR Byte
...
Flotul = 4*Switzerland_cheese_weight*Price_per_pound

---

as here, Whatever the initial value of "Flotul" , it will be overwritten ...

BTW, I often observed "FF" was the default value for an erased chip, BUT I also found other values - especially for EEPROM - , may be because of chip tests @Factory ...

SO, Only ONE rule : Carefully initialize all and every variable if you do not want to have surprises ...

We're not programming Arduinos here ... :D:D:D

Alain

Hi All,

Yup....initilisation....

I declared an array:

Code:

---

...
RxBuffer VAR BYTE(18)
...

---

and used it like this:

Code:

---

HSERIN 200,READ_SMS,[WAIT("+CMGR:"),WAIT(10),DEC4 RxSMSCode, STR RxBuffer\180\10]

---

After having had a good fondue (and read all your comments), I finally pointed out where my mistake was hiding. And I don't mean to convince anybody here about the healthy benefits of swiss cheese (not for the liver but apparently for the eyes), but...there must be something :D

The behaviour of the program is really confusing with this error. Some variables stay as declared an others have their value "randomly" changed.

Arghhhh!! This one cost me hours....:o

Thanks to All again ;)