Echelon LonTal Stack - Manual (Page 122)

110 Developing a LonTalk Stack Device Application
When data that must be stored persistently is updated in RAM, the LonTalk host
stack does not immediately update the corresponding persistent memory.
Instead, the LonTalk host 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 LonTalk host stack supports large configurations.
If the LonTalk host 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
LonTalk host stack is shut down by calling the LonExit() function, the LonTalk
host 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 LonTalk host stack maintains a set of flags (one for each
segment) that survive an unorderly shutdown so that the LonTalk host stack can
detect the unorderly shutdown at the next restart.
The LonTalk host 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 LonTalk Stack device has likely lost updates from a network
manager that it has already acknowledged. If the LonTalk Stack 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 LonTalk host
stack deletes the configuration data, logs a configuration checksum error, and
goes unconfigured. You can restore the configuration by recommissioning 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 you 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 LonTalk host 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 LonTalk host stack was stopped. Typically, this
function returns FALSE, but if the device was reset while a transaction
was in progress, this function returns TRUE and the non-volatile data
segment is considered corrupt, so the restore fails.
2. Calling the LonNvdOpenForRead() callback handler function to open
the segment that corresponds to the specified type.