Introduction

Z-Accel is a new packaging of the familiar Z-Stack into a more user-friendly format. If you need to implement a ZigBee solution quickly, Z-Accel could be your most promising alternative.

Objectives

• Look at the Z-Accel architecture
• Learn about Simple API (SAPI)
• Look at Z-Accel solutions
• Do an introductory lab

The greatest hazard in life is to risk nothing. (Dr. Grissom)

Module Topics

• Z-Accel ..... 9-1
• Module Topics. ..... 9-3
• Three Paths to ZigBee ..... 9-5
• Z-Accel ..... 9-6
• Simple API ..... 9-7
• Remote Procedure Calls ..... 9-8
• Architecture ..... 9-9
• App Model and Architecture ..... 9-10
• Profiles and Endpoints. ..... 9-11
• PAN Formation and Discovery ..... 9-12
• Target Hardware ..... 9-13
• Lab9A - Z-Accel Sample Application (ZASA) ..... 9-15
• Hardware list: ..... 9-16
• Software list: ..... 9-16
• Procedure ..... 9-17
• Open the Project ..... 9-17

Do you know who ELI the ICEman is?

Three Paths to ZigBee

The document presents three paths to ZigBee implementation:

• Path 1: Small footprint, High integration, Location Engine optional. Uses CC2430/1 with CC2430/1 development kits.
• Path 2: Flexible, Easy to use, Reduces time to market. Uses CC2480 (ZigBee Processor) with eZ430-RF2480 development kits.
• Path 3: Ultra low power, Well-known radio. Uses MSP430 with CC2420/CC2520 + MSP430ZDK development kits.

Z-Accel is specifically associated with Path 2, utilizing the CC2480-RF2480, MSP430, and CC2480.

Z-Accel

What is Z-Accel and the CC2480?

• Z-Accel is a ZigBee Network Processor that communicates with any MCU via an SPI or UART interface.
• CC2480 is the first-generation ZigBee 2006-compliant network processor in the Z-Accel family.
• Z-Accel allows customers to work with their favorite MCU.
• Z-Accel provides complete ZigBee functionality without having to learn the complexities of a full ZigBee stack.

Z-Accel - Key Features

• Reduce Development Complexity
• Preprogrammed / preconfigured ZigBee Node
• Easy to Deploy
• Accelerate ZigBee Connectivity for existing solutions
• Easily added as a serial peripheral
• Easy to Use
• Split Application and Network processor
• Application Processor running Application Framework & Profile
• Standardized protocol
• Network Infrastructure reused by multiple applications
• Manufacturer Specific Profiles to enable interoperability whenever possible
• Z-Accel supports SimpleAPI
• SimpleAPI has only 10 API calls to learn, which drastically simplifies the development of ZigBee applications.

The architecture involves an Application Microcontroller (e.g., Any MSP430) communicating with a ZigBee Processor (CC2480) via SPI/UART interface. The CC2480 includes the Texas Instruments logo and an antenna.

Simple API

Benefits of using SimpleAPI

• Shorten time from idea to launch
• Shorten learning curve
• No need to read the ZigBee specification (SimpleAPI documentation is less than 30 pages, ZigBee 2006 specification is 534 pages).
• Very little code space needed on the application MCU (small application microcontroller can be used, 4kB+).
• Advanced API can still be used if needed.
• Approximately 90% of all applications can be done with SimpleAPI.

SimpleAPI implements:

• Device configuration
• Commissioning of networks
• Binding of devices
• Sending and receiving data

SimpleAPI Functions and Callbacks

The image depicts a rocket launch, symbolizing progress and the start of something new, with the text "Functions & C" visible.

Remote Procedure Calls

Z-Accel Transport Overview: Remote Procedure Calls (RPC)

CC2480's 10 Simple API calls are abstracted to 4 Physical Transport Layer Command Types:

• AREQ - Asynchronous Request (Callback Events, Function call with a return value)
• POLL - Polling for Data (Retrieve Queued Data)
• SREQ - Synchronous Request (Immediate Response)
• SRSP - Synchronous Response (Response to a SREQ command)

Architecture

The Z-Accel architecture diagram shows a Host processor (MSP430) with HAL and Application layers, interacting with Simple API and ZACC RPC. This communicates via SPI/UART interface to a ZigBee Processor (CC2480) which runs a ZigBee Processor Server, Simple API, Z-Stack API, Z-Stack, and Radio. The diagram also shows the connection between an Application Microcontroller (Ultra-Low Power MCUs MSP430, Texas Instruments) and a ZigBee Processor (CC2480, Texas Instruments) via SPI/UART, with an antenna connected to the CC2480.

App Model and Architecture

The Z-Accel Application Model involves registering your Application Devices and End Points. Devices can act as a Source (Router or End Device) to create periodic sensor reports (Temperature, Battery) or as a Sink (Coordinator) to receive data from bound devices. The diagram illustrates a ZASA (Z-Accel Sample Application) with Source EP and Sink EP, connected via clusters. It shows configuration EP and user-added cluster examples.

The Application Device Architecture shows the Application processor (MSP430) running Sample Application - ZASA, SAPI - Simple API, ZACC (RPC), HAL/BSP, and Physical Layer (SPI/UART). This connects to the ZigBee Processor (CC2480) which handles the ZigBee stack and radio.

Profiles and Endpoints

CC2480 supports Manufacturer Specific Profiles (Private Profile) developed by individual manufacturers. It also supports ZigBee 2006. Devices can join a PRO network as End Devices. A Profile ID must be unique and use a ZigBee Alliance allocated profile identifier. Commercial products developed using this profile must undergo network capable testing.

Endpoints are described as:

• Endpoint 0 (EP0) is the ZDO application running on the CC2480.
• Additional Endpoints run on the application processor (MSP430).

The diagram shows a Sink EP (EP 1) and a Source EP (EP 2) with binding connections. Manufacturer Specific Clusters are shown for both Sink and Source.

PAN Formation and Discovery

PAN Formation (Sink: Coordinator)

The process involves the Application processor (MSP430) running ZASA, using Simple API for App & Start Req and AF Register. Remote Procedure Call (RPC) handles SREQ/SRSP for these. The Network Form is confirmed by an AREQ.

Pan Discovery/Join/Bind (Source: Router or End Device)

The Application processor (MSP430) running ZASA, uses Simple API for App & Start Reg, Start Confirm, Bind Request. RPC handles SREQ/SRSP. The Register Device is confirmed by an AREQ. Bind Confirm is also an AREQ.

Target Hardware

The Z-Accel Lab Target Hardware includes:

• An eZ430-RF2480 Emulator Board.
• MSP430F2274 processor.
• SPI connection to CC2480.
• 2 LEDs (1 red, 1 green).
• 1 Pushbutton.
• Photo-resistor.
• 5 exposed MSP430 GPIO (P2.2 – P2.4, P2.4 & P4.5).

MSP430F2274 features:

• 32K Flash / 1K RAM
• Two 16-bit timers
• USCI Comm Interface
• 10-Bit, 200Ksps ADC
• Two Op-Amps

The image shows the eZ430-RF2480 Target Board and an MSP430 chip.

It's later than we ALL think.

Lab9A - Z-Accel Sample Application (ZASA)

This section details the ZASA project setup and operation.

Project Steps:

• Open ZASA project.
• Update channel and PAN ID parameters.
• Configure, build and load.
• Start PC Demo Application.
• Start Coordinator-Sink, then Router-Source then End Device-Source.
• Observe PAN traffic on Daintree SNA.

A table shows example Channel and PAN ID assignments:

Images show USB dongles and development boards used in the lab.

Hardware list:

• 1 eZ430-RF2480 Emulator Board
• 3 eZ430-RF2480 Target Boards
• 2 Battery Modules
• 4 AA Batteries
• 1 USB Extender cable
• 1 SmartRF04EB board
• 1 CC2430EM board
• 1 antenna

Software list:

• IAR Embedded Workbench for MSP430 version 4.11D
• TI Packet Sniffer version 2.10.1
• Daintree Sensor Network Analyzer version 2.3.0.8
• eZ430-RF2480 Wireless Sensor Monitor version 1.1.4 (swrc096c.zip)
• eZ430-RF2480 ZASA Installer (Rev.B) (swrc097b.zip)
• CC2480 Software Examples (swru169.zip)

Procedure

1. Open the ZASA project

Open C:\Texas Instruments\eZ430-RF2480\ZASA\IAR\SampleApp.ewp with IAR Embedded Workbench.

2. Set your channel and PAN ID

In the App workspace group, open sample_app.cfg for editing and select the channel and PAN ID that your workgroup was assigned. Make sure to only select a single channel.

3. Check the Options

In the options for the project, in the FET Debugger category, make sure that the Connection port is set to Automatic.

4. Build/Download

Connect the eZ430-RF emulator to an open USB port on your PC with the USB extender cable. Connect one of the eZ430-RF2480 target boards to the emulator and build/download the ZASA code to it. Do the same for the other two target boards. Leave the last target board attached to the emulator and connect the other two boards to the battery modules.

5. Operation of the ZASA Code

The ZASA application is comprised of two types of devices, Sources and Sinks, operating in potentially all three ZigBee roles: Coordinator, Router, and End Device. Sources provide temperature and bus voltage readings collected by the MSP430 using its on-chip temperature sensor and ADC converter. The ZASA application provides code for operating as either type of device, and allows for easy configuration via the button on the CC2480 target board.

After power up, the Sample Application (the host) is in the state app/riting, waiting to initialize the CC2480. CC2480 always restores its previous network state from NV memory unless pre-configured not to. This Sample Application does not take advantage of NV restore for predictable behavior. When the CC2480 resets, it sends a SYS API message. The host waits for this indication. Upon receiving it, the host preconfigures CC2480 to not perform NV restore on the next reset and transitions to the appWaiting state. In this state, both LEDs blink at 1-Hz. Connect the power jumpers on both battery modules and click the Go button in IAR Embedded Workbench. The LED on each board should be blinking at 1-Hz.

Device Configuration via Button:

• One momentary button push in a two-second window configures the device as an FFD (Full Function Device - capable of routing).
• Two momentary button pushes in a two-second window configures the device as an RFD (Reduced Function Device - an End Device).

When the two-second window expires, the device is configured and transitions to the appJoining state. An FFD tries to join an existing network as a ZigBee Router for 10 seconds. If it fails, it starts a new network as a ZigBee Coordinator. An RFD tries to join an existing network as a ZigBee End Device for 10 seconds. If it fails, it stops, transitions to appJoinWaiting, and enters low-power for 30 seconds, then tries again. While in appJoining or appJoinWaiting, the LEDs are off.

Coordinator Setup: On the target board attached to the emulator, press the button once. After about 10 seconds, the red LED lights up, indicating the device configured itself as the Coordinator. When an FFD starts a new network as a ZigBee Coordinator, the red LED is solid on, and devices can bind. The state transitions to appRunning with sub-state "allowing joins" (appPermittingF flag). It also maintains a tertiary state, "sinking data" (appSinkingF flag). When a message is acknowledged, the green LED blinks once. The "allowing joining" sub-state can be toggled by a button press. It transitions to "not allowing joining" by clearing appPermittingF, and the red LED blinks at 1-Hz.

Router Setup: Pick one target board attached to a battery module and press the button once. After a moment, the green LED lights up, indicating the device configured itself as a Router. Label this board "Router". When an FFD successfully joins an existing network as a ZigBee Router, its state transitions to appBinding, and the green LED is solid on. The device uses SAPI to negotiate OTA and find the sinking device. It requests a bind from SAPI every 30 seconds until successful. Upon successful binding, the state transitions to appRunning with sub-state "allowing joins" (appPermittingF flag). The "allowing joining" sub-state can be toggled by a button press. It transitions to "not allowing joining" by clearing appPermittingF, and the green LED blinks at 1-Hz. Every 10 seconds, the device sets a tertiary state, "sending data" (appSendingF flag). The device requests acknowledgment of data messages OTA, retrying up to 3 times if SAPI feedback indicates no acknowledgment. When acknowledged or retries expire, the "sending data" sub-state is cleared by clearing the appSendingF flag. When a message is acknowledged, the red LED blinks once.

End Device Setup: On the last target board, press the button twice within a 2-second window to configure it as an End Device. Data transmissions and acknowledgments are indicated by flashing LEDs. Label this board "End Device". When an RFD successfully joins an existing network as a ZigBee End Device, its state transitions to appBinding, and the green LED blinks at 1-Hz. The device uses SAPI to negotiate OTA and find the sinking device. The RFD waits up to 10 seconds for a bind request to succeed, then transitions to appBindingWait and enters low power for 30 seconds. It alternates between binding states and low power every 30 seconds until successful. Upon successful binding, the state transitions to appRunning with sub-state "allowing low power" (appLowPwrF flag). Every 10 seconds, the device sets a tertiary state, "sending data" (appSendingF flag). The device requests acknowledgment of data messages OTA, retrying up to 3 times if SAPI feedback indicates no acknowledgment. While awaiting acknowledgment, the device enters low power and wakes every 2 seconds by a timer to poll for SAPI feedback. When acknowledged or retries expire, the "sending data" sub-state is cleared by clearing the appSendingF flag. When a message is acknowledged, the red LED blinks once.

6. GUI for Sample Application

A PC GUI displays data received by the Coordinator (Z-Accel sink) via a UART connection through the USB port. Stop Debugging in IAR Embedded Workbench and minimize the tool. Power off the Router and End Device boards.

Start the GUI by clicking on the eZ430-RF2480 Sensor Monitor shortcut on your desktop. Cycle power to reset the Coordinator by unplugging/plugging the USB extension cable attached to the emulator/target board. After a moment, the "SINK RX" bubble in the GUI should turn red, indicating connection and data reading. Press the button on the target board once to configure the board as a Coordinator-Sink. After about 10 seconds, the red LED on the board will light.

Connect power for the Router, and then press the target button once to configure the device as a Router-Source. A blue bubble should appear on the PC GUI with data inside. The bubble flashes each time a data packet is received. Inside the bubble, you will see:

• The temperature reported by the device's MSP430 internal temperature sensor (may be incorrect, not calibrated).
• The short address of the ZigBee device (should be 0x0001 for the first Router joining the Coordinator).
• The time that the last data was received (PC time).
• The battery voltage of the device.

Connect power for the End Device, and then press the target button twice within 2 seconds to configure the device as an End Device-Source. After a few seconds, the LEDs will flash occasionally, indicating data transmission and acknowledgment. A green-ish bubble should appear on the PC GUI with data inside, flashing each time a data packet is received. Note the data inside the bubble.

Close the Sensor Monitor GUI and power off all three Z-Accel boards.

7. Run the Packet Sniffer

Turn on your sniffer board, ensuring it's connected to the PC's USB port. Start the Daintree Sensor Network Analyzer. Select your source and your workgroup's channel before clicking the Start Capture button.

Observe the action on the SNA as you follow the steps below. Ensure the packets make sense in terms of expected ZigBee network activity:

• Power on the Coordinator board and press the target button once.
• Power on the Router and press the target button once.
• Power on the End Device and press the target button twice within 2 seconds.

8. Power down

Close Daintree SNA and IAR Embedded Workbench. Power all the boards down.

STOP You're done.