With the new wireless bootloader the first challenge was finding a way to move binary code from one node to another by means of standard SWAP packets. The solution was already there, it was just a matter of looking at other file transfer methods as FTP or HTTP. Based on a similar strategy, the node becomes the master in the file transfer by querying (SWAP query packet) the HEX file line by line. Once the node masters this process, it can easily detect CRC errors and query the same line multiple times if necessary. On the other hand, the file server has not to worry about whether a line (SWAP status packet) has been received or not by the node.

The second challenge was making multiple bootloaders (serial and wireless bootloaders) and user application coexist in flash. Depending on project-related preferences, developers may decide to grab the wireless bootloader or not so Arduino 1.5 has to identify this in order to set the correct starting address for the application. Arduino 1.5 fortunately allows creating custom menus so this finally became a minor step in the development process.

Finally, there was the challenge to develop a firmware server. Here the new SWAPdmt command-line tool has played a key role. Once the file transfer process was validated, adding this functionality into SWAPdmt was a matter of developing some lines of code.

The above video shows how a new firmware image (HEX format) is transferred to a battery-powered panStamp NRG from SWAPdmt-cmd. A second terminal running minicom, with a second panStick, is used to monitor the wireless traffic.

Link to the wiki page where SWAP loader is explained.