rfWsnNodeIntFlashOadClient Example

Example Summary

The WSN Node example illustrates how to create a Wireless Sensor Network Node device which sends packets to a concentrator. This example is meant to be used together with the WSN Concentrator example to form a one- to-many network where the nodes send messages to the concentrator.

This examples showcases the use of several Tasks, Semaphores and Events to get sensor updates and send packets with acknowledgement from the concentrator. For the radio layer, this example uses the EasyLink API which provides an easy-to-use API for the most frequently used radio operations.

Peripherals Exercised

Resources & Jumper Settings

If you’re using an IDE (such as CCS or IAR), please refer to Board.html in your project directory for resources used and board-specific jumper settings. Otherwise, you can find Board.html in the directory <SDK_INSTALL_DIR>/source/ti/boards/<BOARD>.

Example Usage

The example also support Over The Air Update (OAD), where new FW can be loaded over OAD. The must be an OAD Server, which is included in the concentrator, and an OAD client which is included in the sensor.

Using the on-chip OAD example

To be safe the external flash of the Concentrator should be wiped before running the example. To do this, program both LP boards with erase_extflash_cc13x0lp.hex. The program will flash the LED’s while erasing and once finished the LED’s will stop flashing. Allow the application to run until the external flash has been erased and the LED’s stop flashing.

The wipe flash FW can be found in below location and should be downloaded with Uniflash programmer: <SDK_DIR>/hexfiles/offChipOad/ccs/erase_extflash_cc13x0lp.hex

In addition, the internal flash of the node should be wiped. This can be done through the Settings and Utilities tab in Uniflash.

The Concetrator OAD Server and Node OAD Client FW must then be loaded in to the LP’s using the Uniflash programmer:

The Concetrator will display the below on the UART terminal:

Nodes   Value   SW    RSSI
 0x0b    0887    0    -080
 0xdb    1036    0    -079
 0x91    0940    0    -079
*Action: Update available FW
Info: Available FW unknown
cmd:

The node OAD image can be loaded into the external flash of the Concentrator over the UART with the oad_write_bin.py script. The action must first be selected using BTN-2. Press BTN-2 until the Action is set to Update available FW, then Press BTN-1 and Press BTN-2 to execute the action.

When “Available FW” is selected and BTN-2 is pressed the terminal will display:

    Waiting for Node FW update...

The UART terminal must first be closed to free the com port. Then the python script run:

    python ../../../../../../tools/easylink/oad/oad_write_bin.py /dev/ttyS28 <SDK_DIR>\examples\rtos\CC1310_LAUNCHXL\easylink\hexfiles\oad\rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v2.bin

After the download the UART terminal can be re-opened and the “Available FW” will be updated to reflect the new FW.

The current FW version running on the node can be requested using the Send FW Ver Req action. This is done by pressing BTN-1 until Action is selected. Then press BTN-2 until the Action is set to Update available FW, The Press BTN-1 until intended device is selected. Press BTN-2 to execture the action.

The next time the node sends data it will respond and the FW version will be displayed:

Nodes   Value   SW    RSSI
 0x0b    0887    0    -080
 0xdb    1036    0    -079
*0x91    0940    0    -079
 Action: Update available FW
Info: Node 0x91 FW v1.0

The FW running on the nodes can now be updated to the available fw on the concentrator. The Action must first be selected using BTN-1. The Press BTN-2 until the Action is set to Update node FW, and Press BTN-1 until the intended device is selected. Press BTN-2 to execture the action.

The next time the node sends data it will respond and the FW update request and start requesting OAD blocks, which will be displayed:

Nodes   Value   SW    RSSI
 0x0b    0887    0    -080
 0xdb    1036    0    -079
*0x91    0940    0    -079
 Action: Update available FW
Info: OAD Block 14 of 1089

Once the OAD has completed the node will reset (if not yo may need to do a manual reset).

Building an OAD hex

For generating the images the following tools are required:

The following steps talk through how to use CCS or IAR to create an OAD hex file which can be used to create the OAD biniaries as described in previous sections

Building the hex file in CCS

  1. Import the CCS porject into CCS(for more information conslt the Examples Users Guide in the proprietary-rf documentation)
  2. If this is for an OAD image (not an image to be flashed), then exclude the ccfg.c file from the project.
  3. Add FEATURE_OAD_ONCHIP and HAL_IMAGE_A or HAL_IMAGE_B to the predefined Symbols in Project->Properties Arm Compiler / Predefined Symbols tab (for Image B the TIRTOS config file must also be changed, see below).
  4. Add FEATURE_OAD_ONCHIP=1 and HAL_IMAGE_A=1 or HAL_IMAGE_B=1 to the Linker symbol definition in Project->Properties ARM Linker->Advanced Options / Command File Preprocessing tab (for Image B the TIRTOS config file must also be changed, see below).
  5. Enable hex file conversion in Project->Properties Arm Hex Utility
  6. Set memory width to 8 in General options
  7. Set output format to intel hex.
  8. Make a code change update the nodeFwVersion string in NodeTask.c
  9. build

Building the hex file in IAR

  1. Create new workspace
  2. Import Custom argument variables (Tools->Configure custom argument variable) from /tools/iar/
  3. Save the workspace in some directory other than the SDK
  4. Close and re-open the workspace
  5. Add the TIRTOS Kernel project (Project-> Add existing project) from kernel/tirtos/builds//release/iar
  6. Build the Kernel
  7. Create a new project
  8. Add the ipcf file (Project-> Add project connection) from /examples/rtos//easylink//tirtos/iar/
  9. If this is for an OAD image (not a production image to be flashed), then exclude the ccfg.c file from the project.
  10. Add FEATURE_OAD_ONCHIP and HAL_IMAGE_A or HAL_IMAGE_B to the predefined Symbols in Project->Properties Arm Compiler / Predefined Symbols tab (for Image B the TIRTOS config file must also be changed, see below).
  11. Add FEATURE_OAD_ONCHIP=1 and HAL_IMAGE_A=1 or HAL_IMAGE_B=1 to the Linker symbol definition in Project->Properties Linker / Config tab symbols definitions (for Image B the TIRTOS config file must also be changed, see below).
  12. Enable hex file conversion in Project-> Options, Output converter tab. Check the “Generate additional output” checkbox and set output format to “Intel extended Hex”
  13. Make a code change update the nodeFwVersion string in NodeTask.c
  14. build

Generating OAD images

To build a project for On-Chip OAD, the following settings must be configured depending on Image A or B:

The following symbols must be defined for the compiler and linker: FEATURE_OAD_ONCHIP HAL_IMAGE_A or HAL_IMAGE_B

In release_oad.cfg, the reset vector addresses for TIRTOS must be configured: /*

// Image B Reset Vector Address //m3Hwi.resetVectorAddress = 0x10010;

Comment out the appropriate resetVectorAddress for the image you are not building.

The prebuilt BIM binary is generated from the BLE SDK projects: <SDK_DIR>\examples\rtos\CC1350_LAUNCHXL\easylink\hexfiles\onChipOad\ccs\bim_intflash_cc1350lp.hex

An OAD image can then be created from the application image with the oad_image_tool_13x0.py:

python oad_image_tool_13x0.py -t onchip -i app -v 0x0100 -m 0x1000 -ob rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v1.bin rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v1.hex

The following command-line arguments can be must be used to build the image: -t onchip -i app -m 0x1000 (for image A) or -m 0x10000 (for image B) -v Where major version (XX) and minor version (YY) must be of the format 0xXXYY, for example 2.3 would be 0x0203.

Creating the OAD Binary:

An example of building a binary for each case is shown below. If you are directly flashing the image to the device with the BIM, please see the next section. OAD Image A:

python oad_image_tool_13x0.py -t onchip -i app -v 0x0100 -m 0x1000 -ob rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v1.bin rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v1.hex

OAD Image B:

python oad_image_tool_13x0.py -t onchip -i app -v 0x0200 -m 0x10000 -ob rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v2.bin rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v2.hex

Flashing an OAD binary:

The Image A OAD binary is the merged with the BIM hex:

python /usr/bin/hexmerge.py -o rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_all_v1.hex "--overlap=error" rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_app_v1.bin bim_intflash_cc1350lp.hex

To flash an image to the device with the On-Chip BIM, you must first create an Image A production OAD binary of the image. This is required since the BIM verifies the CRC value of any image before it is executed.

python oad_image_tool_13x0.py -t onchip -i production -v 0x0100 -m 0x1000 -ob rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_all_v1.bin rfWsnNodeIntFlashOadClient_CC1310_LAUNCHXL_all_v1.hex

The BIM uses a CRC check to validate any image before it is executed, so it must have an OAD header. Because the BIM is merged with the initial application image, the ‘production’ image type must be used when building the OAD binary.

Application Design Details

RadioProtocol.h can also be used to change the PHY settings to be either the default IEEE 802.15.4g 50kbit, Long Range Mode or custom settings. In the case of custom settings, the smartrf_settings.c file is used. This can be changed either by exporting from Smart RF Studio or directly in the file.

References