CC2652P: NV corruption during low-temperature test (battery powered)

Hi Shuyang,

We have added a 30-second update NV item function to our project to speed up the recurrence of the problem.

One of the devices had the same problem.
From the information on the NV page of the abnormal firmware, It can see that the last item on the first NV page is missing Item Hdr, but the NV Item stored last time is valid, but the device cannot be started at this point.

DW_fwBroken_writeNvTest_20210701_1.zip

Thanks,

Howjie

The low-voltage detection method will cause the device to behave inconsistently before and after the low-voltage threshold, which is not what customers expect to see.
This operation can be used as an alternative method.

Is there a better way to solve this problem?

Thanks,

Howjie

Howjie zhou said:

The low-voltage detection method will cause the device to behave inconsistently before and after the low-voltage threshold

Have you already tested this solution?  What is the abnormal effect of recovering from the low-voltage threshold and is it possible to reset the device after recovery to improve behavior?

The NVOCMP_initNvApi only returns success or a specific failure code, but it does not determine which specific NV item is corrupted.  Since this level of parse/detect is not provided, you may want to further determine the proper course of action through re-initializing (precautionary step, should return success if already created) and reading each NV item to detect whether an error is present.

Regards,
Ryan

If the NV system supports abnormal data repair, it is of course the best solution.
From the NV-related documents or comment, the NV system is designed to support these exception repairs.

We are already trying to enable low-voltage detection, but there is no test result yet.

According to our understanding, after enabling low voltage detection, the behavior of the device will be inconsistent due to this function.
Assuming that the low battery threshold is 2000mV, when the battery voltage value is greater than 2000mV, the device can store the data in NV, such as key information such as frame counter, channel, and panid.
When it is detected that the voltage is lower than 2000mV, since data storage cannot be performed, operations related to these key information will cause the equipment to work abnormally.

In addition, the effectiveness of the program may be affected by the following factors:
1. Under different manufacturers or ambient temperatures, the discharge curves of button cell are quite different;
2. Battery voltage detection algorithm;
3. The voltage of the button cell is extremely unstable when the battery is low, and whether there is still a risk during the long and time-consuming NV operation.

Of course, we can set a higher threshold in this solution. When the battery voltage is lower than this threshold, directly let the program enter while(1) until the battery is exhausted.

Thanks,

Howjie

How often does your application need to update NV memory?  Most low-power end nodes store network information during commissioning and afterwards rarely need to change or modify the stored NV settings.  It would be prudent to implement low battery fail prevention methods.

Regards,
Ryan

Currently, there is no data that needs to be stored frequently on our device.

If we do not consider the situation where the device joins the network again, the WWAHu and Frequency Agility functions on our device may be affected.

It seems that the low-battery check solution for the button cell usage scenario will introduce more abnormal situations to be solved, for example, when the NV is initialized, it is detected that the battery is insufficient.

We will try to fix this problem by ourselves in the future.

Thanks，

Howjie