Software Update via Ethernet - the mbed application can pull down an updated application binary from a web server and activate that binary. This library works only with the LPC1768, as it relies on the magic-chip boot-loader mechanism.

Dependents:   WattEye X10Svr PUB_SWUpdate

Success!! With this library, a network connection, and a web server hosting a new binary image, you can update the mbed firmware over the air (FOTA) - well, at least via Ethernet so far.

As of March 2015, it has been tested with the following mbed official libraries:

And a custom derivation:

  • HTTPClient v33, v32, which includes a custom HTTPFile.

Part of the update process involves checking the integrity of the downloaded binary file, for both a checksum and the program (file) size. To create this additional information, a small perl script is used (the important part is only 20 lines of code). See the documentation in the header file.

After the new binary is successfully downloaded, the checksum and the size are evaluated and if correct, then the old binary file is removed (this is the only way to cause the new binary to activate).

The mbed can then be automatically reset to activate the new image, or this may be deferred in case there is some other process necessary for an orderly restart.

Details are in the SWUpdate header file, and PUB_SWUpdate is a publicly accessible demonstration program for this library.

Revision:
14:0e012d53c6df
Parent:
13:cf76c2bd3dfc
Child:
15:49cc43dcbbf6
--- a/SWUpdate.h	Sat Jun 21 19:39:27 2014 +0000
+++ b/SWUpdate.h	Fri Jun 27 20:57:23 2014 +0000
@@ -13,11 +13,17 @@
 /// Your application will have a name of your choosing, which you will 
 /// use in the API.
 ///
+/// @note Your binary file name should not exceed 6 characters. This leaves
+///     room for a 2-digit sequence number. Since this is using the local
+///     file system, it does not support long filenames when accessed from
+///     the mbed. So, SomeLongFile23.bin becomes somefi~1.bin and is then 
+///     erased, leaving no file.
+///
 /// Local File System Files:
 ///
 /// The files of interest on the local file system are as follows:
 ///
-///   @li myprog_23.bin - The actual application binary file that is currently
+///   @li myprog23.bin - The actual application binary file that is currently
 ///             executing. In this case, this is the 23rd version that
 ///             has been installed. You can go to 99 after which you might
 ///             want to start over.
@@ -27,7 +33,7 @@
 ///
 /// If "myprog.ver" does not exist, it will assume that the server has a 
 /// newer application, so it will be downloaded and activated (even if all
-/// it does is to replace the existing myprog_23.bin file).
+/// it does is to replace the existing myprog23.bin file).
 ///
 /// Web Server Files:
 ///
@@ -53,9 +59,9 @@
 /// Variations:
 ///
 ///   Within that single web server folder, you could have several apps - 
-///     @li SensorNode.bin, SensorNode.txt
-///     @li SensorNode_B.bin, SensorNode_B.txt
-///     @li SensorDisplay.bin, SensorDisplay.txt
+///     @li Sensor.bin, Sensor.txt
+///     @li SensrB.bin, SensrB.txt
+///     @li SensrD.bin, SensrD.txt
 ///
 ///   In this example, perhaps your first version was called SensorNode, but
 ///   with a small hardware design change, you have a new "model B" version.
@@ -96,8 +102,8 @@
 
 // This defines the maximum string length for a fully qualified
 // filename. Usually, this will be pretty short 
-// (e.g. "/local/myprogramname.bin"), but we want to be generous.
-#define SW_MAX_FQFN 80
+// (e.g. "/local/myprog.bin"), but we want to be generous.
+#define SW_MAX_FQFN 30
 
 // This defines the maximum string length for the url, including
 // the base filename of interest.