Non Volatile Extended Memory (NVEM) User's Guide
This guide covers the NVEM feature in SPLat. You should in the very least skim through the whole document before attempting to use NVEM.
NVEM stands for Non-Volatile Extended Memory. Non-Volatile means this is memory that will not lose its data when the power goes off. Extended means that it exists as an extension to the regular memories in SPLat, which are the Program Memory and the RAM (formerly known as Data Memory).
The NVEM concept provides a framework within which we can implement a very wide range of memory types, ranging from a dozen bytes of battery backed RAM for power-out proofing all the way up to very large (megabyte) memories for data logging applications. All current SPLat products contain a type called "NVEM type 0". It is suited mainly to storing lookup tables within a versatile record structure. Other types may only ever be implemented in custom SPLat controllers.
Note: It is important to keep in mind that there are potentially many different types of NVEM, with different attributes. Not all types will be suitable for all applications, and not all types will exist in all controller models.
NVEM type 0, as provided in current SPLat models, is useful for:
- Storing static look-up tables, for example non-linear functions.
- Storing dynamically alterable user configuration tables (e.g. configuring a machine for processing different products such as custom processing cycles.)
- Storing LCD messages to save memory when the same message is displayed in several different places in your program
- Creating an applications specific scripting language and storing scripts in NVEM (this actually was the first live use of NVEM).
Not all SPLat products will contain all possible types of NVEM. In fact, no product prior to MMi200 and SL99 with dialect 15 Firmware contains any NVEM.
We introduced the first NVEM features into MMi200 and SL99 with language dialect 15. We call this type 0 (zero) NVEM, and it has special support in the SPLat/PC programming software (over and beyond the 30+ instructions that apply to all future types of NVEM). With type 0 NVEM SPLat has acquired not only a potentially large (up to 30K) memory for user configuration data, but also a versatile table lookup capability.
Note: NVEM type 0 (NVEM0) makes otherwise unused FLASH memory in the controller available for tables and other uses. It is the nature of FLASH memory that it will wear out after a certain number of writes (reads don't affect it). For that reason the NVEM0 in most controllers is unlikely to be suitable for applications involving frequent writes, such as data logging. As such, many controllers do not permit writes to NVEM0. P lease refer to the documentation for your specific SPLat model for more details.
Many controllers also have an on-board EEPROM chip, which is often used for a small amount of re-writable NVEM Type 1 (NVEM1) memory. On an HMI430 or HMI700, just under 4K of NVEM1 is available.
Most controllers also have spare RAM available. This is often made available as NVEM2. Being RAM, read/write endurance is not an issue. However, unless the whole device is battery-backed, NVEM2 will disappear when the power is cycled.
A very few controllers have battery-backed RAM available on the chip, which may be made available as NVEM3. On the HMI430 and HMI700, this is only 20 bytes. On most 32-bit controllers (specifically those based on the F4 family) with firmware built from 20 January 2020 this is 4KB. If there is no battery fitted, this memory will not last through power cycles. If there is a battery, on the other hand, NVEM3 becomes a useful backup system with no endurance issues.
CAUTION: You must take into account the possibility of power failing right in the middle of writing to any 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. That means that in the very least your program can have a good probability of avoiding the use of suspect data.