Debugging ZigBee ApplicationsJune 1, 2006 By: Andy Wheeler, Ember Corp. Sensors
Traditional debugging techniques can't handle the inherent complexity of wireless sensor networks. New tools are evolving to address these unique challenges.
Combining low-cost, spread-spectrum radios with multihop networking, ZigBee addresses a broad set of embedded network applications for home automation, building controls, medical monitoring, industrial automation, automatic meter reading, asset management, homeland security, and other services. Many applications currently being ZigBee-enabled already exist in other forms, often using wired networks or no networking at all.
ZigBee applications are typically built on resource-constrained 8- or 16-bit microcontrollers, with the networking stack and application often sharing the same processor. While developing a ZigBee-enabled thermostat appears to pose debugging challenges similar to those faced when developing a standard microcontroller-based thermostat, sharing the processor between an application and a network stack and the inherent nondeterminism of wireless networking complicate matters. As ZigBee systems grow in size, from a single thermostat to a complete building HVAC system, the applications become more distributed, involving many processors and communications links. This more complicated picture requires a new class of debugging tools. This article surveys traditional embedded application debugging techniques, explores how they apply to ZigBee development, and examines the tools that are emerging to address the situations where they fail.
Debugging a Digital Thermostat
A digital thermostat serves as a good example of how, using traditional debugging techniques, a basic component can be converted to become part of a larger ZigBee system. It also shows where the techniques must be supplemented or replaced.
A typical microcontroller unit (MCU)-based thermostat has an 8-bit MCU with a temperature sensor, an LCD, and some I/O for buttons and the heater control. Once application code is written, a developer typically enters a debugging cycle (Figure 1) that steps through code augmentation/change, reprogramming, and observation. Code augmentation provides better visibility into what is happening in the device. The developer may toggle spare pins to view the program's behavior on a logic analyzer, or else use a spare serial port to print debugging statements. Most modern MCUs also support some sort of in-circuit debugging capability through a JTAG or proprietary interface to allow you to halt and step the processor along and view the contents of memory and registers. These in-circuit debuggers provide a user interface through a PC-based debugging tool.
Figure 1. Typical debugging cycle
A simple ZigBee/wireless version of the same thermostat might separate the temperature sensor component from the controller MCU and allow multiple temperature sensors to communicate to a single controller, perhaps to enable a multizone system. Because each of the remote sensors contains an MCU to drive the radio, the developer is faced with several more MCUs than were present before. The extra components make isolating problems more difficult. For instance, a typical ZigBee device contains a vendor-provided ZigBee stack that interfaces with the radio and shares the MCU's resources with the application code. If a temperature reading fails to appear at the controller, the fault could have occurred at one of many stages: the sensor's application code, the sensor's ZigBee stack, the radio link or network, the controller's ZigBee stack, or the controller's application. The developer requires some level of visibility into the RF communications of the system in order to isolate faults (Figure 2).
Figure 2. Potential fault errors in ZigBee thermostat system are shown in red
Most Read Articles