• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 416 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

RTOS/CC2640R2F: In field device failures - crashes in Icall_init() in main.c

RTOS/CC2640R2F: Can power loss create data corruption, how to avoid?

Glenn Vassallo
Guru 21435 points
Part Number: CC2640R2F

Tool/software: TI-RTOS

Our CC2640R2 device is writing and reading data at regular intervals. The device runs from a coin cell battery that needs to be replaced at a regular interval.

Questions:

  1. Could data corruption occur if the device is in the middle of writing data to the CC2640R2 and power is lost, either by someone removing the battery or due to the battery running out of power?

  2. If data corruption can occur in these conditions, what are recommended coding practices to reduce the likelihood of data corruption due to power loss?

  • 0
    Guru 735685 points
    1. Yes
    2. I would suggest designing some mechenism to avoid battery remove arbitrarily. Another alternative is to use external EEPROM or Flash for sensor data storage to reduce or avoid chance to this kind of flash damage.
  • 0
    Guru 86755 points
    Hi Glenn,

    If you are writing to SNV with setting OSAL_SNV=1 data can be loss during reset. If you set OSAL_SNV=2, when the SNV gets full it will backup the data at RAM then write it back to SNV. Much better explanation can be found in the documentations.

    For battery, I set thresholds. If critical I put the device in Shutdown Mode. It is like the smart phone turning it self off when the battery level is critical.

    #define BATTERY_HIGH_THRESHOLD 3270
    #define BATTERY_MEDIUM_THRESHOLD 2800
    #define BATTERY_LOW_THRESHOLD 2250
    #define BATTERY_CRITICAL_THRESHOLD 1900

    -kel
  • 0 in reply to Markel Robregado
    Guru 86755 points

    Hi Glenn,

        I realized I mixed up my explanation. Anyway check the documentation regarding OSAL_SNV=1 and OSAL_SNV=2.

        "A compaction is the copying of valid data to a temporary area followed by an erase of the sector where the data was previously stored"

        OSAL_SNV=1 - The valid data is copied to RAM. So when a reset happens during this operation data can be lost.

        OSAL_SNV=1 - The valid data is copied to another area in internal flash, protecting data when reset happens during compaction

    -kel