TinyOS sports a tool called Deluge for handling network wide reprogramming of motes using the radio. Certain core components of this tool have been adapted for use in a Blip network. In Blip it's called NWProg.
The basic flow of using NWProg is this:
Quick start: Add this to the Makefile of the TinyOS app:
And create a file in the app directory for the flash chip you are using. With
epic this called
volumes-at45db.xml and contains:
<volume_table> <volume name="GOLDENIMAGE" size="65536" base="0" /> <volume name="DELUGE1" size="65536"/> <volume name="DELUGE2" size="65536"/> <volume name="DELUGE3" size="65536"/> </volume_table>
You also need to compile
$ cd $TOSROOT/tos/lib/tosboot $ make epic
Install the app like normal
$ make epic blip install bsl,/dev/ttyUSB0
You should see it do two installations, one for TOSBoot and one for your app.
Use the python script
tos-nwprog located in
$ make epic blip $ cd build/epic $ tos-nwprog -u <image number> -f tos_image.xml <ip address>
$ nc6 -u <ip address> 2000 nwprog list nwprog boot <image number> <millisecond delay until reprogramming>
Things get more complicated if you have defined a new TinyOS platform for the board you are using. There are many places in the NWProg/Deluge/TOSBoot stack where there are custom defined settings for all of the given supported platforms. For some reason the platform specifics are not in
tos/platforms but in each library folder.
support/sdk/make/tosboot.extrafor your platform.
tos/lib/net/Deluge/extrafor your platform.
Using Blip2 + RPL + NWProg creates rather large application binaries. I found these to be too large to allow me to run an actually interesting application on top of the networking stack. To work around this I came up with the following solution:
NWProgLite is similar to NWProg in Blip except all it allows you to do is restart the app and flash into the golden image. This way you can compile your application with NWProgLite and only add 500 bytes to the code size (4KB if you do not have the shell included already).
To make any Blip enabled app compatible compile with:
$ make epic blip nwproglite
This TinyOS app is basically the simplest app possible that includes Blip, RPL, and NWProg. It doesn't do anything except become a node in the network. When the node is running this app, it can flash either of the flash partitions with a new image. Then, you can boot into the new application.
BlipNWProgBaseon all the nodes in the network.
BlipNWProgBaseinto volume 0 on every node
nwproglitecompiled app you want into volume 1 of every node
$ nc6 -u <ipaddress> 2000 nwprog boot 1
To load a different app:
$ nc6 -u <ip address> 2000 nwprog reset
$ nc6 -u <ipaddress> 2000 nwprog boot 1
In order to do the large code size trick, BlipNWProgBase needs to be in volume 0. Getting it there can be a pain using over the air programing. To avoid this, we can use some Deluge machinery to program the volumes while they are connected locally.
$ cd $TOSROOT/apps/tests/deluge/basestation $ make hemera install bsl,/dev/ttyUSB0 $ cd $TOSROOT/apps/BlipNWProgBase $ tos-deluge serial@/dev/ttyUSB0:115200 -i 0 build/hemera/tos_image.xml $ make hemera blip install bsl,/dev/ttyUSB0
It should be noted that I attempted to merge the serial connection loading functionality of the Deluge basestation with
BlipNWProgBase, but I couldn't get it to fit on an MSP430F1611.
To reduce the amount of data that needs to be transferred over the network, I'm working on a method that only transmits blocks that are different from the current stored block.
This works by asking for hashes of 32 64-byte blocks. Then the local script only sends the blocks that are different. Repeat.
It is possible to load an image of an app that does not have NWProg included (something like
Blink). The procedure is the same with one change: you must specify where the app should reside in flash manually since
tosboot.extra will not automatically do it. To do this, add this line to the application makefile.
CFLAGS += -Wl,--section-start=.text=0x4a00
Make sure that the code was set to the correct address, see note above.
After every chuck of data sent by
tos-nwprog, the node sends back 6 bytes confirming it was able to store the data.