Probably one of the biggest cost savers to today's commercial and industrial business owners is productivity. With tough fiscal times staring them in the face, these companies need to increase the productivity of their employees in order to reduce things like costly truck rolls, operator down time, and more.
To answer this concern, system designers are turning to embedded solutions to bring Ethernet and Internet connectivity to traditionally non-connected devices. While this provides a clear set of benefits to the end user, it also provides a host of challenges to the system designer.
Upgrading with FTP
When building remote connectivity into a system design, designers are faced with several protocols to choose from. However, the two most common are the FTP and HTTP.
Of these two options, FTP boasts the highest efficiency for handling remote connectivity (see Figure 1). In the implementation illustrated in Figure 1, an FTP client or server, depending on how the system has been designed, requests a file upload. If the user is simply browsing the file system, no action can take place, but once the user is validated, the client or server has access to the device's file system. If the user wants to put into or get a file from the system, a routine can be called. In the case of a new binary image, a flash memory programmer routine can be spawned, and the device updated.
If the binary image is not new, the process is a conventional FTP file access. This type of check is important, as it protects against unwanted field upgrades. This can be a limitation depending on the design, since the end user will need to know the exact filename before performing a software upgrade.
Of course, inconsistencies during flash memory programming can also cause huge headaches for designers employing FTP. However, this can easily be solved using straightforward error checking techniques.
The HTTP approach
While FTP may be the most efficient method for handling system software updates, it may not be the most user friendly. That's a distinction that gets handed off to HTTP.
The HTTP method allows a user to browse the device and pass new binary images through what is referred to as a form (see Figure 2). A form allows data to be transferred to a server (in this case, the actual embedded device) for processing.
At another level, forms allow for device manipulation, such as hardware configuration and hardware system status, such as lights, sensors, or the executable image residing in flash memory. HTTP requires that design engineers have a bit more understanding about application design, especially with regard to Web pages.
In direct socket connection, HTTP is a user-implemented file transfer methodology that employs standard TCP/IP in sockets. Field upgrade is usually not performed with the FTP or the web interface. Special software must be written at both the host and device level in order for this method to be used, rather than the often built-in FTP and HTTP browsers and servers. User-friendliness in the field in this case depends on the software written for the host PC.
Spawning the servers
When bringing remote connectivity to a system architecture, embedded FTP and HTTP servers are typically spawned from applications with one call each. In addition to spawning servers, callback routines must be set up so the device can respond to specific requests made by the client.
For example, an FTP server must know what to do when a put command is issued. If the web server is going to be used to upgrade a device, the embedded web server must be spawned so that it will be listening for requests from a browser.
The same is true for an FTP server awaiting a request from an FTP client. Callback routines, directing the application to respond properly to a given action, must also be registered. For FTP implementation, when a file is put to the system, the application must know where the file will go, and in the case of a special filename (such as a new binary image) the application code must know what routine (such as a flash programmer routine) to call to reprogram the flash memory device.
Board support packages
A board support package (BSP) enables the programming of flash memory while the board is intiated with the implemented application. Most BSPs contain firmware and software for components on the development or target board. A BSP should include the set-up routines and low-level drivers responsible for communicating with the subsystems, such as flash or other memory components.
The flash memory drivers are implemented so that the sector sizes and flash memory architecture are known. This allows the software designer to implement high-level software for programming the flash memory with application program interfaces (APIs). The APIs will then speak to the flash memory at the low level.
This BSP describes low-level device initialization. Most integrated processors include what is termed the memory controller. The memory controller is responsible for speaking to memory components, such as flash memory, SDRAM, or other types of memory on the system. The flash memory components typically need special software routines to communicate with the memory controller.
Writes to flash memory require special software command codes, while reads resemble a typical SRAM device. To accurately program a device, the BSP must be aware of the actual hardware in the system. API support must also exist for the flash memory being populated on the board, as well as the flash memory command codes themselves.
Backing up the flash
It's important to note that a system design featuring a bad or corrupt flash memory is useless in the field, resulting in a non-functional device. Thus, the use of redundant flash memory devices helps alleviate some of this risk. Device restoration can be accomplished with a single switch between flash memory devices that are located on the board, while the use of boot flash memory allows for a board to always get into a start-up state.
Boot flash memory can perform checksums on the program flash memory to determine if it is corrupt. If it is, measures can be taken to get the board functional again. These measures can can range from getting a new flash memory image from the network to performing a system-level memory test to see if there's a hardware failure, illustrating the value of network connectivity. Boot flash memory can also be used to initiate an image download directly into the RAM on the device upon start-up.
Use of non-volatile RAM devices allows for multiple devices to receive the same upgrades without the worry of overriding critical board parameters in the flash memory. The new flash image will contain information that tells the device how to boot based on parameters stored in the RAM devices.
RAM execution is critical to field upgradability. System designs must execute programmer functions from RAM or another flash device in order to write to the primary program flash memory. In case of an all-out failure, some method of visibility and control into the system is required to initialize the device. Processor type will influence the methodology, but it typically entails a background debug module, such as a JTAG debugger.
Initial hardware designs must also take into consideration that programs might get quite large over time. Algorithms and OSes can change. New protocols and features, such as new graphics or sound, may be added. Planning ahead for footprint limitations will help to preserve the design integrity of the desired hardware architecture.
Flash programming routines can be called to actually re-burn the flash memory device on the board. What usually happens after the upload is that a reset will occur so that the new image with the updated software will take effect. Otherwise, the file can consist of a data log or new hardware configuration. Provisions, such as file name comparisons, key words, or web page options, can be used to initiate the new burning of the flash devices.
Regarding the process of flash memory upgrading itself, remember that the RAM contains the stack, the heap, and the instruction area. The heap is where all the dynamic data is stored. The difference between step one and step two involves the file being uploaded from a client or server located somewhere on the network. When there is some downtime, a new image file can be programmed somewhere into flash memory. Before the file is updated through the device, it is typically padded to make sure it accurately fits into the given flash memory device, and this helps with the design of the flash memory programmer APIs.
An important note is that the new image file must fit inside the heap. Enough room has to be left for other dynamic data, as well as a completely new image. This buffering in the image allows for a critical thread in the application to complete before resources are allocated for device initialization.
Another key way to improve overall flash memory performance is to build in a memory jump routine into the application code. Typically, after reset, a minimal boot-up configuration will execute from flash memory. This contains memory region mapping, general ASIC register configuration, and some board-level testing, if desired. After this configuration is complete, the device will have the ability to either copy an image from ROM to RAM, then jump to execute, or it could download an image from a server on a network directly into RAM and begin execution. In either case, a function can be called that is located at the start of the RAM image. This will start the execution from the RAM device, thereby enabling the flash memory device to be updated on the board.
Designers looking to add remote connectivity should also review the implementation procedures for the flash memory update. After power-on or reset, designers typically can boot from flash memory, and will most likely require some low-level initialization routines to get the ASIC, processor, or system in a known state.
Next, the image is copied from ROM to RAM, then jumped to start execution. FTP or HTTP servers or clients on the device itself can be spawned, and if a request is made from a client for a field upgrade, the downloaded file can be passed through the device and the new image stored in the device itself. A reset will follow immediately, allowing the benefit of working with the latest software upgrade.
Whenever possible, design for a flexible memory architecture, such as leaving enough room in RAM for new ROM images (even though the entire heap could be used if the device will be reset after programming) and padding out the board for larger density hook-ups. Only use flash memory for critical parameter storage if you have written excellent flash memory management APIs. The worst thing that could happen is to inadvertently overwrite or erase parameters, such as a device MAC address or IP configuration parameters.
William Dowell is the field application engineer manager for NetSilicon. He holds a BSEE from Worcester Polytechnic Institute with an emphasis on communications and systems design. He can be contacted at email@example.com.