Details on bug fix for Zigbee NVRAM in nRF Connect SDK v2.7.0

[anusha_bathala]

Hello Nordic Support,

I have a question related to the bug fix in nRF Connect SDK version 2.7.0, which is the following:

I would like to understand some details on what the implemented fix is. On checking this ticket https://devzone.nordicsemi.com/f/nordic-q-a/108665/zigbee-zboss-fatal-error-at-init, what I understand is that the fix is clearing zigbee NVRAM and restarting zigbee network. Can you please confirm if this is the fix done. The reason for asking this is:

We have a Zigbee coordinator application and when performing a zigbee NVRAM erase operation, some of the paired end devices cannot join the network back which is a problem for deployed sites. 

Can you please provide suggestions for avoiding or at least reducing the frequency of Zigbee NVRAM corruption in case of Nordic soft reboot or power reboot?

Regards,

Anusha

[Edvin]

Hello,

Roughly, yes.

The patch consists of categorizing NVRAM records into minor and major, and using a CRC to check for corruptions. If a minor record is corrupted it will be deleted, and if a major record is corrupted it will be reported to the application. Before, it would just fault on any error, causing a reboot loop.

So this patch would cause it to fail less frequently. It is part of the ZBOSS library, so it is not possible to add this from the application side, if that is what you are asking. The reboot loop happens inside the zboss stack, and there is no way to tell it to ignore the corrupted records.

Best regards,

Edvin

[anusha_bathala]

Hi Edvin,

Thanks for your response. I have some follow-up questions based on your response.

1. So, if I understand correctly, the bug fix is not erasing the full zigbee NVRAM data in case of corruption but only deletes specific corrupted record if it is a minor record. Is my understanding correct?

Edvin said:

and if a major record is corrupted it will be reported to the application.

2. What must the application do in such a case? If application does nothing, will this corrupted major record stay as it is? 

3. As part of the patch, are there any cases where the entire Zigbee NVRAM data is erased in case of corruption by ZBOSS stack? 

4. Can you please provide your recommendation for this? Note that our application also writes to flash but not to the zigbee NVRAM flash sections.

anusha_bathala said:

Can you please provide suggestions for avoiding or at least reducing the frequency of Zigbee NVRAM corruption in case of Nordic soft reboot or power reboot?

Looking forward to your response.

Regards,

Anusha

[Edvin]

Hello,

anusha_bathala said:

1. So, if I understand correctly, the bug fix is not erasing the full zigbee NVRAM data in case of corruption but only deletes specific corrupted record if it is a minor record. Is my understanding correct?

Correct.

anusha_bathala said:

2. What must the application do in such a case? If application does nothing, will this corrupted major record stay as it is? 

I believe it is handled by the libraries. I am not sure about the details here. I just read from some old message threads, but I believe it is handled by the application, rather than failing in the closed source ZBOSS library.

anusha_bathala said:

3. As part of the patch, are there any cases where the entire Zigbee NVRAM data is erased in case of corruption by ZBOSS stack? 

If it e.g. looses power at the wrong point in time, we can't guarantee that it will not need to be re-joined into the network because of corrupt network data, but it is not a common issue. But that is not what this patch is about. Before this, you could end up with a device that would never be able to join any network again, because it was stuck in a boot loop (and you would also not be able to update the FW on it, to get it out of the boot loop).

anusha_bathala said:

4. Can you please provide your recommendation for this? Note that our application also writes to flash but not to the zigbee NVRAM flash sections.

It should not be a problem that your application uses NVRAM. But I do remember that our Zigbee team recommended all customers to upgrade to v2.7.0 when it was released, so I suggest that you look into this (if you haven't already).

Best regards,

Edvin

[anusha_bathala]

Thanks, Edvin for your response. The patch details are clearer now. 

I just have one follow-up question. 

In general, what would be your recommended guidelines for application flash data management when the application uses zigbee?

Regards,

Anusha

[Edvin]

Hello Anusha,

Sorry for the late followup. Can you please be a little more precise?

In general, you should use the ZBOSS NVRAM API to store data to flash. This way, you ensure that it doesn't collide with anything in the Zigbee stack, but perhaps that wasn't your question?

Best regards,

Edvin