Member | Action | Date |
---|---|---|
|
Updated
to
Zigbee Host Application is not allowing all devices to join request with link keys
your collegue have confirmed it is the problem with the plug that fails to decrypt the NWK key so it cannot announce itself in the network. Can you please makesure that you decrypt the messages with the link key i gave you? I am confirming this device cannot join from the logs i have attached
Show more
|
Feb 20 2020, 6:25 PM |
|
Posted
Zigbee Green Power on Zigbee and Thread Wireless Knowledge Base
Zigbee® Green Power (ZGP) is included in the Zigbee 3.0 specification (Z3) (Zigbee Alliance, Zigbee 3.0 specification, https://www.zigbee.org/zigbee-for-developers/greenpower/). It is an end-to-end open standard that allows ultra-low power devices called Green Power Devices (GPDs) to operate on Zigbee networks. The technology requires ultra-low power RF silicon that uses many orders of magnitude less power than required for a Zigbee sleepy or fully-networked wireless connection. The EFR32xG22 EM2 and EM4 power modes along with the back-up RAM feature make it suitable to implement a periodic or event-based GPD sensor with bidirectional commissioning and secured key exchange. GPD Communication There are two types of communication modes based on energy budget: - Unidirectional: the device only transmits information to the Zigbee network - Bidirectional: the device transmits and then receives information back, such as security material. The bidirectional mode implementation uses EM2 power mode and the low energy sleep timer as a wake-up source between transmit and receive. Commissioning and Security The hardware acceleration in EFR32xG22 makes it possible to implement a GPD with the highest level of security (encryption and message integrity with application key exchange) during bidirectional commissioning. Storage of Security Material In a battery-backed GPD implementation, the back-up RAM can hold the security material during EM4 sleep. More Information The user guides on Green Power fundamentals and information about using the Silicon Labs Green Power framework can be found here: https://www.silabs.com/documents/public/user-guides/ug103-15-green-power-fundamentals.pdf https://www.silabs.com/documents/public/user-guides/ug392-using-sl-green-power-with-ezp.pdf |
Feb 13 2020, 7:37 PM |
|
Replied
to
Gecko SDK on GitHub
Hi Diego, This is very helpful feedback, and I've passed this along internally for consideration. All, If there's any other feedback about what would be helpful in how we distribute the libraries and code, please let us know. As I mentioned, we're continuing to discuss how we can do this in a better way internally, so the more feedback the better! ~Tabi |
Dec 27 2019, 7:41 PM |
|
Replied
to
Gecko SDK on GitHub
Hi all, Unfortunately, this issue is more complicated than just using git to push the SDK releases on Github, as there are several licensing and legal complications. We’re continuing to discuss this internally and will let you know when we have more we can share. ~Tabi |
Dec 11 2019, 9:12 PM |
|
Posted
September 2018 SDK Release - Silicon Labs Release Update Notification on Blog
Hi all, I'm pleased to announce new software that includes improvements and bug fixes for our Bluetooth, Thread, Zigbee, and MCU product families. This release provides the following:
Note that API documentation and release notes for most stacks are now available at docs.silabs.com. Need help? Please contact Silicon Labs Technical Support. |
Nov 01 2018, 5:07 PM |
|
Updated
EMU_E110 - Potential Hard Fault when Exiting EM2 or EM3 on Knowledge Base
See the Errata sheet for your device to see the complete description of this errata and affected products:
Affected Devices
The following list shows devices that might exhibit the failure mode.
* Rev D and earlier do not have the issue
Additional Notes Regarding the Failure Mode
When exiting EM2 or EM3, some devices may intermittently execute code incorrectly or enter the hard fault handler instead of entering the expected ISR associated with the wake source.
The flash is powered down in EM2 and EM3 to save power. Some control registers in the flash can rarely enter an invalid state upon power-on, causing the first read of flash to be incorrect. If this occurs after exiting EM2 or EM3, the core attempts to fetch the interrupt address, but the value will be incorrect and may be invalid. In the case of an invalid value, the core will then jump to the hard fault handler for attempting to execute code from an invalid address. All subsequent reads from the flash are unaffected, and it is only the first flash read after exit from EM2 or EM3 that is potentially erroneous.
Software Workaround Installation
The attached ZIP file contains software workarounds for each affected device family for the GCC build tools. These workarounds implement the fix for EM2, but the code and methodology is similar for applications using EM3.
How the Firmware Workaround Works
The firmware workaround relocates the full interrupt vector table to RAM in addition to the peripheral ISRs that are used for EM2 wake-up. When waking from EM2, the core will then jump to the ISR in RAM that performs a dummy read of the flash to clear the potential flash read issue. This method consumes 224 bytes of RAM for Leopard Gecko devices.
Note that when using this workaround to address this issue, the system designer must ensure that no interrupts without the dummy read of flash will wake the device out of EM2 and start executing. To be safe, ensure the interrupts that include the dummy read of flash are the highest interrupt priority prior to entering EM2.
Additional implementation details can be found in the comments supplied in the workaround source code.
For any questions on this issue or the workaround, contact technical support. |
Oct 29 2018, 6:36 PM |
|
Updated
May 2018 SDK Release - Silicon Labs Release Update Notification on Blog
Hi all, I'm pleased to announce the latest SDK that includes improvements and bug fixes for our Bluetooth, Thread, Zigbee, and MCU product families. This release provides the following:
Need help? Please contact Silicon Labs Technical Support. ~Tabi |
Oct 01 2018, 9:17 PM |
|
Replied
to
Example of I2C on Micrium
Hi Ernst, Sorry for the confusion! We'll keep the conversation on this forum going forward. Thanks, ~Tabi |
Aug 20 2018, 11:30 PM |
|
Updated
May 2018 SDK Release - Silicon Labs Release Update Notification on Blog
Hi all, I'm pleased to announce the latest SDK that includes improvements and bug fixes for our Bluetooth, Thread, Zigbee, and MCU product families. This release provides the following:
Need help? Please contact Silicon Labs Technical Support. ~Tabi |
Aug 07 2018, 11:40 PM |
|
Posted
May SDK Release - Silicon Labs Release Update Notification on Blog
Hi all, I'm pleased to announce the latest SDK that includes improvements and bug fixes for our Bluetooth, Thread, Zigbee, and MCU product families. This release provides the following:
Need help? Please contact Silicon Labs Technical Support. ~Tabi |
Aug 07 2018, 11:38 PM |