Echelon FTXL - Manual (Page 206)

194 Downloading an FTXL Application Over the Network
minimum, the FTXL application should reserve enough RAM to buffer two flash
sectors. When one sector has been completely received, the application should
write it to flash in a background process. If the write is not complete when the
second buffer is filled, the FTXL application must tell the application download
utility to delay additional updates until the application is ready to receive the
data.
After the transfer is complete and all data has been written to non-volatile
memory, the application must prepare the image so that the boot loader can
reboot the Nios II processor from the new image. This preparation must be
defined so that a device or processor reset at any point will result in a functioning
FTXL device. For example, the reset could always cause a boot from the old
application image, or from the new application image, or from some temporary
boot application that can complete the transition (possibly with user
intervention).
The Altera tools provide a number of methods to control how memory is
organized and how the system is booted. For information about these methods,
see the
Nios II Software Developer’s Handbook . In particular, refer to the section
on “Memory Usage” within the “Developing Programs using the HAL” chapter,
and the descriptions of the alt_load_section() function within the “HAL API
Reference” appendix.
By using the alt_load_section() function, your application can control how
program data is copied from flash to RAM. Thus, you can, at boot time, decide
whether to boot the old application image or the new one. In preparation for the
boot, your application must direct how the boot should be performed. For
example, your application could include a table at a fixed location that includes
boot parameters, such as the flash locations of the main() function and your reset
vectors. Switching to the new application is accomplished by patching these boot
parameters and then resetting the processor. However, there should be a
fallback if the boot parameters become corrupted, for example, because the device
reset while writing to the sector that contains the boot parameters. This can be
accomplished by maintaining two sets of boot parameters, a primary and backup,
in different flash sectors. The backup is only updated after successfully booting
from the primary.
Another issue to consider is whether the entire image will be loaded or only a
partial image. It is far simpler, and more flexible, if the entire image, including
the FTXL LonTalk protocol stack and the operating system can be replaced.
However, loading the entire image can take several minutes (for example, loading
an application such as the FTXL simple example application could require 10
minutes or longer). Loading only the application portion of the image is possible
if you structure your application very carefully. For example, you might need to
provide patchable linkage stubs that allow your loaded application image to
interact with the pre-loaded FTXL LonTalk protocol stack library and operating
system.