Echelon FTXL - Manual (Page 90)

78 Developing an FTXL Application
current application. The header also includes a checksum to ensure that the data
is free of errors. If any of these validations fails, the FTXL LonTalk protocol
stack deletes all non-volatile data in the segment and sets the device to the
unconfigured state.
When data that must be stored persistently is updated in RAM, the FTXL
LonTalk protocol stack does not immediately update the corresponding persistent
memory. Instead, the FTXL LonTalk protocol stack defers writing the data to
persistent memory so that it can continue to respond to network management
commands in a timely fashion. The reasons for deferred writing of persistent
memory include:
• Flash sectors sizes tend to be large and can take a long time to write.
• Each network management update generally affects only a small amount
of data, and typically, a single logical operation consists of many
messages (commissioning of the device generally being the most common
and most extensive).
• The FTXL LonTalk protocol stack supports large configurations.
If the FTXL LonTalk protocol stack has not received any updates to a particular
segment for a short (configurable) time (for example, 1 second), it uses the
application callback handler functions to write the data to persistent memory. If
the FTXL LonTalk protocol stack is shut down by calling the LonExit() function,
the FTXL LonTalk protocol stack completes the write process before returning
from the function. However, a sudden power outage or an unexpected CPU reset
can prevent an orderly shutdown. The FTXL LonTalk protocol stack maintains a
set of flags (one for each segment) that survive an unorderly shutdown so that
the FTXL LonTalk protocol stack can detect the unorderly shutdown at the next
restart.
The FTXL LonTalk protocol stack checks the flag, by calling the
LonNvdIsInTransaction() callback handler function, during device startup before
it reads the non-volatile data. If the flag is set, integrity of the non-volatile data
has been compromised. Even if the configuration is internally consistent, the
FTXL device has likely lost updates from a network manager that it has already
acknowleged. If the FTXL device reverted to the last known configuration, this
inconsistency would likely be undetected and could result in errors that are
difficult to isolate. Instead, the FTXL LonTalk protocol stack deletes the
configuration data, logs a configuration checksum error, and goes unconfigured.
You can restore the configuration by recommissiong the device from network
management tool.
If you use either of the standard non-volatile drivers, you can enable tracing by
setting the global variable nvdTraceEnabled to a non-zero value. If create your
own custom non-volatile data driver, be sure to add some tracing capability to it.
Restoring Non-Volatile Data
During device startup, the FTXL LonTalk protocol stack reads the non-volatile
data for each segment and initializes the corresponding data structures stored in
RAM by performing the following steps:
1. Calling the LonNvdIsInTransaction() callback handler function. The
application returns whether an NVD transaction for this segment was in
progress when the FTXL LonTalk protocol stack was stopped. Typically,