EmberZNet GA for STM32W108xx RF microcontrollers

Size: px

Start display at page:

Download "EmberZNet GA for STM32W108xx RF microcontrollers"

Kristian Ward
5 years ago
Views:

1 Release notes EmberZNet GA for STM32W108xx RF microcontrollers About these release notes This is Rev 4 of the release notes for the STM32W108xx kits related to the GA (general availability) of the EmberZNet stack. This release of these kits contains the following: Improvement on lowering the power consumption of STM32W108xx devices especially when operating as a sleepy end device using a battery as a power source. Hardware Abstraction Layer (HAL) software provided as source code for the STM32W108xx ZigBee PRO Networking stack Sample Applications provided as source code Hardware Reference Designs and Datasheet for the STM32W108xx Serial-UART-only and Serial-UART-OTA Bootloaders. Added support for multiple STM32W108 application boards delivered with the STM32W108xx Kits Note: 1 The term application board refers to the STM32W108xx boards delivered with all available STM32W108xx kits. This term is not used for referring to the STM32-Primer2 + MB850 platforms. 2 For more information, visit the STM32W 32-bit RF microcontroller webpages at These webpages provide full access to all STM32W108xx resources (kits, software packages and documents). What s new The EmberZNet GA stack is designed to run on STM32W108 engineering samples and on the STM32W108xBU61 microcontroller. This release addresses the following low power improvements: The power consumption of common operations performed by battery operated, sleepy end devices, has been greatly reduced. Functions such as polling for data automatically take advantage of improvements to radio operation. Additional improvements can be achieved by updating applications to take advantage of the new CPU idling function that sets the CPU into a low power state when it has nothing to do and is otherwise waiting for packets to be received, waiting for interrupts to trigger, or waiting for a delay to expire. The following features are deprecated in this new release: SLEEPMODE_POWERDOWN and SLEEPMODE_POWERSAVE sleep modes are deprecated on STM32W108xx devices. Currently, halsleep() function remaps these modes to the appropriate replacements which are SLEEPMODE_NOTIMER and SLEEPMODE_WAKETIMER respectively. The intention is the new naming should be more descriptive. Please refer to the hal/micro/micro-common.h file for more information about each sleep mode. March 2011 Doc ID Rev 4 1/10

2 Contents RN0034 Contents 1 Read me first Host PC system requirements Installation Support Software versions Supported hardware platforms Accessing documentation File layout Installation Installing the EmberZNet stack Command line utilities Installing drivers for USB virtual COM Known issues/limitations Networking stack and HAL software IAR Embedded Workbench for ARM Intended behavior Issues fixed in the EmberZNet stack Stack/HAL issues fixed Revision history /10 Doc ID Rev 4

3 Read me first 1 Read me first This chapter provides important information about this release. 1.1 Host PC system requirements PC and compatible devices running Windows XP operating systems. Note: To install the IAR (Integrated Development Environment) used for building the EmberZNet ZigBee PRO stack, users must have administrator privileges. 1.2 Installation Refer to the STM32W108xx kit user manuals for detailed step-by-step instructions about how to set up your kit for the first time. See Section 2: Installation for detailed instructions on installing this release. 1.3 Support STM32W108 kit customers are eligible for technical support. To obtain information about STM32W108 products and services, as well as to sign up for product support, visit Software versions Stack software - version 4.3 build 27. The version number is defined as SOFTWARE_VERSION in the source code in the stack/config/config.h file. This stack software release is intended to be used with the following versions of other components: Programming utilities - em3xx_load (Version 2.0b ), em3xx_convert (Version 2.0b ) and stm32w_flasher (Version 1.3.0b1) IAR Embedded Workbench for ARM (Version or 5.41) 1.5 Supported hardware platforms This release is supported on the STM32W108xx platforms available with the following kits: STM32W108xx starter kit (order code: STM32W108B-SK) STM32W108xx extension kit (order code: STM32W108B-KEXT) STM32W108xx low-cost RF control kit (order code: STM32W-RFCKIT) Doc ID Rev 4 3/10

4 Read me first RN Accessing documentation To view the full set of documentation, open: Start > All Programs > STMicroelectronics > EmberZNet > STM32W108 > Documentation or open the documentation/index.htm file from the root directory of the installed EmberZNet stack. The documentation includes HTML pages describing the EmberZNet Stack API and the HAL API, along with Kit user manuals, an application developer's guide, the STM32W108 datasheet, and various application notes. To view information on the sample applications, open: Start > All Programs > STMicroelectronics > EmberZNet > STM32W108 > Samples Or open the app/sampleapps.html file from the root directory of the installed EmberZNet stack. This includes explanations of how the sample applications work, what commands are supported, notes, and limitations. It also includes shortcut links to open the project files. To view documentation for the IAR Embedded Workbench, open: Start > All Programs > IAR Systems > IAR Embedded Workbench for ARM > Release Notes 1.7 File layout Installing the EmberZNet stack software creates the following directories: app: Contains sample application utilities and source code. Note that sample application project files are included in the ewb directory under the project directory (for instance, app/ sensor/ewb). Project workspaces have an eww extension. app/nodetest: Contains a pre-built image of the nodetest image. app/prebuilt: Contains pre-built images of many of the sample applications including: ZigBee Smart Energy (SE), ZigBee Home Automation (HA) and Sensor example applications (sink, sensor, sleepy-sensor, mobile-sensor). Note: It also contains the binary image for the Perytons Network Analyzer. app/util: contains useful utility libraries for developing applications. hal: Contains the STM32W108 HAL source code. stack: Contains the header files necessary to build EmberZNet applications. build: Contains the pre-built stack libraries. Note that when sample applications are built, their corresponding files are stored in a subdirectory of this directory. documentation: Contains documentation files. Open documentation/index.htm to see a list of all documentation files. tool/bootloader: Contains the bootloader project files for building bootloaders with custom modifications. tool/em3xx: Contains the em3xx utilities. tool/stm32w_flasher: Contains the stm32w_flasher utility. 4/10 Doc ID Rev 4

5 Installation 2 Installation Refer to the STM32W108xx kits user manuals for detailed step-by-step instructions about how to set up your kit for the first time. The release is made up of several components that work together to provide complete functionality. With the exception of the IAR Embedded Workbench, the most recent versions of all of these installers can be downloaded from the STM32W 32-bit RF microcontroller webpages at Installing the EmberZNet stack The stack installer (EmberZNet_\{release version}-stm32w108.exe) should be installed first, and performs the following actions: Installs the files needed to develop applications on the EmberZNet Stack into a directory specified by the user. (The default location is C:\Program Files\STMicrolectronics\{release version}\ STM32W108). Adds a shortcut to the Start Menu into the folder specified by the user (default directory is...\stmicrolectronics\{release version}\stm32w108). Adds an entry to the Add/remove programs panel (accessed from the Windows Control Panel) so the stack can be uninstalled. Does not affect any environment variables. 2.2 Command line utilities The following command line utilities are provided in the tools\em3xx folder of the installation path: em3xx_load.exe em3xx_convert.exe used to convert s37 files into ebl format The following utility is provided in the tools folder of the installation path: stm32w_flasher Note: Refer to the STM32W108xx kits user manuals for more information about using this utility. 2.3 Installing drivers for USB virtual COM In order to use the serial communication channel on an application board, a driver for the FTDI USB-to-Serial converter or a Virtual COM port driver for the STM32F103xx MCU must be installed. The correct driver is based on the application board revision number. The following application boards requires the FTDI USB-to-Serial converter driver: MB851 Rev A MB851 Rev B MB954 Rev A This driver is available from the FTDI website at All other application boards require the STMicroelectronics Virtual COM port driver which is available from the ST website at (then /internet/com/ SOFTWARE_RESOURCES/SW_COMPONENT/SW_DRIVER/vcpdriver_v1.zip). Doc ID Rev 4 5/10

6 Known issues/limitations RN Known issues/limitations 3.1 Networking stack and HAL software 1. Persistent security state after join failure may cause spurious failures in subsequent join attempts. 2. Corrupt / incorrect response data in ZDO Binding Table Response. 3. Application is not running after a default recovery in some cases. This seems to happen when the target node is in default recovery mode (after being reset during a bootload process). When the source node attempts to recover using a broadcast query, the recovery process seems to be successful. However, the RX channel on the UART does not seem to be running; the TX channel seems to be working fine. This seems to only happen on the standalone bootloader demo v2 application which uses a virtual UART; when tried with the sensor application which uses a real UART, it seems to work fine. 4. Indirect Transaction Expiry route error not being sent in some situations. 5. MTORR reception by concentrator neighbor sometimes causes an assert in the emhandleroutecommand call. 6. em3xx_load may not properly leave the chip in a state where deep sleep can be fully achieved. If testing deep sleep, power-cycle the chip after loading a new image. 7. Not all of the output from commands in the nodetest application has been fully updated to use our easily parse-able response formatting. These commands may have their output changed in future releases. 8. ARM has recently published the ARM Cortex Microcontroller Software Interface Standard (CMSIS). The CMSIS is under evaluation for use in future releases. Therefore, it is possible the register definitions, exception and interrupt definitions, and other HAL APIs and source code may change in future releases to offer compatibility with the CMSIS Standard. 9. ARM's TPIU TracePort functionality is not gracefully shutdown when entering deep sleep. This could cause some unwanted noise to be seen in debug channel output of sleepy devices. 10. The ADC functionality included as part of the HAL is a port of the driver from the sn2xx. This driver should be considered preliminary as it does not provide functionality for all aspects of the ADC s hardware features of the STM32W108 series. This driver is also implemented assuming that the EmberZNet Stack will share the ADC with the application. This is no longer true, as the application has full control of the general purpose ADC on the STM32W108xx. Future releases may include changes to the ADC driver to expose the additional new features, and remove the sharing. 11. The haladcsetrange() function within the HAL should not be used. Only the default, low voltage range of the ADC should be used. 6/10 Doc ID Rev 4

7 Known issues/limitations 3.2 IAR Embedded Workbench for ARM 1. When starting a debug session, IAR may incorrectly display a warning about the stack CSTACK being filled to 100% while the threshold is set to 90%. 2. An IAR optimization error may result in a NULL pointer access in very rare cases where a pointer that may sometimes be NULL is passed to a function that then verifies the pointer is not NULL before accessing it. 3. The IAR linker displays usage statistics about the amount of different types of memory that are used. The RAM usage statistics (read/write data memory) incorrectly count the Simulated EEPROM as RAM. Please instead refer to the output generated by em3xx_convert which provides a more complete breakdown of usage. 4. While the linker prints to stdout basic information regarding code and data usage, this information can be confusing and misleading. em3xx_convert, which is triggered by the IAR project files as a post build step, prints to stdout more detailed information of RAM usage, Flash memory usage, and a usage summary. 5. Errors and memory usage information generated by em3xx_convert may not be visible in the build output window of the IAR Workbench. To view these errors, select Options from the Tools menu, then select the Messages category. Under the Show build messages option, select All. 6. See the IAR EWARM release notes for additional information. 3.3 Intended behavior This section describes certain intended behaviors that have caused confusion: 1. Broadcasts with an empty payload are not heard through the loopback by the sending node. Problem: When sending a broadcast with no payload, the sending node does not get an emberincomingmessagehandler() call for the broadcast loopback. Other devices in the network will receive the broadcast as expected. Workaround: Add a 1-byte payload to a broadcast that the sender expects to hear through the broadcast loopback. 2. It takes at least 2 seconds for a node to leave the network. Problem: ZigBee requires devices to send a Leave message when they are leaving a network. To ensure that this message is sent, devices wait 2 seconds. Workaround: None. 3. When a node hears one of its own messages, the lasthoplqi and lasthoprssi parameters should have invalid values. Problem: The last read values for LQI and RSSI are used when a device hears a message from itself. Workaround: A device should not use LQI and RSSI values when the source address is itself. 4. Parent could allow a device rejoining with an in-use ID to cause a node on the network to change its ID. Problem: If a child attempts a rejoin using a shortid that is already assigned to another device, the parent does not allow the rejoin and sends an ID conflict message causing the joined device using the same ID to change it's ID. Workaround: None, intended behavior. Doc ID Rev 4 7/10

8 Known issues/limitations RN A route discovery is not initiated if a source routed unicast is sent with the EMBER_APS_OPTION_FORCE_ROUTE_DISCOVERY APS option. Problem: The source route option takes precedence over the route discovery option. This could be setup to return an error, but the designed behavior is to allow the source route option (the route being used is a many-to-one route) to take precedence over the route discovery option. Workaround: None, intended behavior. 6. Route Records are not sent to the Trust Center from a router after it reboots Problem: Route table data (such as the concentrator flag associated with route destinations that are concentrators) are stored in RAM, which is cleared upon reboot. When the router reboots, it has no Many-to-One Route [MTOR] to the Trust Center [TC], so it has no reason to send Route Records when communicating to the TC. Furthermore, routing to the TC becomes almost impossible because no known route exists; the exception to this is when the router in question is a neighbor of the TC, in which case a one-hop route is inferred by the router once it finds the destination in its neighbor table. However, even in the inferred, one-hop route case, there is no actual route entry and thus no concentrator status to be preserved yet, so no Route Record arrives for the TC to process. Workaround: While it is possible for the TC (assuming it s running our EmberZNet PRO stack) to infer a similar one-hop route back to the router in the neighboring case and thus route its replies, this will not work for routers that are non-neighbors of the TC. In order to properly correct the situation for all routers, the TC needs to be doing Many-to-One Route Requests [MTORR] periodically to advertise its status as a concentrator. Once the MTORR is received by the router, a route table entry for the TC will be created, and Route Records will resume when unicasting to the TC. 8/10 Doc ID Rev 4

9 Issues fixed in the EmberZNet stack 4 Issues fixed in the EmberZNet stack 4.1 Stack/HAL issues fixed Cell Bias and ADC calibrations are now performed on every wakeup. Developed an easy way to redefine halsc1isr(). Fixed possible buffer leak when sending sleepy broadcasts. Applications now have more accurate control over remote binding modifications. Serial library now accommodates FIFO queues larger than 128 bytes. Serial library now properly handles non-power-of-2 FIFO queue sizes. Output file for standalone-bootloader-demo-v2 is now included properly in the project file. When opening the project file in IAR, the output file is now properly included. Previously, the name was missing and when trying to debug the project, IAR would display a message that it could not find the output/debug information. Maximum transfer size fields for Node Descriptor Response can now be set by the customer. Added a halsleep function with milliseconds (as opposed to quarter seconds) accuracy. STM32W108xx is now able to transmit after shutdown (Deep Sleep - Nodetest). Leaving the ZDO network causes the node to leave the network, if eui64 matches. Expose API for performing AES MMO Hash (for install codes) on SoC platform. emberjoinnetwork no longer prevents a secure join. Fixed difference in current draw before and after adctest command executed in Nodetest. New (public) API for sending end device announcement. 5 Revision history Table 1. Document revision history Date Revision Changes 16-Nov Initial release. 16-Feb Jun Mar Added support for EmberZNet GA stack. See What s new on page 1 for list of modifications. Updated Section 1.6: Formal ZigBee certified platform status on page 3. Added support for EmberZNet GA stack. See What s new on page 1 for list of modifications. Changed supported hardware platforms; changed ST URL. Doc ID Rev 4 9/10

10 Please Read Carefully: Information in this document is provided solely in connection with ST products. STMicroelectronics NV and its subsidiaries ( ST ) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described herein at any time, without notice. All ST products are sold pursuant to ST s terms and conditions of sale. Purchasers are solely responsible for the choice, selection and use of the ST products and services described herein, and ST assumes no liability whatsoever relating to the choice, selection or use of the ST products and services described herein. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. If any part of this document refers to any third party products or services it shall not be deemed a license grant by ST for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoever of such third party products or services or any intellectual property contained therein. UNLESS OTHERWISE SET FORTH IN ST S TERMS AND CONDITIONS OF SALE ST DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE USE AND/OR SALE OF ST PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION), OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS EXPRESSLY APPROVED IN WRITING BY AN AUTHORIZED ST REPRESENTATIVE, ST PRODUCTS ARE NOT RECOMMENDED, AUTHORIZED OR WARRANTED FOR USE IN MILITARY, AIR CRAFT, SPACE, LIFE SAVING, OR LIFE SUSTAINING APPLICATIONS, NOR IN PRODUCTS OR SYSTEMS WHERE FAILURE OR MALFUNCTION MAY RESULT IN PERSONAL INJURY, DEATH, OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE. ST PRODUCTS WHICH ARE NOT SPECIFIED AS "AUTOMOTIVE GRADE" MAY ONLY BE USED IN AUTOMOTIVE APPLICATIONS AT USER S OWN RISK. Resale of ST products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by ST for the ST product or service described herein and shall not create or extend in any manner whatsoever, any liability of ST. ST and the ST logo are trademarks or registered trademarks of ST in various countries. Information in this document supersedes and replaces all information previously supplied. The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners STMicroelectronics - All rights reserved STMicroelectronics group of companies Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan - Malaysia - Malta - Morocco - Philippines - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States of America 10/10 Doc ID Rev 4

RN0046 Release note. 1 Introduction. SimpleMAC library for STM32W108xx kits. About this release note

RN0046 Release note. 1 Introduction. SimpleMAC library for STM32W108xx kits. About this release note Release note SimpleMAC library for STM32W108xx kits 1 Introduction About this release note This release note is related to the SimpleMAC library which supports all the available STM32W108xx kits. This