Has it partially correct.
Originally, all Connect ME modules were of a -S type, with Digi’s boot loader and post image stored in flash. Late last year we released a next generation version of the ME, which included a new Ethernet PHY and ROHS lead-free compliance. It was with the release of this nex-gen module that a decision was made to split the ME family into the -S (standard) and -C (custom) branches.
The -S modules are primarily intended for use with our Integration kit and Digi’s plug-and-play firmware. IT is also possible, by way of our Legacy Support Kit (LSK) add-in, to use these modules with our NET+Works Development Kit.
The -C modules are intended for use with our NET+Works Development Kit as well as persons wanting to work with other operating systems, ucLinux, VXWorks, etc.
The difference between the -S and -C modules are strictly related to the contents and condition of the flash.
The -S module has its first 128KB of flash protected (this is where the boot loader is stored. This module also requires teh use of our post image (128KB). The remainder of the flash is used for firmware image storage, flash file system, NVRAM and a reserved portion of flash, used by our Boot/Post. There is limited flexibilty in how the flash can be utilized. You are provided no control over the boot and post loader code.
The -C module’s flash is left completely unprotected. The boot loader is a standard image, the source code for which is provided in the development kit. The remainder of the firmware is usagble in a fairly flexible manner.
As for recovery methods the default application (firmware) image implements a FTP server which allows you the abilty to upload a replacement boot loader and/or application image and have it programmed into flash. Other methods of software upload are certainly possible, teh FTP server is the default method which is provided with the development kit.
During the boot process, if the stored application image is found to be corrupted or missing there will be an attempt to enable the Ethernet interface and acquire IP configuration via DHCP. As part of this DHCP offer the boot loader will look for options 66 (Boot Server Host Name)and 67 (BootFile Name). With this information the boot loader will attempt to retrieve, verify, write to flash and execute the specified application image.
With the development kit, since the source code is provided, it is certainly possible to implement additional boot loader features.
- Implement mechanism by which shorting the /INIT pin during boot will cause the boot loader to output an interactive interface by which one could forece the downloading of a replacement application image.
- Modify both the boot loader and BSP to support the storage to two application image in flash, one being a recovery image, using the naftpapp application, the other being the target application. Decision as to when one or the other image is executed could be made automatically via the boot loader, via a user interface or by way of one or more GPIO pins.
I have working implementations of both of the above examples available if anyone is interested. Please send in a request for the source by way of our online support request form at http://www.digi.com/support/eservice/eservicelogin.jsp.
Also, as Erik has stated, without the availability of a JTAG interface the only way to get a new image into flash is by having some mechanism already implemented and available from within flash, i.e. the boot loader of application image needs to have the ability).