There are 3 ways to request a device to leave the network, although none of them are perfect in that they do not guarantee the result of having a device exit immediately, or to force it to stay out of the network in the future ("kicking out a device").

Here are some descriptions of the leave request methods with pros and cons.

1) Send ZDO Leave to ZR parent with ZED's EUI as target
-Pros: Will always succeed (if ZED is still in the child table of ZR and ZR is reachable) with response status, regardless of what ZED's polling rate is.
-Cons: If ZED isn't polling parent regularly, parent's NWK Leave command to child could time out before child gets it, and child gets erased anyway. When child polls next time, parent will tell him to leave and rejoin because it's an non-child end device, so that gets you back to before the ZDO Leave.

2) Send ZDO Leave to ZED with ZED's EUI (or all-zero EUI) as target
-Pros: ZDO response clearly indicates whether ZED received the leave request. No confusion as above with ZED accidentally being told to rejoin.
-Cons: If ZED isn't polling parent regularly, it won't receive this request, so sender needs to be careful about timing of sending the request. In older EmberZNet stack versions (4.6 through 5.4), a bug existed that would sometimes reject a ZDO Leave Request sent to an end device depending on who was the sender. In EmberZNet versions 5.6.0 and earlier, the ZED won't get a ZDO Leave Response out before it leaves the network, so the requester must rely on the APS ACK rather than the ZDO response to confirm receipt.

3) Send APS Remove Device command (emberSendRemoveDevice) to ZR parent with ZED's EUI as deviceToRemove.
-Pros: APS-authenticated (unlike ZDO messages), so devices (even SE devices) can't choose to ignore this, and it is harder to spoof because it requires APS encryption.
-Cons: Need long address of child and parent for the command. No APS ACK available for APS commands, so can't confirm receipt by the parent. Still may encounter problem where parent deletes child before the child knows it was removed, causing child to rejoin on next poll attempt. Can only be sent by Trust Center.

In general, we recommend a fallback system, such as trying 2 and falling back to 1 (or 3) if it doesn't work.

Some customers testing EM3xx device transmit functionality over temperature observe transmit issues such as signal degradation and varying frequency offsets during large changes in temperature. This happens when the customer places the device in a continuous transmit mode, for example with standalone tx, txtone or txstream test modes using the nodetest application or manufacturing library based test commands in the customer's application, and then change the temperature without exiting the continuous transmit mode.  This test method, where the device resides in a continuous transmit mode, does not reflect the device’s normal transmit behavior as it would function in a real application.

The reason for the customer seeing these performance issues is the device is not able to recalibrate the channel when left in this continuous transmit mode and recalibration is not triggered when the temperature changes. When a device is powered up for the first time after programming and it selects a channel, a calibration is run automatically for proper configuration of the device. This calibration occurs the first time each channel is selected (since default channel calibration token data exists for that channel in simulated EEPROM), as well as any time there is a change in temperature (when compared with the temperature at the time of the previous calibration event) which is large enough to trigger recalibration.

Silicon Labs recommends not to remain in a continuous transmit mode while changing temperature.  We recommend instead to bring the unit to the desired temperature, start the continuous transmit mode, take the desired test measurement, exit / stop the transmit mode, move on to the next temperature set point, and repeat.  This allows all channel calibration checks and events to occur normally, thus allowing transmit operation to function normally at all test temperatures.

Related articles:

http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24MHz-Crystal-Tuning/ta-p/157154

http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24-MHz-Crystal-Selection/ta-p/144602

Related application note:

http://www.silabs.com/Support%20Documents/TechnicalDocs/AN700.pdf

1. Hardware setup

You need an EM35x breakout board (which is part of the EM35x development kit) and a module that supports the USB MSD bootloader (such as EM3588, which we assume in this example).

Check your jumper settings on the EM35x breakout board (shown in picture below is revision C2). Important to check: J40 should have upper two pins shorted.

2. Upload the Application with MSD Application Bootloader Local Storage­

Build an application with the bootloader type "Local storage" (under the "HAL configuration" tab in Ember Desktop app builder), then load the application you have built (which we have named "MSD_bootloader_EM3588_test.ebl" in this example) and the bootloader "msd-app-bootloader-local-storage.s37" (which is supplied as a pre-built image in the EmberZNet PRO stack release) to the chip.

You may wish to build a second application as the "upgrade image". When you build the application we suggest that you enable LED1 as the heartbeat LED, which is helpful as a simple indicator when the application is running (see step 4 below).

3. Enter bootloader mode

Ground PA5 (or press down the BOOTLOAD button near the bottom right corner of EM35x breakout board) while pressing and releasing the RESET button or doing a power-on-reset. The chip enters a FIB monitor mode (see EM3588-RM, section 7.5). No LED on the EM3588 module should be on at this time. Then send a carriage return from the physical UART (SC1) for the chip to enter bootloader (see AN772 section 1.4.1). The green LED0 on EM3588 module is lit now.

To avoid sending the carriage return to enter bootloader, you can define USE_BUTTON_RECOVERY to use another GPIO pin to enter bootloader mode (without going into the FIB monitor mode first). In this case you need to rebuild the msd-app-bootloader-local-storage bootloader image. The .eww workspace is provided in the stack release so you can build it in IAR yourself. Just add USE_BUTTON_RECOVERY in the “Defined symbols” box under project options -> C/C++ Compiler -> Preprocessor, and rebuild. Then load this modified bootloader to the bootloader area in step 2 when you upload an application to the chip. The default button on EM35x breakout board is button1 (PC6). If you wish to use another GPIO pin you can modify it too. 

When you are in bootloader mode, you will see the green LED0 on EM3588 module is lit (see the picture in step 1).

4. Firmware upgrade

Plug in a USB cable to the USB port beside the EM3588 module (as shown in the picture in step 1) and to your PC. In Windows Explorer you should see a mass storage device show up.

Open this mass storage device, and drag and drop the .ebl file you want to upgrade with.

Unplug the USB cable. The firmware update should happen now, and you will see the red LED1 on the EM3588 module flashing which is a simple sign that the application you’ve just uploaded is running now.