search

Elelabs / elelabs-zigbee-ezsp-utility

Elelabs Zigbee EZSP Utility to perform firmware update on a range of Elelabs EZSP products as well as other generic EZSP adapters.
Apache License 2.0
134 stars 27 forks source link

[REQUEST] Silcon Labs Zigbee EmberZNet 6.10.9 NCP firmware image as stable release for ELR023 and ELU013? #44

Open Hedda opened 10 months ago

Hedda commented 10 months ago

@NilsBohr please release Silcon Labs Zigbee EmberZNet 6.10.9.0 NCP firmware image as a "stable" release for ELR023/ELU013:

https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-6.10.9.0.pdf

Silabs Zigbee EmberZNet 6.10.9.0 is a bug-fix release of 6.10 contains a few important fixes for those who run the older firmware.

Like to request you add EmberZNet 6.10.9.0 or later Zigbee NCP firmware images (as an upgrade for existing 6.10.3.0 images).

That should keep all existing old compatibility and could act as "stable" stop-gap while experimenting with 7.3.x+ series firmware.

PS: That release notes PRF cover SDK version(s): 6.10.9.0 released October 25, 2023 6.10.8.0 released September 5, 2023 6.10.7.0 released July 13, 2023 6.10.5.0 released March 29, 2023 6.10.4.0 released January 11, 2023 6.10.3.0 released October 13, 2021 6.10.2.0 released September 8, 2021 6.10.1.0 released July 21, 2021 6.10.0.0 released June 16, 2021

Fixed in release 6.10.7.0

ID # Description
398694, 823888, 519731 ZCL reporting plugin is modified so that a rarely occurring exception condition (failure to read a reportable attribute's value; possibly because the attribute's endpoint is disabled) does not result in excess execution cycles, repetitive printing of a debug message, and (for an RTOS configuration) blocking of a lower-priority task.
841499 Fixed issue where a newly joined device can sometimes not get added to the child table if its IEEE address is not known.
1150905 Fixed spurious frame pending bit set when there is no data pending.

Fixed in release 6.10.5.0

ID # Description
1103581 Fixed an issue that caused a new device to join the network with a random extended PAN Id instead of using the same from received beacon. This difference in extended PAN Id was causing a PAN Id conflict upon device join.