Monthly Archives: September 2015

Smart community update

This map (below) shows all the wireless sensors currently installed in Pruksa Silvana (east Bangalore). This will serve as a test bed for our low power wireless mesh stack. The data from each of these sensors is being sent to our data storage and visualization service (WiSight) running on AWS. I will share the link soon.


Each sensor node is a WSN1101L or WSN1101N interfaced to one or more sensors and/or actuators.

Our aim is to completely blanket this community with the WiSense low power sub-ghz wireless mesh network.

If you have a IOT use case you want to try out in this network, please contact me at  We will help you add your device to this network and monitor/control it on the cloud.

I am going to share pics of each of these nodes in the next post.

Here is one of the nodes controlling a water valve.


Take a look at some of the data collected from this network.


The graph above shows the outdoor temperature over the last five days.


The graph above shows the battery voltage of a solar street light over the past 3.5 days.

Map courtesy google maps.

Over the air firmware upgrade in the WiSense mesh network

In this post, I will be describing the over the air firmware upgrade functionality in the WiSense LPWMN (low power wireless mesh network).


WiSense nodes are based on the TI MSP430G2955 value line micro-controller. This micro has 56 KB of flash and 4 KB of RAM. All the code running on a WiSense node (apart from read only data / initialized data) resides on this on-board FLASH. WiSense nodes also have an 128 KB EEPROM (M24M01) connected to the MSP430 over I2C. This EEPROM is more than enough to hold 2 firmware images (max size 56 KB each). The EEPROM also has a metadata section at offset 0 which contains information on the number of valid images stored in the EEPROM, the length, start address and CRC info of each segment in the stored image. You can get info on the images stored in any node’s EEPROM by reading some FU attributes.


Currently only unicast firmware upgrade is supported. I will be adding support for multicast upgrade soon. In multicast mode, multiple nodes will be able to receive the firmware image simultaneously. In unicast firmware upgrade mode, the external gateway sends the firmware in fixed size chunks to the specified node in the network. Currently the chunk size is fixed at 40 bytes. If the image size is say 50000 bytes, the image will be sent to the specified node in 1250 separate packets each containing one 40 byte page.

Typical firmware image for the MSP430G2955 has 3 or more contiguous segments. Each of these segments has an associated address at which this segment must be written to in the on-board 56 KB FLASH memory of the MSP430. The other attribute is the length of the segment.

Firmware image related attributes are listed below.

  • 16  – Get the flags for each image on the EEPROM. Flags indicate if image is being upgraded or valid and or active.
  • 20  – Get the total length of image 1.
  • 21  – Get the number of segment in image 1
  • 23 – Get the date/time at which image 1 was flashed
  • 40  – Get the total length of image 2.
  • 41  – Get the number of segment in image 2
  • 43  – Get the date/time at which image 2 was flashed

For example see below the attributes retrieved from a node (short address 1246) which has two images in it’s EEPROM. Image 1 is an FFD image of length 46399 bytes across three segments. Image #2 is an RFD image of length 40535 bytes across three segments. The node is currently running image #2 (the RFD image). This means node was running as a reduced function device (RFD) when these commands were executed (on the gateway).

  • pi>> ./gw.exe /dev/ttyUSB0 gav 1246 16
    AttrId<16> AttrVal: 0x3 0x3 0x2 0x0
    Image #1 : Valid   Not Active
    Image #2 : Valid   Active
  • pi>> ./gw.exe /dev/ttyUSB0 gav 1246  20
    Request sent. Waiting for response …..
    AttrId<20> AttrVal<46399>
  • pi>> ./gw.exe /dev/ttyUSB0 gav 1246  21
    Request sent. Waiting for response …..
    AttrId<21> AttrVal<3>pi
  • pi>> ./gw.exe /dev/ttyUSB0 gav 1246  23
    Request sent. Waiting for response …..
    AttrId<23> AttrVal: Thu Sep 3 19:13:26 2015
  • pi>> ./gw.exe /dev/ttyUSB0 gav 1246  40
    Request sent. Waiting for response …..
    AttrId<40> AttrVal<40535>
  • $>> ./gw.exe /dev/ttyUSB0 gav 1246  41
    Request sent. Waiting for response …..
    AttrId<41> AttrVal<3>
  • pi>> ./gw.exe /dev/ttyUSB0 gav 1246  43
    Request sent. Waiting for response …..
    AttrId<43> AttrVal: Thu Sep 3 19:45:41 2015

Firmware upgrade is controlled by a firmware upgrade entity running on the gateway connected to the WiSense LPWMN coordinator node. The gateway can be a laptop, PC or an SBC such as the Raspberry Pi. Let us look at a typical upgrade scenario.

Assume some full function device (FFD) with short address X needs to have it’s firmware updated.

Step 1: Build the new image for the FFD (for example using CCS)

Step 2: Convert the binary image file (.out) to TI-TXT flash image format. This is a text file. If you using CCS, add this line to “post-build steps” box in the “Build window” under project build settings.

“”${CG_TOOL_HEX}” –ti_txt  “${BuildArtifactFileName}” \

-o “${BuildArtifactFileBaseName}.txt”  -order MS -romwidth 16

Step 3: Upload this image file (in TI-TXT format) to the gateway (for example a Raspberry Pi)

Step 3: Run the upgrade application which will read the image and determine the size, location and contents of each of the segments in the image. You also need to specify the short address of the node to be upgraded.

prompt> ./gw.exe  /dev/ttyUSB0  uc_fu  23 ./ffd_image.txt 

In the example shown above, 23 is the short address of the FFD which is to be upgraded. The file containing the new image is “./ffd_image.txt”.

Step 4: The application will send couple of initialization messages to the specified FFD. These two messages will convey the following information.

  • Number of segments in the image
  • For each segment in the image
    • Size of the segment
    • Start/load address of the segment in the MSP430’s on board flash memory
    • Length of the segment in bytes
    • CRC-16 calculated over segment contents.

Step 5: The upgrade app will send each page to the destination node and wait for response from the node. The response will be sent by the upgrade app running on the node. The response will indicate the segment index and the page index of the next segment expected by the app on the node. If the upgrade app on the gateway does not receive the expected response within a fixed time period (say 10 seconds), the gateway app will resend the same packet. The gateway app will retry a fixed number of times before giving up and terminating the upgrade session.

When the upgrade app on the node receives a page packet, it checks the segment index and page index info and if the page is the next expected page, it will write the page to the EEPROM. This app will then read the page back from EEPROM and calculate 16 bit CRC over the contents read back from the EEPROM. It then sends a response message back to the app on the gateway node (through the coordinator node). This message conveys the CRC calculated above and the segment and page index of the next expected message. If the app (on the node) receives the last page of a segment, it will also calculate 16 bit CRC over the contents of the whole segment (stored in the EEPROM). If this CRC does not match the CRC of the segment stored in the metadata portion of the EEPROM, the app will send the next expected page index to 0 expecting to received the complete segment once again. When the gateway app receives a message in response to a prior page frame sent to a node, it will calculate 16 bit CRC over the last sent page and compare it against the CRC sent by the remote node. If CRC matches, the gateway app will then send the next page. If the CRC does not match, the gateway app will resend the same page. The gateway app will resend the same page a fixed number of times before giving up and terminating the upgrade session. On sending the last page of a segment. the gateway app will wait for up to a minute for a response from the remote node so that the remote node has enough time to read the whole segment from EEPROM and calculate the 16 bit CRC over the whole segment.

Step 5: When the app (on the node) verifies the CRC on the last segment, it will immediately start reflashing the MSP430’s on board FLASH memory with the just received image, one segment at a time.

Step 6: The first step in writing the image to the flash is to erase the FLASH blocks which will hold the image. M24M01 block size is 256 bytes. The app will erase all the blocks occupied by one segment and then move to the next segment. The blocks to erase is determined by the start address and length of each segment.

Step 7: The app is now ready to write each segment to the flash. After writing a segment to FLASH, the app will calculate 16 bit CRC on the segment by reading back the contents of the segment (byte by byte) from the FLASH. If the calculated CRC matches the CRC stored in the metadata portion of the EEPROM, the app will move on to write the next segment to FLASH. If a CRC mismatch occurs, the app will start from the beginning by erasing all the required blocks. The app will retry a fixed number of times before giving up (will just blink the LEDS in a fixed pattern to indicate upgrade failure).

Step 8: Once the CRC of the last segment written to the FLASH is verified, the app (on the node) will update the metadata of the new image on the EEPROM to indicate that the image is valid and active. It will mark the other image as inactive.

Step 9: The app will reset the MSP430. The MSP430 will reboot and run the image in the FLASH.

MSP430 FLASH self programming can be done in two ways.We have used the easier “Direct FLASH reprogramming” method in which the code which is reading the image from the EEPROM and writing to the FLASH is itself running in the FLASH. Under this method, when the CPU fetches instructions from flash memory during flash reprogramming, flash returns “3FFFh” (JMP $) to the CPU. This sends the CPU into an endless loop until flash reprogramming has been completed. On completion, flash returns the next instruction and program execution continues. All the “upgrade” code needed to reprogram the flash is loaded at a location in flash which does not overlap with the segments specified in the image file being written to the FLASH memory. This “upgrade only” code is self contained and does not refer to any code or data anywhere else within the FLASH memory. This “upgrade only” code section has the following funtionality:

  • Soft I2C driver needed by the M24M01 driver
  • M24M01 EEPROM driver
  • Code which computes CRC-16
  • Functions for erasing the FLASH and writing to it.
  • Code which reads from EEPROM and writes to  FLASH

WiSense nodes which have two valid images in their EEPROM can also be requested to flash the standby image and reboot. This can be done by sending a message of type “DIS_MSG_TYPE_SWITCH_TO_SBY_IMAGE”.

Full function devices (FFD) have their radio active at all times so it is pretty straightforward to send the complete image to such nodes. Reduced function devices (RFDs) usually stay in low power mode (radio switched off) and only wake up now and then to sense and if required communicate. Upgrading RFDs is not as easy as upgrading FFDs. For now our approach is to load the EEPROM on RFDs with a standby FFD image. To upgrade the RFD, first a command is sent to the RFD to switch to running the FFD image and then send the new RFD image and switch to it after reflashing.


  • slaa103.pdf  – MSP430 Flash Self-Programming Technique