doc: zigbee: add known issue KRKNWK-19894 #20634

AdamZelikNS · 2025-02-26T16:00:07Z

Add mention of possible ZCL Reporting configuration data incompatibility issue after performing DFU.

NordicBuilder · 2025-02-26T16:04:47Z

CI Information

^{To view the history of this post, clich the 'edited' button above}
Build number: 9

Inputs:

Sources:

sdk-nrf: PR head: 21a8ebddc6ef936272fe3b2b8f9586e3287d1071

more details

sdk-nrf:

PR head: 21a8ebddc6ef936272fe3b2b8f9586e3287d1071
merge base: 4dfdc18cd66f89855dfa516a750a09cf219cfc97
target head (main): 4dfdc18cd66f89855dfa516a750a09cf219cfc97
Diff

Github labels

Enabled	Name	Description
	ci-disabled	Disable the ci execution
	ci-all-test	Run all of ci, no test spec filtering will be done
	ci-force-downstream	Force execution of downstream even if twister fails
	ci-run-twister	Force run twister
	ci-run-zephyr-twister	Force run zephyr twister

List of changed files detected by CI (1)

doc
│  ├── nrf
│  │  ├── releases_and_maturity
│  │  │  │ known_issues.rst

Outputs:

Toolchain

Version:
Build docker image:

Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped; ⚠️ Quarantine

◻️ Toolchain
◻️ Build twister
◻️ Integration tests

Disabled integration tests

- desktop52_verification
- doc-internal
- test-fw-nrfconnect-apps
- test-fw-nrfconnect-ble_mesh
- test-fw-nrfconnect-ble_samples
- test-fw-nrfconnect-boot
- test-fw-nrfconnect-chip
- test-fw-nrfconnect-fem
- test-fw-nrfconnect-nfc
- test-fw-nrfconnect-nrf-iot_libmodem-nrf
- test-fw-nrfconnect-nrf-iot_lwm2m
- test-fw-nrfconnect-nrf-iot_mosh
- test-fw-nrfconnect-nrf-iot_positioning
- test-fw-nrfconnect-nrf-iot_samples
- test-fw-nrfconnect-nrf-iot_serial_lte_modem
- test-fw-nrfconnect-nrf-iot_thingy91
- test-fw-nrfconnect-nrf-iot_zephyr_lwm2m
- test-fw-nrfconnect-nrf_crypto
- test-fw-nrfconnect-proprietary_esb
- test-fw-nrfconnect-ps
- test-fw-nrfconnect-rpc
- test-fw-nrfconnect-rs
- test-fw-nrfconnect-tfm
- test-fw-nrfconnect-thread
- test-fw-nrfconnect-zigbee
- test-low-level
- test-sdk-audio
- test-sdk-dfu
- test-sdk-find-my
- test-sdk-mcuboot
- test-sdk-pmic-samples
- test-sdk-sidewalk
- test-sdk-wifi
- test-secdom-samples-public

Note: This message is automatically posted and updated by the CI

github-actions · 2025-02-26T16:20:06Z

You can find the documentation preview for this PR here.

Preview links for modified nRF Connect SDK documents:

https://ncsdoc.z6.web.core.windows.net/PR-20634/nrf/releases_and_maturity/known_issues.html

peknis · 2025-02-27T06:18:21Z

doc/nrf/releases_and_maturity/known_issues.rst

@@ -1532,6 +1532,22 @@ KRKNWK-12115: Simultaneous commissioning of many devices can cause the Coordinat
 KRKNWK-11826: Zigbee Router does not accept new child devices if the maximum number of children is reached
  Once the maximum number of children devices on a Zigbee Router is reached and one of them leaves the network, the Zigbee Router does not update the flags inside beacon frames to indicate that it cannot accept new devices.

+.. rst-class:: v2-9-0-nRF54H20-1-rc2 v2-9-0 v2-8-0 v2-7-0 v2-6-3 v2-6-2 v2-6-1 v2-6-0
+
+KRKNWK-19894: The Device Firmware Upgrade (DFU) from |NCS| 2.5 or older to a newer version may cause fatal error or abnormal behavior.


Suggested change

KRKNWK-19894: The Device Firmware Upgrade (DFU) from |NCS| 2.5 or older to a newer version may cause fatal error or abnormal behavior.

KRKNWK-19894: The Device Firmware Upgrade (DFU) from the |NCS| v2.5 or older to a newer version may cause fatal error or abnormal behavior

peknis · 2025-02-27T06:22:22Z

doc/nrf/releases_and_maturity/known_issues.rst

+   The issue occurs in the following conditions: the device initially uses FW built with |NCS| 2.5 or older, has configured ZCL Reporting feature (i.e. reports selected attributes),
+   then DFU is performed where the new FW is built based on |NCS| 2.6.0 or later.


Suggested change

The issue occurs in the following conditions: the device initially uses FW built with |NCS| 2.5 or older, has configured ZCL Reporting feature (i.e. reports selected attributes),

then DFU is performed where the new FW is built based on |NCS| 2.6.0 or later.

The issue occurs when the device initially uses firmware built with the |NCS| v2.5 or older and has the ZCL Reporting feature enabled (which means it reports selected attributes).

The DFU is performed where the new firmware is built based on the |NCS| v2.6.0 or later.

peknis · 2025-02-27T06:22:55Z

doc/nrf/releases_and_maturity/known_issues.rst

+   The issue occurs in the following conditions: the device initially uses FW built with |NCS| 2.5 or older, has configured ZCL Reporting feature (i.e. reports selected attributes),
+   then DFU is performed where the new FW is built based on |NCS| 2.6.0 or later.
+
+   During the upgrade, the NVRAM content is preserved. However, part of this content has a structure that is incompatible with the new FW, leading to abnormal behavior.


Suggested change

During the upgrade, the NVRAM content is preserved. However, part of this content has a structure that is incompatible with the new FW, leading to abnormal behavior.

During the upgrade, the NVRAM content is preserved.

However, part of this content has a structure that is incompatible with the new firmware, leading to abnormal behavior.

peknis · 2025-02-27T06:26:32Z

doc/nrf/releases_and_maturity/known_issues.rst

+   Symptoms: attribute reporting stops working, the device sends Report Attributes command very frequently, but these are corrupted (empty) messages,
+   most likely in such a state it is not possible to reconfigure the reporting feature.
+   In some cases of cluster configuration it is also possible that the FW will encounter a fatal error every time it starts.


Suggested change

Symptoms: attribute reporting stops working, the device sends Report Attributes command very frequently, but these are corrupted (empty) messages,

most likely in such a state it is not possible to reconfigure the reporting feature.

In some cases of cluster configuration it is also possible that the FW will encounter a fatal error every time it starts.

The attribute reporting stops working.

The device sends the Report Attributes command very frequently, but the messages are corrupted (empty), most likely in such a state that you cannot reconfigure the reporting feature.

In some cases of cluster configuration, the firmware may encounter a fatal error every time it starts.

Here I only applied part of one suggestion. I have used Most likely, this device condition prevents remote reconfiguration. - so that it is more clear what the state of what this sentence means is

peknis · 2025-02-27T06:29:01Z

doc/nrf/releases_and_maturity/known_issues.rst

+   **Workaround:** After detecting that the device has been upgraded, perform a NVRAM erase (all or just the part with ``ZB_NVRAM_ZCL_REPORTING_DATA`` id).
+   Note that this is a way to avoid abnormal behavior, but the consequence is the loss of configuration data, i.e. the need to reconfigure the device.


Suggested change

**Workaround:** After detecting that the device has been upgraded, perform a NVRAM erase (all or just the part with ``ZB_NVRAM_ZCL_REPORTING_DATA`` id).

Note that this is a way to avoid abnormal behavior, but the consequence is the loss of configuration data, i.e. the need to reconfigure the device.

**Workaround:** After the device has been upgraded, perform an NVRAM erase (all or just the part with ``ZB_NVRAM_ZCL_REPORTING_DATA`` ID).

This is a way to avoid abnormal behavior, but the consequence is the loss of configuration data and you need to reconfigure the device.

mariusz-nordicsemi · 2025-02-27T09:57:02Z

doc/nrf/releases_and_maturity/known_issues.rst

@@ -1532,6 +1532,22 @@ KRKNWK-12115: Simultaneous commissioning of many devices can cause the Coordinat
 KRKNWK-11826: Zigbee Router does not accept new child devices if the maximum number of children is reached
  Once the maximum number of children devices on a Zigbee Router is reached and one of them leaves the network, the Zigbee Router does not update the flags inside beacon frames to indicate that it cannot accept new devices.

+.. rst-class:: v2-9-0-nRF54H20-1-rc2 v2-9-0 v2-8-0 v2-7-0 v2-6-3 v2-6-2 v2-6-1 v2-6-0
+
+KRKNWK-19894: The Device Firmware Upgrade (DFU) from |NCS| 2.5 or older to a newer version may cause fatal error or abnormal behavior.


Shouldn't the issues be ordered by the ticket number? I think this issues should be placed as the first one with "KRKNWK-" prefix as the youngest one.

Ok, maybe that's how it should be, I didn't think of that. I'll move it to the right position, but I'll do it at the very end, after the other suggestions are resolved.

check the positioning rules and move the added element

I moved it. Now it's the first "KRKNWK-.." in the Zigbee section

mariusz-nordicsemi · 2025-02-27T09:57:51Z

doc/nrf/releases_and_maturity/known_issues.rst

+
+KRKNWK-19894: The Device Firmware Upgrade (DFU) from |NCS| 2.5 or older to a newer version may cause fatal error or abnormal behavior.
+
+   The issue occurs in the following conditions: the device initially uses FW built with |NCS| 2.5 or older, has configured ZCL Reporting feature (i.e. reports selected attributes),


Should be v2.5.0 (instead of v2.5)?

hmm .., wouldn't that be misleading, i.e. suggesting incorrectly that e.g. v2.5.0 is affected and v2.5.1 is not?
Or another idea - maybe using v2.5.x here would be more readable?

I decided to put v2.5.3. Please see comment

annwoj · 2025-02-27T11:11:06Z

doc/nrf/releases_and_maturity/known_issues.rst

+   The issue occurs when the device initially uses firmware built with the |NCS| v2.5 or older and has the ZCL Reporting feature enabled (which means it reports selected attributes).
+   The DFU is performed where the new firmware is built based on the |NCS| v2.6.0 or later.


Not sure if this update didn't affect the original meaning, please correct me if I'm wrong. But the action subsequence seems to be missing. Maybe we could say:

Suggested change

The issue occurs when the device initially uses firmware built with the |NCS| v2.5 or older and has the ZCL Reporting feature enabled (which means it reports selected attributes).

The DFU is performed where the new firmware is built based on the |NCS| v2.6.0 or later.

The issue occurs when the device initially uses firmware built with the |NCS| v2.5.0 or earlier, and has the ZCL Reporting feature configured (which means it reports selected attributes).

Subsequently, the DFU is performed where the new firmware is built based on the |NCS| v2.6.0 or later.

Also I think we should keep "configured" as it seems to relate to the part about selected attributes, but then again, I might be overinterpreting

applied, but using v2.5.3

Yes, good point about "configure" word. If we understand it as:

"configure" --> selects which attribute is to be included in the report, specifies the interval, specifies triggering method, ..

then this word will better reflect the situation.
("configure" restored)

annwoj · 2025-02-27T11:13:34Z

doc/nrf/releases_and_maturity/known_issues.rst

+   Most likely, this device condition prevents remote reconfiguration.
+   In some cases of cluster configuration, the firmware may encounter a fatal error every time it starts.
+
+   **Workaround:** After the device has been upgraded, perform an NVRAM erase (all or just the part with ``ZB_NVRAM_ZCL_REPORTING_DATA`` ID).


Suggested change

**Workaround:** After the device has been upgraded, perform an NVRAM erase (all or just the part with ``ZB_NVRAM_ZCL_REPORTING_DATA`` ID).

**Workaround:** After upgrading the device, perform an NVRAM erase (complete or specifically targeting the part with the ``ZB_NVRAM_ZCL_REPORTING_DATA`` ID).

annwoj · 2025-02-27T11:13:54Z

doc/nrf/releases_and_maturity/known_issues.rst

+   However, part of this content has a structure that is incompatible with the new firmware, leading to abnormal behavior.
+
+   The attribute reporting stops working.
+   The device sends the Report Attributes command very frequently, but the messages are corrupted (empty).


Suggested change

The device sends the Report Attributes command very frequently, but the messages are corrupted (empty).

The device frequently sends the Report Attributes command, but the messages are corrupted (empty).

annwoj · 2025-02-27T11:18:46Z

doc/nrf/releases_and_maturity/known_issues.rst

@@ -1532,6 +1532,24 @@ KRKNWK-12115: Simultaneous commissioning of many devices can cause the Coordinat
 KRKNWK-11826: Zigbee Router does not accept new child devices if the maximum number of children is reached
  Once the maximum number of children devices on a Zigbee Router is reached and one of them leaves the network, the Zigbee Router does not update the flags inside beacon frames to indicate that it cannot accept new devices.

+.. rst-class:: v2-9-0-nRF54H20-1-rc2 v2-9-0 v2-8-0 v2-7-0 v2-6-3 v2-6-2 v2-6-1 v2-6-0
+
+KRKNWK-19894: The Device Firmware Upgrade (DFU) from the |NCS| v2.5 or older to a newer version may cause fatal error or abnormal behavior


Suggested change

KRKNWK-19894: The Device Firmware Upgrade (DFU) from the |NCS| v2.5 or older to a newer version may cause fatal error or abnormal behavior

KRKNWK-19894: The Device Firmware Upgrade (DFU) from the |NCS| v2.5.0 or older to a newer version may cause fatal error or abnormal behavior

The problem affects each of 2.5.0, 2.5.1, 2.5.2, 2.5.3, so finally I decided to put v2.5.3. Please comment if you have a different opinion

Thanks, that makes perfect sense, since the 5.2.3 will be the newest in this context :)

I'm not sure about it. Putting v2.5.3 might make an impression that in this particular version there is sth specific (in comparison to v2.5.0, and v2.5.1 and v2.5.2). IMO v2.5.0 should be treated as equivalent to v2.5.x.
If there is a v2.5.4 released, would anyone update the description of this known issue?

If that's the case and the issue might be valid for the next release maybe we could just state it as a variable v2.5.X? Then the issue could say:
The Device Firmware Upgrade (DFU) from the |NCS| v2.5.X to a newer version may cause fatal error or abnormal behavior
I think leaving just 2.5.0 might be misleading

I agree, v2.5.X also looks good. I used that

annwoj

just some last suggestions for better flow

annwoj · 2025-02-27T13:10:29Z

doc/nrf/releases_and_maturity/known_issues.rst

+   In some cases of cluster configuration, the firmware may encounter a fatal error every time it starts.
+
+   **Workaround:** After upgrading the device, perform an NVRAM erase (complete or specifically targeting the part with the ``ZB_NVRAM_ZCL_REPORTING_DATA`` ID).
+   This is a way to avoid abnormal behavior, but the consequence is the loss of configuration data and you need to reconfigure the device.


Suggested change

This is a way to avoid abnormal behavior, but the consequence is the loss of configuration data and you need to reconfigure the device.

This method prevents abnormal behavior, but it leads to the loss of configuration data, requiring you to reconfigure the device.

annwoj · 2025-02-27T13:12:16Z

doc/nrf/releases_and_maturity/known_issues.rst

+
+   The attribute reporting stops working correctly.
+   The device frequently sends the Report Attributes command, but the messages are corrupted (empty).
+   Most likely, this device condition prevents remote reconfiguration.


Suggested change

Most likely, this device condition prevents remote reconfiguration.

This condition of the device likely prevents remote reconfiguration.

AdamZelikNS · 2025-02-28T08:03:34Z

I've noticed a bug in the built html : the header "KRKNWK-19894: The Device .." has incorrect formatting (not bold). I have no idea why. Does anyone know?

check and correct formatting

peknis · 2025-02-28T08:17:08Z

doc/nrf/releases_and_maturity/known_issues.rst

+.. rst-class:: v2-9-0-nRF54H20-1-rc2 v2-9-0 v2-8-0 v2-7-0 v2-6-3 v2-6-2 v2-6-1 v2-6-0
+
+KRKNWK-19894: The Device Firmware Upgrade (DFU) from the |NCS| v2.5.3 or older to a newer version may cause fatal error or abnormal behavior
+


Suggested change

The empty line broke the formatting.

thanks, removed the empty line, build in progress..

doc/nrf/releases_and_maturity/known_issues.rst

Add mention of possible ZCL Reporting configuration data incompatibility issue after performing DFU. Signed-off-by: Adam Zelik <adam.zelik@nordicsemi.no>

sonarqubecloud · 2025-02-28T15:15:55Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

AdamZelikNS requested a review from a team February 26, 2025 16:00

AdamZelikNS requested a review from a team as a code owner February 26, 2025 16:00

github-actions bot added doc-required PR must not be merged without tech writer approval. changelog-entry-required Update changelog before merge. Remove label if entry is not needed or already added. labels Feb 26, 2025

edmont approved these changes Feb 26, 2025

View reviewed changes

edmont requested a review from annwoj February 26, 2025 18:27

peknis requested changes Feb 27, 2025

View reviewed changes

mariusz-nordicsemi reviewed Feb 27, 2025

View reviewed changes

AdamZelikNS force-pushed the pr/krknwk19894_known_iss branch from 85adb39 to 470f4fa Compare February 27, 2025 11:07

annwoj reviewed Feb 27, 2025

View reviewed changes

AdamZelikNS force-pushed the pr/krknwk19894_known_iss branch 2 times, most recently from 70c57d0 to 2b2c140 Compare February 27, 2025 12:29

annwoj reviewed Feb 27, 2025

View reviewed changes

AdamZelikNS force-pushed the pr/krknwk19894_known_iss branch from 2b2c140 to 05ae673 Compare February 27, 2025 15:17

peknis requested changes Feb 28, 2025

View reviewed changes

annwoj reviewed Feb 28, 2025

View reviewed changes

doc/nrf/releases_and_maturity/known_issues.rst Outdated Show resolved Hide resolved

AdamZelikNS force-pushed the pr/krknwk19894_known_iss branch 2 times, most recently from d383f33 to 9619cad Compare February 28, 2025 10:48

annwoj approved these changes Feb 28, 2025

View reviewed changes

mariusz-nordicsemi approved these changes Feb 28, 2025

View reviewed changes

doc: zigbee: add known issue KRKNWK-19894

21a8ebd

Add mention of possible ZCL Reporting configuration data incompatibility issue after performing DFU. Signed-off-by: Adam Zelik <adam.zelik@nordicsemi.no>

AdamZelikNS force-pushed the pr/krknwk19894_known_iss branch from 9619cad to 21a8ebd Compare February 28, 2025 15:10

AdamZelikNS requested a review from peknis March 3, 2025 07:37

peknis approved these changes Mar 3, 2025

View reviewed changes

nordicjm merged commit c825401 into nrfconnect:main Mar 3, 2025
14 checks passed

	KRKNWK-19894: The Device Firmware Upgrade (DFU) from \|NCS\| 2.5 or older to a newer version may cause fatal error or abnormal behavior.
	KRKNWK-19894: The Device Firmware Upgrade (DFU) from the \|NCS\| v2.5 or older to a newer version may cause fatal error or abnormal behavior

		The issue occurs in the following conditions: the device initially uses FW built with \|NCS\| 2.5 or older, has configured ZCL Reporting feature (i.e. reports selected attributes),
		then DFU is performed where the new FW is built based on \|NCS\| 2.6.0 or later.

	During the upgrade, the NVRAM content is preserved. However, part of this content has a structure that is incompatible with the new FW, leading to abnormal behavior.
	During the upgrade, the NVRAM content is preserved.
	However, part of this content has a structure that is incompatible with the new firmware, leading to abnormal behavior.

		Workaround: After detecting that the device has been upgraded, perform a NVRAM erase (all or just the part with ``ZB_NVRAM_ZCL_REPORTING_DATA`` id).
		Note that this is a way to avoid abnormal behavior, but the consequence is the loss of configuration data, i.e. the need to reconfigure the device.

		The issue occurs when the device initially uses firmware built with the \|NCS\| v2.5 or older and has the ZCL Reporting feature enabled (which means it reports selected attributes).
		The DFU is performed where the new firmware is built based on the \|NCS\| v2.6.0 or later.

	Workaround: After the device has been upgraded, perform an NVRAM erase (all or just the part with ``ZB_NVRAM_ZCL_REPORTING_DATA`` ID).
	Workaround: After upgrading the device, perform an NVRAM erase (complete or specifically targeting the part with the ``ZB_NVRAM_ZCL_REPORTING_DATA`` ID).

	The device sends the Report Attributes command very frequently, but the messages are corrupted (empty).
	The device frequently sends the Report Attributes command, but the messages are corrupted (empty).

	This is a way to avoid abnormal behavior, but the consequence is the loss of configuration data and you need to reconfigure the device.
	This method prevents abnormal behavior, but it leads to the loss of configuration data, requiring you to reconfigure the device.

	Most likely, this device condition prevents remote reconfiguration.
	This condition of the device likely prevents remote reconfiguration.

		.. rst-class:: v2-9-0-nRF54H20-1-rc2 v2-9-0 v2-8-0 v2-7-0 v2-6-3 v2-6-2 v2-6-1 v2-6-0

		KRKNWK-19894: The Device Firmware Upgrade (DFU) from the \|NCS\| v2.5.3 or older to a newer version may cause fatal error or abnormal behavior

doc: zigbee: add known issue KRKNWK-19894 #20634

doc: zigbee: add known issue KRKNWK-19894 #20634

Conversation

AdamZelikNS commented Feb 26, 2025

NordicBuilder commented Feb 26, 2025 • edited Loading

CI Information

Inputs:

Sources:

Github labels

Outputs:

Toolchain

Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped; ⚠️ Quarantine

github-actions bot commented Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdamZelikNS Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annwoj Feb 27, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annwoj left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdamZelikNS commented Feb 28, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sonarqubecloud bot commented Feb 28, 2025

Quality Gate passed

NordicBuilder commented Feb 26, 2025 •

edited

Loading

github-actions bot commented Feb 26, 2025 •

edited

Loading

AdamZelikNS Feb 27, 2025 •

edited

Loading

annwoj Feb 27, 2025 •

edited

Loading

AdamZelikNS commented Feb 28, 2025 •

edited

Loading