PDA

View Full Version : Clearing Index variable arrays



longpole001
- 25th July 2014, 06:16
Hi guys ,
i have a several large indexed arrays , that upon startup sometimes have values other than zero ,

should this happen ?

cheers

Sheldon

EarlyBird2
- 25th July 2014, 07:11
I assumed in the past when the chip is programed the variables are allocated space within the program area and I believe that the programmer does not initialise the variables to zero so if the variable space had previously been set those values will persist. I have come across this before and I always initialise my variables to known values if required. I wonder if chips are shipped with all bits set to zero or are some set during testing in the factory or just randomly as part of the manufacturing process.

Anyway as I said I have noticed this behaviour before and I initialise my variables within the program.

longpole001
- 25th July 2014, 07:29
thanks steve

HenrikOlsson
- 25th July 2014, 09:29
Hi,
Variables are stored in RAM - not in program memory (FLASH).
You can use the PBP command CLEAR to initialize ALL declares variables to 0 or you can use a FOR-NEXT loop iterating thru your array and write 0 (or whatever) to each location.

(And, when the chip is erased (program memory) all bits in the FLASH memory are set to one).

/Henrik.

EarlyBird2
- 25th July 2014, 09:41
Hi,
Variables are stored in RAM - not in program memory (FLASH).
You can use the PBP command CLEAR to initialize ALL declares variables to 0 or you can use a FOR-NEXT loop iterating thru your array and write 0 (or whatever) to each location.

(And, when the chip is erased (program memory) all bits in the FLASH memory are set to one).

/Henrik.

Thanks Henrik I knew you would put me straight, obviously it is RAM now you have told me. Why is the RAM not CLEAR to start with?

HenrikOlsson
- 25th July 2014, 10:29
Hi Steve,
If you look at the datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/39605F.pdf) for the 18F1220, section 4.0 you'll find the following:

Most registers are unaffected by a Reset. Their status
is unknown on POR and unchanged by all other
Resets. The other registers are forced to a “Reset
state”, depending on the type of Reset that occurred.
If you look further into that section you'll find a long a list of the Special Function Registers and what state they are in at POR and other types of resets. But, I hear you say, that's not the RAM where my variables are stored is it? Well, if you look at figure 5-6 (Data Memory Map) you'll see that the SFRs (all the peripheral control registers etc) and the general purpose RAM (where your declared variables are stored) are all just registers within the same block of volatile memory - which then brings as back to the quote from the Reset section: Their status is unknown on POR and unchanged by all other Resets.

Another useful hint, not directly related to variables in RAM but anyway, which I learned from Darrel (of course) not too long ago is that if you look at any register for any peripheral or what not there's a note above each bit where it says for example R/W-1 this means that that particular bit in that particular register is Readable and Writeable AND that it's POR state is 1. If you look at the CONFIG Words it might say R/P-1 which means it's Readable, Programable (but not writable at runtime) and it's erased state (since this is program memory, not RAM) is 1.

Does that make sense?

/Henrik.

EarlyBird2
- 25th July 2014, 10:37
Certainly does make sense. Thanks yet again Henrik.

longpole001
- 26th July 2014, 03:56
interesting i did not know that on the data sheet , or missed its real meaning ,