Echelon FT 3150 Smart Transceiver - Manual (Page 35)

FT 3120 / FT 3150 Smart Transceiver Data Book 29
Integrity Mechanisms
The system image checksum covers the system image. It is only available when the system image resides in off-chip
memory and its use is optional. A system image checksum error always forces the device to the applicationless state.
No checksum is computed if the device is in the applicationless state.
The checksums are all verified during reset processing by the network processor and as part of the background
diagnostic process. The background diagnostic process causes the device to reset when an error is detected; no state
change occurs. It is assumed that any persistent error will be found by the reset processing.
Upon detecting a checksum error, the reset process will force the appropriate state and log an error in the error log.
For the FT 3150 Smart Transceiver, a checksum must fail twice during reset processing in order for it to be deemed
bad.
Reboot and Integrity Options Word
An FT 3150 Smart Transceiver has a number of options for actions taken following a checksum error or other
memory related fatal errors. The 16-bit word resides in the system image and is defined as part of the export options
of the device in the LonBuilder and NodeBuilder tools.
The recovery process relies on the fact that the initial on-chip EEPROM image for the application, configuration, and
communication parameter data reside in the off-chip system image. During initial power up, the system image data is
copied (booted) to on-chip EEPROM. The recovery process recopies or reboots the suspect areas as dictated by the
error and the recovery options. Any changes made to the on-chip EEPROM (e.g., a network application load or
network tool initiated reconfiguration) after the initial boot are lost in the recovery process. The recovery action
is defined by setting a combination of bits as defined by the following bit masks (Table 2.12).
Table 2.12 Recovery Action Bit Masks
NOTE 1: Applications exported with these options cannot be loaded over the network.
In the above options, “configuration” does not include the communication parameters since their recovery is
governed separately. Also, fatal application errors refer to application image checksum errors, memory allocation
failures, and memory map failures. Refer to Programming 3150 Chip Memory in the LonBuilder User’s Guide
(Revision 3.0) or to Loading an Application Image in the NodeBuilder User’s Guide (Release 3 Revision 2) for more
information.
The configuration will be rebooted independently of the application only if all the configuration table sizes match
between EEPROM and ROM. This avoids a situation where a new application with different table sizes is loaded
over the network, and a reboot of the configuration corrupts the program.
Recovery Word Description
0x0001 Reboot application if application fatal error.
0x0002 Always reboot application on reset (see NOTE 1).
0x0004 Reboot configuration if configuration checksum fails.
0x0008 Reboot configuration on an application fatal error.
0x0010 Always reboot configuration on reset.
0x0020 Reboot communication parameters if configuration checksum fails.
0x0040 Reboot communication parameters if type or rate mismatch.
0x0080 Always reboot communication parameters on reset.
0x0100 Reboot EEPROM variables when rebooting application.
0x0200 Applicationless state is considered to be an application fatal error. If
option 0x0001 or 0x0008 is set, applicationless state will result in a
reboot. Application fatal errors are defined below (see NOTE 1).
0x0400 Checksum all code, including system image.