
**************************************************************************

        Firmware Revision History - XBee/XBee-PRO Smart Energy Generic Module Radio Modems

**************************************************************************

** XBee-SE Firmware Overview **

The XBee-SE firmware is based off the EmberZNet 3.4.0 (beta 1) ZigBee-PRO stack.  

XBee-SE firmware uses the AT commands and API frames of XBee-ZB firmware, with some minor differences in default values and ranges.

** XBee-SE Firmware Versions **

XBee version numbers will have 4 significant digits. A version number is reported by issuing an 
ATVR command.  The response returns 3 or 4 numbers. All numbers are hexadecimal and can have a 
range from 0-0xF. A version is reported as "ABCD". Digits ABC are the main release number and D 
is the revision number from the main release. "B" is a variant designator. The following 
variants exist in ZB firmware:

•	“1" - Coordinator, API Mode (AP=1,2) 
•	“3" - Router API Mode (AP=1,2) 

All releases will have an even number for C. All internal development will have an odd number 
for C. Field D is always present, even when D is 0. 


** Released Versions **

Released ZigBee firmware versions are available from the X-CTU program for download.  
To download released versions:

1.  Go to the ‘Modem Configuration’ page in X-CTU.
2.  Click on ‘Download New Versions’ and select ‘Web’.
3.  You may need to disable your firewall in order to download new versions.

**************************************************************************
*                       Version 3x32 Release Notes                       *
**************************************************************************
Release Date: March 19, 2012
EmberZNet  Release: v3.5.1 stack

Fixed flash corruption issue triggered by sending a packet to a device that had left the network. 

Increased API command buffer size to correctly handle an ATZU API command response.

Addressed APS extended retry timeout issue when sending fragmented packets causing a device to lockup.
  


**************************************************************************
*                       Version 3x30 Release Notes                       *
**************************************************************************
Release Date: June 16, 2011
EmberZNet  Release: v3.5.0 stack

Default value for SN was extended from 0x01 to 0xF0 to increase the time tolerance for a parent to wait for sleeping end devices to poll before timing out and forcing the child off the network.

Issues which were causing some Tx Status 0x32 (no resources) messages have been addressed.

Recent changes to the SE 1.1 certification test suite concerning Key Establishment error and termination handling have been addressed.

A problem where partner link key exchange was failing due to reversed endpoints in the response message has been fixed.

CB1 is disabled while Authentication is in progress.

**************************************************************************
*                       Version 3x28 Release Notes                       *
**************************************************************************
Release Date: February 24, 2011
EmberZNEt  Release: v3.5.0 stack

TX Status message will sometimes show a 16 bit address other than 0xFFFE.

A router/end device's link key table will be reset when a joined device leaves a network.

The configured value of KY will be preserved even if a RE command is given.

SC mask range is increased to 0xFFFF to support use of Channel 26 on the XBee Pro Plus.
The default value remains 0x7FFF.
However, if Channel 26 (0x8000) is present in the SC mask, then transmit power
for all channels is capped at 3 dBm.

ZU (Certificate public key) is now read/write.

Setting AO to 0x07 enables passthru for all ZDO traffic, whether supported or unsupported by the stack.

New DO (Device Options) command has been added to control a bitmask of options.

DO bit 0x01 enables the temperature compensation option on the XBee S2B.
By default it is enabled.  This option appears in all SE and ZB builds for the XBee S2B.
Disabling Temperature Compensation reduces wake time overhead for sleeping end devices from 13 ms to 2 ms,
but then transmit power may vary by as much as 8 dBm as a function of temperature.

DO bit 0x02 enables the join notification message option on the SE Coordinator.
By default it is disabled.  This option appears in the SE Coordinator builds.
The other 6 bits of DO are held in reserve to support future boolean command options.

DO bit 0x04 enables best response option during joining.
By default it is disabled, which selectes the First Response option.
First response will cause the node to join with the first network to send a beacon response.
A change from the prior release is that the node will continue to dwell on the first response channel in an attempt
to receive beacon responses from all neighbors on that same network as reported in the first beacon response.
Best response will cause the node to search all channels in the SC mask before selecting a network to join.

The NH limit was reduced from 30 to 11 to comply with the SE 1.x specification.

DO, ZT, ZU, ZV have been added to the mxi files.

**************************************************************************
*                       Version 3x26 Release Notes                       *
**************************************************************************
Release Date: July 8, 2010
EmberZNet  Release: v3.5.0 stack

OTHER

Vantive 35116
The Range Extender will try to join a network 3 times at 1 second intervals, 
then at 1 minute intervals for 15 minutes, and thereafter at 1 hour intervals.
As before, Coordinator, Router, and End Devices will try to join a network 
3 times at 1 second intervals before giving up.

Corrected bug introduced in 3x25 where CB2 with NJ=0x00 or 0xFF 
would send zero or 0xFF instead of 60 seconds.
**************************************************************************
*                       Version 3x25 Release Notes                       *
**************************************************************************
Release Date: July 6, 2010
EmberZNet  Release: v3.5.0 stack

BUG FIXES

Vantive 34569.
Fixes a bug in the code which checks for EO==8 and 
a lack of an authorized trust center link key before launching
KE endpoint discovery and authentication.

OTHER

Vantive 35065
NJ can now be set to 0xFF, which allows permit join to persist indefinitely.
The default value of 0xFE is unchanged.
**************************************************************************
*                       Version 3x24 Release Notes                       *
**************************************************************************
Release Date: July 2, 2010
EmberZNet  Release: v3.5.0 stack

BUG FIXES

Vantive 34569.
If authentication is enabled (EO==8), and authentication is interrupted or fails, 
the device will leave the network and retry join/authentication.
A device with EO==8 may not remain associated and unauthenticated.

**************************************************************************
*                       Version 3x23 Release Notes                       *
**************************************************************************
Release Date:  May 29, 2010
EmberZNet  Release: v3.5.0 stack

FEATURES

- Change to Range Extender's Assoc LED blinking function

Assoc LED state   Meaning
-----------------------------------------------------------------------------
Steady Light      Node is joined and connection to Coordinator is verified
3000 msec blink   Node is not joined, AI will indicate why
1000 msec blink   Node is trying to join
 250 msec blink   Node is joined but connection to Coordinator is not working

Note the state of the LED1 on development boards is the reverse of the Assoc LED.
When the Assoc LED is on, LED1 is off; when the Assoc LED is off, LED1 is on.

Once the node has joined, the status of the connection to the Coordinator is checked at 30 second intervals.

BUG FIXES
- Quickly sending two fragmented messages was hanging the XBee.  Now the first message will transmit,
the second will fail with a TxStatus of 0x32 returned.

- The Coordinator was sometimes not responding to KE Init requests with KE Init responses, it does now.

- Failure of KE endpoint discovery will cause the device to leave and try to join again,
provided there are untried join attempts remaining.

- Fixed a bug where accumulated KE endpoint discoveries were causing a R/E/RExt to leave the network needlessly after associating.

- Vantive 33995: code now handles a redundant request to start joining while a join is already in progress.
Depending on when the second join request occurs, the device will either restart the join, or leave the network and attempt to join again.
A new modem status message is generated if this occurs (MODEM_CONFIG_CHANGED=0x11).

- Vantive 34056: An attempt to broadcast with APS encryption enabled in the TxOptions will fail
and generate a TxStatus code of TX_STATUS_APS_BCAST=0x2D.
An attempt to broadcast with APS encryption enabled in the TxOptions with EE=0 will fail
and generate a TxStatus code of TX_STATUS_APS_NO_EE=0x2E.

OTHER

- Default setting for NK on the Coordinator has been changed from 1 to 0.
This means the Coordinator will generate a random network key when the network is formed,
instead of using a network key value of '1'.

- Default setting for KY on the Coordinator has been changed from 1 to 0.
This means the Coordinator will generate a random global initial link key when the network is formed,
instead of using a global initial link key value of '1'.

- Default setting for EO on the Router and End Device has been changed from 0 to 8.
Now that we have production certificates integrated into our manufacturing processes, 
it makes more sense to enable authentication by default.

UNRESOLVED ISSUES:

- Quickly sending two fragmentable messages to the same destination will hang the XBee.
The workaround is to wait for the TxStatus response from the first message before sending the second.

**************************************************************************
*                       Version 3x1B Release Notes                       *
**************************************************************************
Release Date:  March 8, 2010
ZigBee Stack:  EmberZNet 3.4.1 ZigBee-PRO stack

FEATURES
- Support for XBee-Pro PLus: SC range of 0-7FFF, Temperature compensation, overvoltage protection
- SC defaults to 7FFF

NEW AT COMMANDS
- TP command for XBee-Pro Plus, returns temperature in Celsius
- %V command, returns supply voltage in units of mV

BUG FIXES
- DB command fixed
- After a Mgmt_Leave_req, rejoining failed until an NR or NR0 occurred.

**************************************************************************
*                       Version 3x1A Release Notes                       *
**************************************************************************
Release Date:  October 2nd, 2009 (BETA RELEASE)
ZigBee Stack:  EmberZNet 3.4.1 ZigBee-PRO stack

FEATURES
- Support for XBee-Pro PLus: SC range of 0-7FFF, Temperature compensation, overvoltage protection

NEW AT COMMANDS
- TP command for XBee-Pro Plus, returns temperature in Celsius
- %V command, returns supply voltage in units of mV

BUG FIXES
- DB command fixed
- After a Mgmt_Leave_req, rejoining failed until an NR or NR0 occurred.
**************************************************************************
*                       Version 3x19 Release Notes                       *
**************************************************************************
Release Date:  June 23rd 2009
ZigBee Stack:  EmberZNet 3.4.0 ZigBee-PRO stack

FEATURES
- new source addresses are added to the address table to facilitate subsequent acceptance of APS encrypted packets

NEW AT COMMANDS
- NR, NR0 command added to disassociate local node from the network
- PO command added to set polling rate on end devices; zero value invokes 100 msec delay, 
range is 1..x1770 in units of 10 msec (10msec:60sec), default is 0x09 (maps to 100 msec)

BUG FIXES
- End Devices leave the network after polls are not answered AND 5 seconds have elapsed without polls being answered
- End Devices wake completely upon receiving a fragment 
- Broadcast messages which are too big to process no longer hang the coordinator and now return a 0x74 Tx Status message
**************************************************************************
*                       Version 3x18 Release Notes                       *
**************************************************************************
Release Date:  June 4th 2009
ZigBee Stack:  EmberZNet 3.4.0 ZigBee-PRO stack

FEATURES
- A new transmit status (0x26) for a non-failure status where an expected relay of a broadcast packet by a node's neighbors was not detected.
- A new receive option bit (0x40) was added which indicates if the packet came from an end device.
- Two speed end device polling.  7.5 seconds is the slow rate, which switches to the fast rate to transact with the parent, and back to slow when it is done.
- In the transmit queue, getpendingtx gets the oldest entry instead of the next entry.
- If a node discovers it has been orphaned by its parent, it now leaves and attempts to rejoin the net.
- CTS is deasserted during authentication.

NEW AT COMMANDS
- A new command "PO" which sets the slow polling rate on the end device.	

BUG FIXES
- Fixed a bug in packet tracking.
- If the extended timeout option is enabled, then it is used because end devices need more time than routers to ack their packets.
- A watchdog reset has been fixed which occurred when a source-route was used inappropriately.
- A router/end device with no certificate no longer attempts to discover the key establishment cluster.
- A coordinator now uses the correct destination endpoint value when responding to SE cluster requests.

**************************************************************************
*                       Version 3x17 Release Notes                       *
**************************************************************************
Release Date:  June 2nd 2009
ZigBee Stack:  EmberZNet 3.4.0 ZigBee-PRO stack

FEATURES

NEW AT COMMANDS
	
BUG FIXES
- APS Encryption and Fragmentation supports payloads of one to 128 bytes.
**************************************************************************
*                       Version 3x16 Release Notes                       *
**************************************************************************
Release Date:  May 29th 2009
ZigBee Stack:  EmberZNet 3.4.0 ZigBee-PRO stack

FEATURES
- Changed Modem descriptor from XB24-ZB, XBP24-ZB to XB24-SE, XBP24-SE respectively.
- Using production release of Ember Stack 3.4.0.

NEW AT COMMANDS
	
BUG FIXES
- A power reset no longer resets the Coordinator's Key Table.
**************************************************************************
*                       Version 3x15 Release Notes                       *
**************************************************************************
Release Date:  May 27th 2009
ZigBee Stack:  EmberZNet 3.4 (beta 3) ZigBee-PRO stack

FEATURES
- Key Establishment is now disabled on routers and end devices by default.
To enable, set EO=8.  KE is always enabled on Coordinators, EO=2.
This was done to improve the "out-of-the-box" experience for developers
 who lack test or production certificates for their modems.
To enable KE, set EO to 8: "7e 00 05 08 01 45 4f 08 5a"
To disable KE, Set EO to 0: "7e 00 05 08 01 45 4f 00 62"

NEW AT COMMANDS
	
BUG FIXES
- Corrected problem which generated a 0x74 status code (payload too big) 
when APS encryption was invoked for RF data payloads of 58-66 bytes.

**************************************************************************
*                       Version 3x14 Release Notes                       *
**************************************************************************
Release Date:  May 15th 2009
ZigBee Stack:  EmberZNet 3.4.12 (beta 2) ZigBee-PRO stack

FEATURES
- End Devices are supported in this release

NEW AT COMMANDS

BUG FIXES
- End Device was unable to join the network as a child of the Coordinator.
- Hardcoded endpoint value (instead of correct source endpoint value) was being used in generating KE responses.

**************************************************************************
*                       Version 3x13 Release Notes                       *
**************************************************************************
Release Date:  April 1st 2009
ZigBee Stack:  EmberZNet 3.4.0 (beta 1) ZigBee-PRO stack

FEATURES
- Fragmentation has been added.  The maximum payload size is 128 bytes, 
  supported by the transmission of up to three fragment packets.
- SC mask default value has been changed to 0x3FFF.
- Ability to disable authentication.  For routers and end devices, 
  change the EO setting from 8 (enables authentication) to 0 (disable authentication).

NEW AT COMMANDS
- VC:  Verify certificate.  Read-only.  1 = certificate present, 0 = no certificate present.

BUG FIXES
1. Power cycling a router no longer causes it to perform key establishment.

**************************************************************************
                             Known Issues
**************************************************************************
The following are known issues in the SE hardware / software.

****** Compiler and Ember Stack ******
Both the compiler and stack are beta versions.  We are awaiting a production release for both from Ember.

******   Simulated EEPROM Erases   ******
The Ember ZigBee stack occasionally writes information to non-volatile memory.  These writes
may require performing a flash page erase which can block up to 20ms (worst case).  The 
EM250 has a 4-byte FIFO to collect incoming serial data.  However, if serial uart interrupts 
are disabled for 20ms, it is possible for incoming serial data to be dropped once the 4-byte
FIFO filles.  ZB firmware de-asserts CTS about 40 microseconds before an erase operation 
begins.  The application should observe CTS flow control as quickly as possible to prevent 
data loss.  

Note that PCs often make use of a FIFO buffer where serial data can be buffered prior to 
transmission to the serial port.  If FIFO buffers are used, PC applications will not be 
immediately responsive to CTS and may experience rare data loss.





