MMi203: Non-volatile memory
The term non-volatile memory means a form of memory that does not lose its data when the power goes off. It can be implemented using a variety of technologies. Your hard disk drive is non-volatile. The magnetic core memory used in computers in the 60's and 70's was non-volatile. Some systems use a small battery to keep the memory powered up even when main power is off. The technologies commonly used in SPLat boards are known as "EEPROM" and "FLASH" memory.
The controller implements three kinds of non-volatile memory: "Permanent" memory, "Shadow" memory and "Non-Volatile Extended Memory" (NVEM). The Permanent memory has existed in SPLat boards almost from the very beginning. Shadow memory is a much newer development made possible by advances in microcontroller technology. NVEM is even more recent, and was introduced into off the shelf products in dialect 16.
Permanent memory
This type of non-volatile memory was introduced into SPLat in March 1998. It allows just 13 bytes of RAM (data memory) to be saved into a non-volatile memory as a indivisible (all or nothing) block to be later restored. The two instructions for this are PermStore and PermRecall.
Shadow memory
This is newer type of non-volatile memory, introduced in March 2002 in language dialect 10. It allows all of RAM to be selectively backed up to a "shadow" memory in blocks of any size, and likewise to be restored in blocks of any size. It also allows the shadow memory to be cleared in blocks, and supports indexed and jndexed addressing for more sophisticated data management in larger projects.
The term shadow memory comes about because it is a region of non-volatile memory that overlaps the RAM. When a certain RAM location is written to the shadow memory, it is written to the same byte address within the shadow memory as its own RAM address.
The instructions for shadow memory are ShadowWrite, ShadowRead and ShadowClear. All these can be used as indexed as well as non-indexed instructions.
Shadow memory is not affected by downloading a new program to the controller. That means any user setup parameters (for example) will remain unchanged. That represents both an advantage and a risk. If you change your program or we change the way we allocate RAM (defBYTE etc) you could have problem, because suddenly your parameters are no longer at the expected addresses. You should therefore consider using absolute RAM addresses (mEQU) to allocate RAM to user parameters.
NVEM page 0
The controller implements "NVEM page 0", which is a non-volatile memory that makes available any of the User Flash memory in the processor chip that is not used by your program.
Comparison between nonvolatile memory types
The following table compares the three nonvolatile memory types as implemented in most SPLat controllers. Actual figures vary between specific products. Make sure you read the descriptions of each type for your product.
| Type | Size | Typical use | Endurance (in typical product) | Notes |
|---|---|---|---|---|
| Perm-mem | 13 bytes | Cycle counters, hour meters | 500K to 1M | Does NOT survive downloading of a new program |
| Shadow | Same size as RAM | User configuration data | 10,000 total (not per byte!) | Survives downloading of a new program |
| NVEM page 0 | However much of User Flash is not used by your program. Maximum 32K. | Lookup tables, infrequently changed configuration or pattern data, scripts | 10,000 per block. | Must be presumed corrupted if a new program is downloaded. |
Endurance of non-volatile memories
Certain non-volatile memory technologies have a finite life, as defined by the number of writes or erases (clear cycles) they can endure. For permanent memory this translates to the total number of times a PermStore can be executed before the memory is likely to give erroneous data. For shadow memory it means the total number of ShadowWrite or ShadowClear instructions before it is likely to give errors. For NVEM0 it is the total of writes to any block of (typically) 512 bytes.
(In older products shadow memory was genuine byte-writable EEPROM, and the endurance was per byte. More recent models use main FLASH because the newer chips lack EEPROM, and each write entails re-writing the whole shadow block. Hence the endurance is now total writes to the block).
You should take great care to not write a program that will write or clear the non-volatile memory so often that it gets worn out too soon.
Example: Say a given non-volatile memory has a stated endurance of 100,000 cycles, and your program counts cans of sardines at a rate of 100 per minute, updating the non-volatile memory after every count. Your board would only last 1000 minutes, or about 2 shifts. If you re-write your program so it only updates the non-volatile memory once per hour, you would get 100,000 hours or about 12 years life, with some loss of accuracy as the trade-off.
CAUTION: You must take into account the possibility of power failing right in the middle of writing to the non-volatile memory. Unless specifically stated for the SPLat product you are using, there is always a possibility that data will be corrupted if that happen. You must therefore ensure, by the design of your system, that there will be no disastrous consequences of corrupted data.
The Permanent Memory has the best protection in this regard. Data is written with a checksum, and the PermRecall instruction provides a result indicator in the R register. This means that in the very least your program can have a good probability of avoiding the use of suspect data.
In the case of writing to NVEM page 0, the risk can be even worse. NVEM page zero follows directly on from the program memory. That means you could be writing to the same (typically 512 byte) block as the end of your program or read-only data tables. A power failure during a write would result in your program getting corrupted. You should therefore have an unused areas of 512 bytes between the program or read-only tables and the part of NVEM page 0 that is to be written to.
Caution: Exceeding the endurance of FLASH memory may damage the controller. It will also void the product warranty.
Support in SPLat/PC
All types of non-volatile memory are supported in SPLat/PC.
The support for permanent memory is documented in the SPLat/PC "classic" help file. In the help file index search for "Permanent memory".
SPLat/PC simulates shadow memory by saving the shadow data in the computer's memory. The data is initialized to all zero's when SPLat/PC is first launched. After that it is affected only by simulated shadow memory instructions. That means you can stop and restart a simulation and the shadow memory data is retained. There is no simulation of an unsuccessful ShadowWrite or ShadowClear.