Data Loss Protection for Memory Systems and Devices

Abstract

A system, method, and device prevent data loss in a memory device. The system includes a non-volatile memory device, the non-volatile memory device including a first data unit configured to store data and associated metadata for the non-volatile memory device, and a second data unit configured to store data and associated metadata for the non-volatile memory device, the first data unit and the second data unit configured to alternately store the most recent versions of the data and associated metadata. The system further includes control circuitry capable of reading metadata from the first data unit and the second data unit, identifying the first data unit as an inactive data unit based on the contents of the first data unit and the second data unit, and performing one or more update operations such that the first data unit is updated and set as an active unit when the update operations are completed.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is an international application of U.S. utility application No. 18 / 379,331, filed October 12, 2023, and claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 63 / 449,644, filed March 3, 2023, which is incorporated herein by reference for all purposes.

[0002] The present disclosure relates generally to memory devices, and more particularly to preventing data loss in such memory devices. [Background technology]

[0003] A memory device may include various memory cells configured to store data values ​​according to a memory architecture. For example, such data values ​​may be included in a configuration registry, which may be stored, in one example, by being written or programmed using various word lines and bit lines. Special data, such as configuration data, may be stored in such memory devices and may be available during various operations of the memory device, such as powering up the device. Thus, such configuration data may undergo read operations when such data is read by the memory device, and write / program operations when updated data is received. Conventional memory devices remain limited in their ability to store and maintain such special data without being affected by unexpected system events, such as a power loss event. [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 illustrates an example of a memory device configured in accordance with some embodiments. [Figure 2]FIG. 1 illustrates an example of a memory system that may include a memory device configured in accordance with some embodiments. [Figure 3] 1 is a flowchart illustrating an example of a method for data protection performed in accordance with some embodiments. [Figure 4] 1 is a flowchart illustrating another example of a method for data protection performed in accordance with some embodiments. [Figure 5] 10 is a flowchart illustrating yet another example of a method for data protection performed in accordance with some embodiments. [Figure 6] 10 is a flowchart illustrating a further example of a method for data protection performed in accordance with some embodiments. [Figure 7] 10 is a flowchart illustrating yet another example of a method for data protection performed in accordance with some embodiments. [Figure 8] 1 is a flowchart illustrating another example of a method for data protection performed in accordance with some embodiments. [Figure 9] 1 is a flowchart illustrating another example of a method for data protection performed in accordance with some embodiments. [Figure 10A] FIG. 2 illustrates an example of an erase sector configured in accordance with some embodiments. [Figure 10B] FIG. 10 illustrates the progression of data contained in a data field during a special data update, according to some embodiments. [Figure 11] FIG. 10 illustrates the progression of data contained in data fields during certificate and firmware updates, according to some embodiments. [Figure 12] 1 is a flowchart illustrating another example of a method for data protection performed in accordance with some embodiments. [Figure 13] 1 is a flowchart illustrating another example of a method for data protection performed in accordance with some embodiments. [Figure 14]1 is a flowchart illustrating another example of a method for data protection performed in accordance with some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the presented concepts. The presented concepts may be practiced without some or all of these specific details. In other instances, well-known processing operations are not described in detail so as not to unnecessarily obscure the concepts being described. While some concepts will be described in conjunction with specific examples, it should be understood that these examples are not intended to be limiting.

[0006] A memory device may include portions configured to store special data used for system purposes. For example, certain portions of the memory device may be configured to store special data, such as a configuration registry. Such data may be used by the memory device at power-on and for various other system operations. Furthermore, such data may be periodically updated based on update data received at the memory device. For example, a memory device may receive data objects, also referred to herein as update data, that may include a data payload containing updates to such configuration registry data. In the context of security, such data may also include security certificate data structures used for validation purposes and firmware data structures that may be used to manage firmware, as will be described in more detail below.

[0007] Accordingly, one or more memory operations may be performed to implement such an update operation and ensure that the updates contained in the received update are implemented in the stored special data. However, during such an update operation, one or more events may occasionally occur unexpectedly. For example, a memory device may experience a power loss during such an update operation. In such an instance, the special data may become corrupted and unusable by the memory device, similar to the case of a corrupted configuration registry. Conventional techniques remain limited in addressing such power loss events because they often require additional dedicated hardware, such as an OTP (one-time programming) array, which cannot handle large volumes of requests. Therefore, conventional techniques are unable to efficiently and effectively provide data loss tolerance.

[0008] Embodiments disclosed herein provide at least two data units used to store special data and associated metadata, with one data unit designated as an active unit and the other data unit designated as an inactive unit. As described in more detail below, update operations and reset or erase operations can be managed so that previous data is maintained throughout the update process and deactivated only when the update is complete. The active and inactive data units can be switched as update operations are incremented. In this way, previous versions of the special data can be maintained even if a power loss event or other disruptive event occurs during the update operation. As also described in more detail below, one or more read operations can be performed to read data from the data units and to generate one or more messages identifying the status of the data units and whether one or more errors have been detected. Thus, embodiments can be implemented to provide data loss tolerance with or without the need for additional hardware, such as an additional memory array, and to provide specific messages regarding possible errors.

[0009] FIG. 1 illustrates an example of a memory device configured in accordance with some embodiments. Accordingly, a memory device such as device 100 may include memory cells stored in memory cell array 104. As described in more detail below, device 100 may be configured to manage the use of active and inactive data units to provide protection against data loss that might otherwise occur due to one or more system events, such as a power loss event. More specifically, device 100 may rotate active and inactive data units used to store sensitive and special data, such as configuration registry and credential data. Such use of active and inactive data units can ensure that a previous version of data is available if a power loss occurs while updating with new data.

[0010] In various embodiments, device 100 includes components that are implementable as one or more integrated circuits. More specifically, device 100 may include a memory module, such as memory 102. In various embodiments, memory 102 includes an input / output interface, such as I / O 114, that is configurable to facilitate communication with one or more other components of the memory system. Memory 102 further includes a controller 108 configured to perform various memory operations for device 100. As described in more detail below, such operations may include read, write, programming, and / or erase operations, which may be determined based on the type of memory included in device 100. Accordingly, controller 108 may include one or more processing elements configured to perform such operations. Such processing elements may be included in any suitably implemented processor and / or control circuitry. In some embodiments, controller 108 further includes a comparator 110 configured to perform one or more comparison operations that may be included in verifying one or more memory operations, such as verifying completion of the memory operation. In one example, the comparator 110 can be configured to compare an erase power loss indicator (EPLI) codeword programmed into the memory sector during an erase operation with a designated EPLI code to verify completion of the erase operation. Such designated EPLI code can be generated or stored within the controller 108. The memory 102 can also include array access circuitry 112 configured to provide the controller 108 with additional access to components of the memory 102.

[0011] In various embodiments, memory 102 also includes a memory cell array 104 configured to include rows and columns of memory cells. Depending on the configuration of memory 102, memory cell array 104 may have various sectors, such as sector 106, each of which may have an associated EPLI bit. In one example, memory cell array 104 may be configured as a flash memory device, such as a NOR flash memory. In this example, memory cell array 104 may include multiple erase sectors. In another example, memory cell array 104 is a resistive random access memory (RRAM) device, which does not have block or sector constraints. While the embodiments disclosed herein describe RRAM devices, it will be understood that any suitable type of non-volatile memory may be used. For example, any suitable single-bit switching scheme may be used herein. As described in more detail below, special data contained in memory cell array 104 may be stored and updated using associated active and inactive data units to provide immunity from power loss events.

[0012] 2 illustrates an example of a memory system that may include a memory device configured according to some embodiments. According to certain exemplary embodiments, system 200 may be suitable for implementing the various components described above, such as device 100 and the active and inactive data units described above and in detail below. In various embodiments, system 200 may include processor 201 that is configurable to implement one or more processing operations. For example, processor 201 is configurable to implement read and write operations and programming and erasing operations related to memory 102. System 200 may also include bus 215 that is configurable to enable communication between the various components of system 200.

[0013] In various embodiments, system 200 may further include memory 102, which may include a controller, as described above. Accordingly, memory 102 may be configurable to implement the active and inactive data units described above and in detail below. In various embodiments, processor 201 may be configurable to implement one or more memory operations. In this manner, system 200 may have a dedicated processing unit, such as processor 201, that is configurable to implement memory operations as disclosed herein. It will be appreciated that one or more components of processor 201 or the controller included in memory 102 may be implemented in an application-specific integrated circuit (ASIC) or in the reprogrammable logic of a field programmable gate array. In some embodiments, processor 201 may be implemented in a programmable system or controller that further includes a non-volatile memory device, such as a Programmable System On a Chip (PSoC™) controller, available from Cypress Semiconductor of San Jose, California, and Infineon Technologies of Neubiberg, Germany. In various embodiments, one or more components of system 200 may be implemented on the same circuit die and within the same package. For example, the processor 201 and the memory 102 can be implemented on the same circuit die. In some embodiments, they can be implemented on different dies and in different packages.

[0014] In various embodiments, communication interface 211 may be configured to transmit and receive data to other system components, or may be configured to transmit and receive packets or data segments over a network. For example, communication interface 211 may be communicatively coupled to a user interface device via a bus, such as bus 215, or via a communications network. As described above, communication interface 211 may be configured to receive data from such user interface devices, which may be included in a data processing system or computer system. In various embodiments, communication interface 211 may be a serial peripheral interface (SPI). In some embodiments, communication interface 211 may also include a data interface, such as one of an Ethernet interface, a frame relay interface, a cable interface, or a DSL interface. Additionally, various super-speed interfaces may be provided, such as a fast Ethernet interface, a gigabit Ethernet interface, an HSSI interface, a POS interface, or an FDDI interface. Generally, these interfaces may include ports appropriate for communication with an appropriate medium. In some cases, they may include an independent processor and, optionally, further volatile RAM.

[0015] 3 illustrates a flowchart of an example method for data protection performed in accordance with some embodiments. Accordingly, a method such as method 300 may be implemented to determine which update operations are appropriate for a memory device and to perform such update operations. More specifically, active and inactive data units may be managed based on the status of such data units and characteristics of the data being updated. In this manner, such use of active and inactive data units may ensure that previous versions of data are available if a power loss occurs during an update with new data. As described in more detail below, such data units may be implemented in conjunction with various memories, such as secure flash memories using a sector-based architecture.

[0016] Method 300 may perform operation 302, which may determine one or more update actions based on data associated with updating data values ​​stored in memory. In various embodiments, such update actions may be determined based on one or more update parameters, such as whether new data is included in the update and / or whether an error message was detected. Thus, the update parameters may be one or more data values ​​for identifying a condition that triggers the update action. Such update parameters may include data values ​​such as version data and validity code status indicators. As described in more detail below, a particular update action may be dynamically determined for each update based on such update parameters, thereby reducing unnecessary and redundant update actions.

[0017] The method 300 may perform operation 304, in which a data unit to be updated may be identified based at least in part on the determined update operation. Accordingly, the data unit to be updated may be identified based on the update parameters described above and one or more active / inactive identifiers. As described in more detail below, active and inactive data units may be identified by one or more flags or identifiers. For example, active units may be identified based on a designated validity code. Accordingly, during operation 304, a data field of the data unit may be used to identify an inactive identifier and the associated inactive data unit.

[0018] Method 300 may perform operation 306, in which one or more update operations may be performed based on the identified data units. In some embodiments, the one or more update operations may be performed on inactive data units, and the inactive data units may be set as active data units once the update is complete. Additionally, previously identified active units may be set as inactive data units. Thus, updates may be performed using inactive data units while previous versions of data are retained in active units and remain available in the event of a system event, such as a power loss.

[0019] 4 illustrates a flowchart of another example method for data protection performed in accordance with some embodiments. Accordingly, a method such as method 400 may be implemented to determine which update operations are appropriate for a memory device and to perform such update operations. As described in more detail below, active and inactive data units may be managed based on the status of such data units and the characteristics of the data being updated. In this manner, such use of active and inactive data units may ensure that a previous version of data is available if a power loss occurs during an update with new data.

[0020] Method 400 may perform operation 402, in which it may be determined whether the contents of the update include new data. In various embodiments, a data file or object may be received at a memory module, and the data object may include an update to be applied to special data in the memory module. As also described above, the special data may refer to configuration data, such as a configuration registry, or other system data. As disclosed herein, the special data may refer to any data for which an update operation is performed and which is also identified as being subject to power loss tolerance. Thus, such data may be system or device data used to manage the operation of the device according to one or more specifications and / or standards, and such data may be transparent to the user. Thus, depending on the type of memory, the update may include such special data and / or other data objects, such as firmware updates or certificates used for secure memory. During operation 402, the data included in the received data object may be compared to existing data stored in the memory to determine whether the data is the same or whether the received data object includes new data.

[0021] If it is determined that the data object includes new data, method 400 may proceed to operation 404, where an update operation may be performed to update the particular data with the new data included in the update. As described in more detail below, such an update operation may include management of data stored in inactive and active data units to complete the update while providing protection from system events such as power loss. More specifically, an inactive data unit may be updated and set as an active unit, while previous data stored in a previously active unit is retained for redundancy purposes and then set as an inactive data unit.

[0022] Returning to operation 402, if it is determined that no new data is present, method 400 may proceed to operation 406, where it may be determined whether an error indicator is present. Such a determination may be made based on status indicators associated with active data units. Accordingly, the status indicators may be examined to determine whether they identify errors that may have occurred during a power loss event. In some embodiments, such status indicators may trigger the generation of an error message or a separate flag or indicator. Accordingly, such additional messages may also be queried during operation 406. If it is determined that an error message is present, method 400 may proceed to operation 404, where an update operation is performed to ensure that valid data is entered and the error indicator is addressed.

[0023] If it is determined that no error messages are present, method 400 may proceed to operation 408, where a portion of the update operation may be performed. Thus, because the update does not include new data and no error messages are present, a portion of the update operation may be performed to avoid unnecessary repeated write / programming operations and extend the operational life of the memory device. For example, a portion of the update operation may include refreshing valid status indicators while not rewriting all of the data included in the update. Furthermore, avoiding unnecessary repeated write / programming operations may also improve command performance by increasing available resources and improving throughput associated with processing commands.

[0024] 5 illustrates a flowchart of yet another example method for data protection, performed in accordance with some embodiments. As described in more detail below, methods such as method 500 may be implemented to perform update operations on a memory device. More specifically, active and inactive data units may be managed based on the status of such data units and characteristics of the data being updated. In this manner, such use of active and inactive data units can ensure that a previous version of data is available if a power loss occurs during an update with new data.

[0025] Method 500 may perform operation 502, in which a first data unit may be identified. As also described above, the first data unit may be a currently active data unit included in a configuration register configured to store data, such as registry data or other special data. The first data unit may be identified as active based on a stored index value, such as a valid code status, and additional metadata, which may include status information, as described in more detail below. In one example, a counter included in a component, such as a controller, may increment a count based on an update operation. The data units may be memory locations included in a configuration register, each including multiple data fields, and may be identified as active or inactive based on a counter index and other metadata. In some embodiments, each data unit may include a count index field, a valid indicator field, and a data field configured to store data. Thus, one or more pairs of data units may be included in a configuration register having even and odd counter indices. During operation 502, in response to determining that an update is to be performed, a currently active data unit may be identified based on the current value and / or maximum count index of the counter, as well as one or more other data fields for determining a valid code status for identifying the active data unit.

[0026] The method 500 may perform an operation 504 in which a data value may be written to identify a first validity indicator. Thus, an active data unit may be identified, and the validity indicator of the active data unit may be refreshed, for example, by rewriting the validity indicator. In this manner, the validity of at least one version of the data is ensured.

[0027] The method 500 may perform an operation 506 in which a second data unit may be identified as inactive. In various embodiments, the second data unit may be a currently inactive data unit. The inactive data unit may currently have a lower count index and may have been used in a previous update operation. Thus, the inactive data unit may be identified based on the lower count index and other data fields used to determine valid code status or based on an associated pairing with an active data unit.

[0028] The method 500 may perform an operation 508 in which a data value for identifying the second validity indicator may be reset. Thus, the validity indicator field of the inactive data unit may be overwritten with one or more data values ​​for identifying the reset. As described in more detail below, the validity indicator may be set to this state during an update operation to indicate that an update is being performed.

[0029] The method 500 may perform an operation 510 in which the contents of the counter identifier to identify the increment may be written. Thus, the contents of the count index field may be overwritten with a new count index representing the increment to the current count value. For example, if the current count value is "n," the count index may be written to a value of "n+1."

[0030] Method 500 may perform operation 512, in which a data value containing the updated data may be written. Accordingly, the data field may be updated to include the new data included in the update. In this manner, the new data included in the update may be stored in the inactive data unit, while the previous version is maintained in the active data unit. Thus, if a power loss event occurs during method 500, the previous version of the data remains available and may be used if the power loss event corrupts and renders the new data unusable.

[0031] Method 500 may perform operation 514, in which a data value to identify a second valid indicator may be written. Thus, as also described above, the valid indicator may be changed from a reset code back to a valid code to indicate that the update is complete and the contents of the data unit are valid. Because the counter has been incremented, the inactive data unit has been set as an active data unit, and the active data unit identified during operation 502 has been set as an inactive data unit. Additional iterations of method 500 may be performed for subsequent update operations. In this manner, the data unit may toggle between inactive and active to provide redundancy of the data stored in the configuration register.

[0032] 6 illustrates a flowchart of an additional example of a method for data protection, performed in accordance with some embodiments. As described in more detail below, a method such as method 600 may be performed to read data values ​​from an active data unit. Additionally, as described in more detail below, method 600 may also be performed to identify one or more error conditions. Thus, the data read from the data unit may be used to determine whether a memory error exists and whether a power loss event has occurred.

[0033] Method 600 may perform operation 602 in which a validity indicator and a counter value may be read from a data unit. As also described above, one or more data units may be used to store special data and associated metadata, and such data units may be switched between active and inactive status to provide redundancy of storage and update operations. During operation 602, a validity indicator and a count value may be retrieved from each data unit.

[0034] Method 600 may perform operation 604, where it may be determined whether a valid, active data unit exists. Similarly, as described above, the count value may be used to identify an active data unit. Additionally, a system component, such as a controller, may retrieve a current count value from a counter, which may also be used for validation purposes. As described in more detail below with reference to Table 1, a data unit having a higher count value may be identified as an active unit, and its validity may be evaluated using the status of the validity indicator. More specifically, if both validity indicator codes do not store an acceptable validity code and / or if both validity indicator codes store an acceptable validity code but their respective counters differ by a value other than one, it may be determined that an active unit has not been reliably identified, and method 600 may proceed to operation 606, where an error message is generated indicating that an active data unit was not found and a memory error has occurred. If both validity indicator codes store an acceptable validity code and the counters differ by a value of one and / or if only one of the validity indicators is valid, method 600 may proceed to operation 608.

[0035] Thus, during operation 608, it may be determined whether the active data unit identifies an error. Thus, once an active data unit is identified, method 600 may determine whether the data unit itself contains an error. As described in more detail below with reference to Table 1, a lookup table may be used to determine whether an error exists based at least in part on the retrieved valid indicator and count value.

[0036] If it is determined that the data unit contains an error, method 600 may perform operation 610, where data may be loaded from the active data unit. Method 600 may proceed to operation 612, where it may be determined whether an error is detected in the data. If it is determined that an error exists in the data, method 600 may proceed to operation 606, where an error message is generated. If it is determined that no error exists in the data, method 600 may proceed to operation 614, where a message is generated to identify the power loss event.

[0037] Returning to operation 608, if it is determined that the data unit does not contain errors, method 600 may perform operation 616, where data may be loaded from the active data unit. Method 600 may proceed to operation 618, where it may be determined whether errors are detected in the data. If it is determined that there are errors in the data, method 600 may proceed to operation 606, where an error message is generated. If it is determined that there are no errors in the data, method 600 may terminate after successfully loading the data from the active data unit.

[0038] [Table 1]

[0039] As noted above, Table 1 provides a mapping between valid indicator and count values ​​and one or more output decisions, such as those made by a controller also described above. These decisions, as interpretations, may be used as valid code statuses as described above. In such cases, the value marked "Other" may be any set of data values, and the data field does not determine the status. Thus, such a lookup table can be used to map retrieved valid indicator and count values ​​to active data units and to determine whether an error has occurred.

[0040] FIG. 7 illustrates a flowchart of yet another example method for data protection, performed in accordance with some embodiments. As described in more detail below, a method such as method 700 may be implemented to perform refresh operations for a memory device. More specifically, the memory device may be a flash memory device in which data and memory operations, such as erase operations, are managed using erase sectors. Thus, as described in more detail below, active and inactive data units may be managed to ensure that previous versions of data are available when a power loss occurs, while adhering to erase sector-based operations determined based on the flash architecture. For example, data units may be implemented on an erase sector basis, such that different data units and associated data structures have independently programmable and erasable erase sectors. In one example, each erase sector may have 16 word lines, with the first word line reserved for metadata and the remaining word lines used for special data.

[0041] Method 700 may perform operation 702, in which a first erase sector may be identified as active. As also described above, the first erase sector may be a currently active erase sector configured to store data. In various embodiments, a particular erase sector may have multiple word lines, such as 16 word lines. Additional details regarding such word lines are described in more detail below with reference to FIG. 10A.

[0042] Thus, during operation 702, a first erase sector may be identified based on the valid code status, as also described above. In one example, a counter included in a component, such as a controller, may increment a count based on the update operation. Also as described above, each erase sector may include a count index field and a data field configured to store data. The erase sector may also include a version data field and a security data field. In various embodiments, one or more pairs of erase sectors may be included in a configuration register having even and odd counter indexes. During operation 702, in response to determining that an update is to be performed, a currently active erase sector may be identified based on one or more data fields usable to determine the valid code status, such as the current value of the counter and / or the maximum count index.

[0043] Method 700 may perform operation 704, in which a data value for identifying a first valid indicator may be programmed. Thus, active erase sectors may be identified, and the first valid indicators of the active erase sectors may be refreshed, for example, by reprogramming the valid indicator. In various embodiments, the valid indicator is a designated flag or bit string configured to be recognized by a system component, such as a controller, as an indicator of valid data following successful completion of a programming or erase operation. In some embodiments, the valid indicator may include a bit, such as an error power loss indicator bit.

[0044] Method 700 may perform operation 706, in which a second erase sector may be identified. In various embodiments, the second erase sector may be a currently inactive erase sector. The second erase sector may currently have a lower count index and may have been used in a previous update operation. Furthermore, the second erase sector may be included in a different erase sector than the first erase sector. Thus, the second erase sector may be identified based on the lower count index or based on its associated pairing with the first erase sector.

[0045] Method 700 may perform operation 708, in which a data value for identifying the second validity indicator may be reset. Thus, the validity indicator field of the second erased sector may be overwritten with one or more data values, such as all zeros. In various embodiments, such overwriting of data may be the beginning of an update process in which previously stored data is invalidated and destroyed by overwriting the data with a specified value, such as all zeros.

[0046] Method 700 may perform operation 710, in which a second erase sector may be erased. Thus, an erase operation may be performed on the second erase sector, and the second erase sector may be prepared to be reprogrammed with updated data. Additionally, one or more data fields, such as a count index field or a valid indicator field, may store a data value representative of a reset operation. For example, such fields may be erased with a data value of "FF." As described in more detail below, such indicators may be set to this state for the duration of the refresh operation and until overwritten to indicate that a refresh is being performed.

[0047] The method 700 may perform an operation 712 in which a counter identifier may be programmed to identify the increment. Thus, the contents of the count index field may be written to include a new count index representing the increment to the current count value. For example, if the current count is "n," the count index may be written to a value of "n+1."

[0048] Method 700 may perform operation 714, in which a data value containing the updated data may be programmed. Thus, the data field may be updated to include the new data included in the update. Additionally, the version data may also be updated. In this manner, the new data included in the update may be stored in the second erase sector, while the previous version is maintained in the first erase sector.

[0049] Method 700 may perform operation 716, in which a data value for identifying a second valid indicator may be programmed. Thus, as also described above, the valid indicator may change from a reset code to a valid code, thereby indicating that the update is complete and the contents of the second erase sector are valid. Because the counter has been incremented, the second inactive erase sector has been set as the active erase sector, and the first previously active erase sector identified during operation 702 has been set as the inactive erase sector. Additional iterations of method 700 may be performed for subsequent update operations. In this manner, the erase sectors may toggle between inactive and active to provide redundancy for data stored in the secure memory.

[0050] FIG. 8 illustrates a flowchart of another example method for data protection, performed in accordance with some embodiments. As described in more detail below, a method such as method 800 may be implemented to perform an update operation on a memory device, which may be a secure memory device. Accordingly, data stored in the memory device may include security data, such as a certificate data structure. Furthermore, the security data may also include a firmware data structure. Accordingly, the data may include the special data and its associated metadata, as well as the certificate data and firmware data, as previously described. As an example, during a firmware version update, both the firmware and certificate data structures may be updated. Accordingly, during a firmware version update, different iterations of the update procedure, such as those described in more detail below with reference to FIG. 9, may be performed for each type of data structure. As described in more detail below, active and inactive data units may be managed to comply with security standards to ensure that a previous version of the special data may be available in the event of a power loss.

[0051] In various embodiments, secure systems and devices are configured to securely store data and may store data according to one or more security constraints. For example, the most recent version of the data may be retained and older versions may be erased. Thus, there may be one valid sector. A previous version may be retained during the update process so that it is available in the event of a power loss event. Once the update process is complete, the previous version may be deleted.

[0052] Additionally, secure systems and devices may include a command counter that may be used to provide count metadata instead of a dedicated incremental counter. Thus, a count value may be obtained from the command counter during an update operation, but this need not be an incremental count value. Furthermore, a hash code may be used for the validity code, since special data in secure systems and devices is hashed for security purposes. As will be described in more detail below, such secure systems and devices may include various data types, such as certificates and firmware, each of which may have associated update operations.

[0053] Method 800 may perform operation 802, in which a first update operation related to a data certificate may be performed. As described in more detail below, the first update operation may be determined based on update data related to the data certificate. More specifically, during operation 802, a first update operation may be determined and implemented for a certificate data structure. As described in more detail below, the first update operation may be determined for a first data structure type, such as a certificate data structure, depending on the firmware version being updated. In various embodiments, version data may be stored in a metadata column. Thus, as described in more detail below with reference to at least FIG. 11 , additional metadata columns may be used to store data such as version data in connection with secure flash.

[0054] Method 800 may perform operation 804, in which a second update operation related to the firmware may be performed. As described in more detail below, the second update operation may be determined based on update data related to the firmware. More specifically, during operation 804, the second update operation may be determined and implemented for a firmware data structure. As described in more detail below, the second update operation may be determined for a second data structure type, such as a firmware data structure, depending on the firmware version being updated.

[0055] Method 800 may perform operation 806, where the secure data may be updated to activate the new version. Thus, new data included in the update may be used to update the secure data, and if included, new certificate and new firmware data structures may be activated. As also described above and in more detail below, activation of the updated data structures may be performed by updating a count value. More specifically, a secure memory location, which may be a separate memory area from that used for special data, may be updated to identify the updated version. For example, a version number in the secure memory location may be updated. In this example, the version number stored in the secure memory location matches the version number stored in the version data fields associated with the certificate and firmware data structures. When these versions match, the secure data is determined to be activated and is available for subsequent memory operations. When the stored version data matches, method 800 may proceed to operation 808.

[0056] Thus, during operation 808, one or more portions of the inactive data unit may be reset. In some embodiments, portions of the inactive data unit used to store certificates and firmware may be reset by writing a reset code or value, such as "FF," for example. Such resetting and overwriting of previous security data may be performed to comply with one or more security standards related to secure data storage.

[0057] 9 illustrates a flowchart of another example method for data protection, performed in accordance with some embodiments. As described in more detail below, a method such as method 900 can be implemented to perform an update operation on a memory device, which may be a secure memory device that may include security data such as a certificate data structure and a firmware data structure. As also described above, such an update operation can be performed for each of the certificate and firmware data. Thus, as described in more detail below, some iterations of method 900 can be performed for the certificate or other security validation data structure, and some other iterations of method 900 can be performed for the firmware of its respective data field.

[0058] Method 900 may perform operation 902, in which a validity indicator for an active data unit may be rewritten. In various embodiments, the validity indicator is a security or verification code calculated based at least in part on the content of a metadata data field of a first data unit that may currently be identified as the active data unit based, for example, on a command count value. In one example, the validity indicator may be a hash value calculated based on the content of the special data and its associated metadata. During operation 902, the hash value may be recalculated and rewritten for the active data unit to refresh the validity indicator for the first data unit.

[0059] Method 900 may perform operation 904, in which the data value of the inactive data unit may be reset. In various embodiments, resetting the inactive data unit confirms that a reset operation has been performed and ensures that only one active version of the special data exists, thereby complying with security standards. Thus, the second data unit may be identified as an inactive data unit, and the value of the second data unit may be reset. Thus, a designated reset code, such as "FF," may be written to both the metadata and the special data. It should be understood that any suitable reset code recognized by a system component, such as a memory controller, may be used to reset the data value.

[0060] Method 900 may perform operation 906, in which a counter value, version data, and update data may be written to the inactive data unit. Accordingly, during operation 906, a count value may be updated to identify the incremented value. As also described above, the count value may be obtained from the command counter. Furthermore, version data, such as a version included in the update data, may also be written to a corresponding field in the inactive data unit. In various embodiments, the version data identifies the version of special data included in the update. Furthermore, the special data included in the update may also be written as update data to a corresponding data field.

[0061] Method 900 may perform operation 908, in which the integrity of the data values ​​stored in the inactive data units may be verified. In various embodiments, the verification may be performed according to a verification and / or validation procedure defined by a security standard. For example, such a verification operation of data integrity may include inspection of an error detection code or some other data integrity data value determined and calculated according to the memory security standard.

[0062] Method 900 may perform operation 910, in which a validity indicator may be generated for the inactive data unit. Thus, as also described above, a hash value may be calculated and stored as the validity indicator for the inactive data unit. The hash value may be calculated based on newly updated data. Thus, the calculated hash value is also an updated validity indicator.

[0063] Method 900 may perform operation 912, where it may be determined whether the update further includes firmware or certificate data structures. Thus, operations 902-910 may be performed on the particular data, and operation 912 may be performed to determine whether additional update operations should be performed on both certificate and firmware data structures. This determination may be made based, among other things, on whether the update includes certificate or firmware data structures and may be made based on one or more identifiers included in the update configured to identify these types of data structures. Thus, the contents of the update may be analyzed, and if it is determined that the update does not include firmware or certificate data structures, method 900 may proceed to operation 914, where inactive data units may be reset and pointers may be updated to identify active data units.

[0064] If during operation 912 it is determined that the update includes a firmware or certificate data structure, method 900 may proceed to operation 916, where version data of the firmware or certificate may be verified. As described in more detail below, the version identified in the updated data may be compared to version data stored in a secure memory location. Thus, the firmware or certificate version data may be compared to version data stored in a secure memory location that provides reference version data for such comparison. If it is determined that the versions match, method 900 may proceed to operation 914, described above. If it is determined that the versions do not match, method 900 may end. As an example, a reset of the inactive data unit may occur after an additional update operation, which may be associated with another data structure, such as a different certificate, firmware, version, etc.

[0065] FIG. 10A illustrates an example erase sector configured in accordance with some embodiments. As described in more detail below, erase sector 1000 illustrates the storage of data, metadata, and special data in a flash memory device in which memory operations are managed using erase sectors. As shown in FIG. 10A , an erase sector such as erase sector 1000 may include multiple word lines configured to store data. In one example, erase sector 1000 includes 16 word lines. In some embodiments, first word line 1002 is configured to store metadata. For example, first word line 1002 may include a first data field 1004 configured to store a count value and a data field, such as second data field 1006, configured to store a valid indicator. Additionally, erase sector 1000 may include additional word lines, such as second word line 1008, configured to store data that may be subject to various refresh operations.

[0066] FIG. 10B illustrates the progression of data contained in a data field during a special data update, according to some embodiments. As described in more detail below, diagram 1030 illustrates an update operation related to a secure system in which the update includes new data, but not updated new versions related to firmware or certificates. More specifically, diagram 1030 illustrates data contained in a data field during a special data operation such as that described above with reference to FIG. 9. As shown in FIG. 10B, diagram 1030 illustrates a first data unit 1032 and a second data unit 1034. In this example, first data unit 1032 is the currently active data unit, and second data unit 1034 is the inactive data unit. During first operation 1036, a first validity indicator is rewritten for first data unit 1032, and second data unit 1034 is reset. Also as described above, the first validity indicator may be a calculated hash value. During second operation 1038, a count value for second data unit 1034 is incremented. During a third operation 1040, the version of the second data unit 1034 is updated. During a fourth operation 1042, special data included in the second data unit 1034 is updated. During a fifth operation 1044, a second validity indicator is written to the second data unit 1034, thereby activating the second data unit 1034. As described above, the second validity indicator may be a second hash value calculated based on the updated data. During a sixth operation 1046, the contents of the first data unit 1032 may be reset by writing a reset code to the contents of the first data unit 1032.

[0067] FIG. 11 illustrates a diagram of the progression of data contained in data fields during a certificate and firmware update, according to some embodiments. As described in more detail below, diagram 1100 illustrates an update operation associated with a secure system, where the update includes new versions of firmware and certificates. Thus, successive iterations of the update method are performed for each of the firmware and certificates, and data is not reset or erased until the end of each respective update method. More specifically, diagram 1100 illustrates data contained in data fields during a certificate and firmware operation, such as that described above with reference to FIG. 9. As shown in FIG. 11, diagram 1100 illustrates a first data unit 1102 and a second data unit 1104 for a certificate data structure. Diagram 1100 also illustrates a third data unit 1106 and a fourth data unit 1108 for a firmware data structure. In this example, first data unit 1102 is the currently active data unit for the certificate, and second data unit 1104 is the inactive data unit for the certificate. Additionally, the third data unit 1106 is a currently active data unit for the firmware, and the fourth data unit 1108 is an inactive data unit for the firmware.

[0068] Thus, during a first operation 1110, a first validity indicator is rewritten for the first data unit 1102 and the second data unit 1104 is reset. As also described above, the first validity indicator may be a calculated hash value. During a second operation 1112, a count value for the second data unit 1104 is incremented. During a third operation 1114, the version of the second data unit 1104 is updated. During a fourth operation 1116, the certificate included in the second data unit 1104 is updated. During a fifth operation 1118, a second validity indicator is written to the second data unit 1104. As described above, the second validity indicator may be a second hash value calculated based on the updated data.

[0069] Further, during a sixth operation 1120, a third validity indicator is rewritten for the third data unit 1106, and the fourth data unit 1108 is reset. As also described above, the third validity indicator may be a calculated hash value. During a seventh operation 1122, a count value for the fourth data unit 1108 is incremented. During an eighth operation 1124, the version of the fourth data unit 1108 is updated. During a ninth operation 1126, the firmware included in the fourth data unit 1108 is updated. During a tenth operation 1128, a fourth validity indicator is written to the fourth data unit 1108. As described above, the fourth validity indicator may be a hash value calculated based on the updated data.

[0070] As shown in FIG. 11 , diagram 1100 further illustrates a secure memory location, such as secure memory location 1130, configured to store a firmware version number that may be used as a reference version number for special data stored in a data unit. For example, during operation 1119, the version number stored in secure memory location 1130 may be compared to the version number of the second data unit 1104, and during operation 1129, the version number stored in secure memory location 1130 may be compared to the version number of the fourth data unit 1108. Such comparison operations may be performed to verify which data units have the correct version number and to activate data units with matching version numbers. In some embodiments, the version number included in secure memory location 1130 was last updated, thereby enabling data units to be activated via such an update. For example, the version numbers stored in second data unit 1104 and fourth data unit 1108 may have been updated to k+1 during operations 1114 and 1124, respectively. When the operation related to the data unit is completed, the version number stored in the secure storage location 1130 can be updated during operation 1132 so that the latest version number is stored in the secure storage location 1130, and the second data unit 1104 and the fourth data unit 1108 are activated since their respective version numbers match.

[0071] 12 illustrates a flowchart of another example method for data protection performed in accordance with some embodiments. As described in more detail below, a method such as method 1200 can be performed to identify an active data unit and read a data value from the active data unit. Additionally, as described in more detail below, method 1200 can also be performed to identify one or more error conditions, such as an active data unit not being identified. Thus, the data read from the data unit can be used to determine whether a memory error exists and whether a power loss event has occurred.

[0072] Method 1200 may perform operation 1202, where it may be determined whether the first validity indicator is correct. As also described above, the first validity indicator may be a first hash value stored in the first data unit. Thus, the first hash value may be recalculated and compared to the hash value stored in the first data unit. If it is determined that the first validity indicator was correctly calculated and stored, method 1200 may proceed to operation 1204.

[0073] Thus, during operation 1204, it may be determined whether the second validity indicator is correct. As also described above, the second validity indicator may be a second hash value stored in the second data unit. Thus, the second hash value may be recalculated and compared to the hash value stored in the second data unit. If it is determined that the second validity indicator was not correctly calculated and stored, method 1200 may proceed to operation 1206.

[0074] During operation 1206, it may be determined whether the data unit being analyzed includes a data structure related to firmware or a certificate. As also described above, this determination may be made based on known sector information, such as sector mapping. Thus, if it is determined that the data unit being analyzed is not related to firmware or a certificate, method 1200 may proceed to operation 1208, where a first data unit is identifiable as an active data unit and data may be read from the first data unit. Furthermore, if it is determined that the data unit being analyzed is related to firmware or a certificate, method 1200 may proceed to operation 1210.

[0075] Thus, during operation 1210, it may be determined whether the version of the firmware and / or certificate matches the version stored in the secure location, as described above. Thus, the versions may be compared to determine whether they match. If it is determined that the versions are the same, method 1200 may proceed to operation 1208, where the first data unit may be identified as an active data unit and data may be read from the first data unit. If it is determined that the versions do not match, method 1200 may perform operation 1212, where it may be determined that a valid active data unit was not found. Additionally, one or more error messages may be generated, also as described above.

[0076] Returning to operation 1204, if it is determined that the second validity indicator is correct, method 1200 may proceed to operation 1214, where it may be determined whether the analyzed data unit includes a data structure related to firmware or a certificate. As also described above, this determination may be made based on known sector information, such as sector mapping. Thus, if it is determined that the analyzed data unit is not related to firmware or a certificate, method 1200 may proceed to operation 1216, where the data unit having a higher count value may be identified as the active data unit. Data values ​​included in the active data unit may be refreshed for hardening purposes, and reset values ​​may be written to the inactive data unit. It should be understood that one or more additional read operations may be performed to read data from the active unit. Returning to operation 1214, if it is determined that the analyzed data unit is related to firmware or a certificate, method 1200 may proceed to operation 1218.

[0077] Thus, during operation 1218, it may be determined whether the data unit being analyzed is associated with firmware. As also discussed above, the data unit may be associated with firmware and / or a certificate, and during operation 1218, it may be determined whether it is specifically associated with firmware. As discussed above, this determination may be made based on known sector information. Thus, if it is determined that the data unit being analyzed is associated with firmware, method 1200 may proceed to operation 1220.

[0078] Thus, during operation 1220, it may be determined whether one of the firmware version numbers stored in the special data is the same as the version number stored in the corresponding secure storage location. If one of the firmware versions matches the version stored in the secure storage location, method 1200 may proceed to operation 1222, where the matching firmware version may be used to identify an active data unit and any suitable read operation may be performed. Additionally, data included in the active data unit may be hardened and a reset code may be written to the inactive data unit. If either or both of the firmware versions do not match, method 1200 may proceed to operation 1212, where an active data unit is not identified.

[0079] Returning to operation 1218, if it is determined that the data units are not associated with firmware, method 1200 may proceed to operation 1224, where it may be determined whether the versions of both data units match the version of the secure data, also referred to herein as special data. As also described above, this determination may be made based on retrieving and comparing the versions in different data structures. If it is determined that both versions do not match that of the special data, method 1200 may proceed to operation 1220, described above, to understand whether either one of the versions matches. If it is determined that both versions match, method 1200 may proceed to operation 1216, where any suitable read, hardening, and reset operations may be performed. In some embodiments, the data unit with the higher count value may also be identified as the active data unit.

[0080] Returning to operation 1202, if it is determined that the first validity indicator is incorrect, method 1200 may proceed to operation 1226, where it may be determined whether the second validity indicator is correct. As also described above, this determination may be made based on calculating and comparing hash values. If it is determined that the second validity indicator is incorrect, method 1200 may proceed to operation 1212, where an active data unit is not identified and one or more error messages may be generated.

[0081] If it is determined that the second validity indicator is correct, method 1200 may proceed to operation 1228, where it may be determined whether the data unit being analyzed includes a data structure related to firmware or a certificate. As also described above, this determination may be made based on known sector information, such as sector mapping. Thus, if it is determined that the data unit being analyzed is not related to firmware or a certificate, method 1200 may proceed to operation 1230, where the second data unit may be identified as an active data unit and data may be read from the second data unit. If it is determined that the data unit being analyzed includes a data structure related to firmware or a certificate, method 1200 may proceed to operation 1232.

[0082] Thus, during operation 1232, it may be determined whether the version of the firmware and / or certificate matches the version stored in the secure storage location. Thus, the versions may be compared to determine whether the versions match. If it is determined that the versions are the same, method 1200 may proceed to operation 1230, where the second data unit is identified as the active data unit and data may be read from the second data unit. If it is determined that the versions are not the same, method 1200 may proceed to operation 1212, where it may be determined that a valid active data unit was not found. Furthermore, one or more error messages may be generated, similarly as described above.

[0083] 13 illustrates a flowchart of another example method for data protection performed in accordance with some embodiments. As described in more detail below, a method such as method 1300 can be implemented to perform an update operation on a memory device, which may be a secure flash memory device. Accordingly, data stored in the memory device may include security data, such as a certificate data structure. Additionally, the security data may also include a firmware data structure. Accordingly, the data may include the special data and associated metadata as well as the certificate data and firmware data previously described. As described in more detail below, in the context of secure flash memory, additional metadata columns may be used for data such as version data, and different data structures may be implemented and managed in different memory sectors.

[0084] Method 1300 may perform operation 1302, in which a first update operation related to a data certificate may be performed. As described in more detail below, the first update operation may be determined based on update data related to the data certificate. More specifically, during operation 1302, the first update operation may be determined and implemented for a certificate data structure. As described in more detail below, the first update operation may be determined for a first data structure type, such as a certificate data structure, in response to a firmware version being updated.

[0085] Method 1300 may perform operation 1304, in which a second update operation related to the firmware may be performed. As described in more detail below, the second update operation may be determined based on update data related to the firmware. More specifically, during operation 1304, the second update operation may be determined and implemented for a firmware data structure. As described in more detail below, the second update operation may be determined for a second data structure type, such as a firmware data structure, in response to a firmware version being updated. In various embodiments, the firmware data structure is stored in a different memory sector than the certificate data structure.

[0086] Method 1300 may perform operation 1306, which may update the secure data and activate the new version. Thus, the new data included in the update may be used to update the secure data, and if included, new certificates and new firmware data structures. Similarly, as described above and in more detail below, version data associated with the updated data structure may be similarly updated to match the version data number stored in the secure memory location and used as a version number reference written into the metadata of the special structure. Once the updated version number matches the reference version number, the updated data structure may be activated.

[0087] Method 1300 may perform operation 1308, in which one or more inactive data sectors may be erased. In some embodiments, sectors of an inactive data unit used to store certificates and firmware may be reset, for example, by erasing the data unit. Such resetting and overwriting of previous security data may be performed to comply with one or more security standards related to secure data storage.

[0088] 14 illustrates a flowchart of another example method for data protection, performed in accordance with some embodiments. As described in detail below, methods such as method 1400 can be implemented to perform update operations on a memory device, which can be a secure flash memory device, which can include security data such as certificate data structures and firmware data structures. In various embodiments, the memory device can be a secure memory flash device that uses erase sectors for erase operations. Thus, method 1400 can be implemented to support secure data update operations in connection with flash memory.

[0089] Method 1400 may perform operation 1402, which may reprogram a validity indicator of an active data unit. As also described above, the validity indicator is a security or verification code calculated based at least in part on the contents of a metadata word line of a first data unit currently identifiable as an active data unit based, for example, on a command count value. In one example, the validity indicator may be a hash value calculated based on the special data and the contents of its associated metadata. During operation 1402, this hash value may be recalculated and reprogrammed into the active data unit to refresh the validity indicator of the first data unit. As also described above, in the context of a flash memory device, the data unit may be a data sector.

[0090] Method 1400 may perform operation 1404, in which sectors associated with inactive data units may be erased. As also described above, erasing the inactive data units confirms that an erase operation has been performed and ensures that only one active version of the particular data exists, thereby complying with security standards. Thus, the second data unit is identified as an inactive data unit, and the sector containing the inactive data unit may be erased. It should be understood that the active data unit may be implemented in a different sector. Thus, implementation of the erase command may erase both metadata and wordlines of data.

[0091] Method 1400 may perform operation 1406, in which a counter value, version data, and update data may be programmed into an inactive data unit. Accordingly, during operation 1406, the command count value may be updated to identify an incremented value. Furthermore, version data, such as a version included in the update data, may also be programmed into a corresponding field of the inactive data unit. In various embodiments, the version data identifies a version of the particular data included in the update. Furthermore, the particular data included in the update may also be programmed into a corresponding data field as updated data.

[0092] Method 1400 may perform operation 1408, in which the integrity of the data values ​​stored in the inactive data units may be verified. In various embodiments, the verification may be performed according to a verification and / or validation procedure defined by the security standard. For example, such verification operations for data integrity may include checking error detection codes or other data integrity data values ​​determined and calculated according to the memory security standard.

[0093] The method 1400 may perform operation 1410, in which a validity indicator for the inactive data unit may be generated. Thus, as also described above, a hash value may be calculated and programmed as the validity indicator for the inactive data unit. The hash value may be calculated based on the newly updated data. Thus, the calculated hash value is also an updated validity indicator.

[0094] Method 1400 may perform operation 1412, in which it may be determined whether the update includes updated data for firmware and / or certificate sectors. Thus, operations 1402-1410 may be performed for sectors containing special data, and operation 1412 may be performed to determine whether additional update operations should be performed for sectors associated with certificate and firmware data structures. This determination may be based, among other things, on whether the update includes certificate or firmware data structures, and may be based on one or more identifiers included in the update configured to identify these types of data structures. This determination may also be based on one or more sector identifiers. For example, sectors may be identified by the system as certificate sectors and firmware sectors, and such information may be stored in the system as a mapping or lookup table. In various embodiments, the target sectors of the update, determined based on one or more identifiers or address locations, may be used to determine whether update data should be programmed into any certificate or firmware sectors. Thus, the contents of the update can be analyzed, and if it is determined that the update does not include an update to firmware or certificate data, method 1400 can proceed to operation 1414 where the pointer is updated and the first data unit can be erased.

[0095] If during operation 1412 it is determined that the update includes an update to firmware or certificate data, method 1400 may proceed to operation 1416, where version data of the firmware or certificate data structure may be verified. As also described above, such verification may be performed based on whether the version number of the firmware or certificate matches a reference version number stored in a secure memory location. If it is determined that the version numbers match, method 1400 may proceed to operation 1414, described above. Additionally, if it is determined during operation 1416 that the update includes a new version number and the version numbers do not match, method 1400 may end.

[0096] Although the foregoing concepts have been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. It should be noted that there are many alternative ways of implementing processes, systems, and devices. Accordingly, the present examples are to be considered illustrative and not limiting.

Claims

1. 1. A system comprising a non-volatile memory device and control circuitry, The nonvolatile memory device a first data unit configured to store data and associated metadata of the non-volatile memory device; a second data unit configured to store data and associated metadata of the non-volatile memory device; wherein the first data unit and the second data unit are configured to alternately store the most recent version of data and associated metadata; The control circuit reading metadata from the first data unit and the second data unit; Identifying the first data unit as an inactive data unit based on content of the first data unit and the second data unit; configured to perform one or more update operations such that, when the update operations are completed, the first data unit is updated and set as an active unit. system.

2. The one or more update operations include: storing update data in the first data unit; incrementing a count value stored in the first data unit to determine that the first data unit is an active data unit; activating the first data unit; resetting the second data unit; Including, The system of claim 1 .

3. the update data is included in an update data object received by the control circuit; The system of claim 2.

4. the first data unit is identified based on a count value included in metadata stored in the first data unit and a count value included in metadata stored in the second data unit; The system of claim 1 .

5. the control circuitry is further configured to generate an error message in response to determining that no active data units exist. The system of claim 1 .

6. the control circuitry is further configured to generate an error message indicating that a power loss event has occurred. The system of claim 1 .

7. the data is configuration data including a certificate data structure and a firmware data structure; The system of claim 1 .

8. the certificate data structure and the firmware data structure each include version data and a validity indicator; The system of claim 7.

9. the validity indicator is a hash value calculated based at least in part on the metadata; The system of claim 8.

10. using control circuitry to read metadata from a first data unit and a second data unit, the first data unit and the second data unit storing data and associated metadata from a non-volatile memory device; using the control circuitry to identify the first data unit as an inactive data unit based on the contents of the first data unit and the second data unit; performing, using the control circuitry, one or more update operations such that, upon completion of the one or more update operations, the first data unit is updated and set as an active unit; A method comprising:

11. The one or more update operations include: storing update data in the first data unit; incrementing a count value stored in the first data unit to determine that the first data unit is an active data unit; activating the first data unit; resetting the second data unit; further comprising: The method of claim 10.

12. The step of identifying the first data as an inactive data unit comprises: extracting a count value included in the metadata stored in the first data unit and a count value included in the metadata stored in the second data unit; determining that the count value of the first data unit is less than the count value of the second data unit; further comprising: The method of claim 10.

13. The method further includes generating an error message indicating that a power loss event has occurred. The method of claim 10.

14. the data is configuration data including at least one of a certificate data structure and a firmware data structure; The method of claim 10.

15. the certificate data structure and the firmware data structure each include version data and a validity indicator, the validity indicator being a hash value calculated based at least in part on metadata; 15. The method of claim 14.

16. 1. A device comprising a non-volatile memory array and one or more processors, The non-volatile memory array comprises: a first data unit configured to store data and associated metadata of the non-volatile memory array; a second data unit configured to store data and associated metadata of the non-volatile memory array; wherein the first data unit and the second data unit are configured to alternately store the most recent version of data and associated metadata; The one or more processors: reading metadata from the first data unit and the second data unit; Identifying the first data unit as an inactive data unit based on content of the first data unit and the second data unit; configured to perform one or more update operations such that, when the one or more update operations are completed, the first data unit is updated and set as an active unit. device.

17. The one or more update operations include: storing update data in the first data unit; incrementing a count value stored in the first data unit to determine that the first data unit is an active data unit; activating the first data unit; resetting the second data unit; Including, 17. The device of claim 16.

18. the first data unit is identified based on a count value included in metadata stored in the first data unit and a count value included in metadata stored in the second data unit; 17. The device of claim 16.

19. the one or more processors are further configured to generate an error message indicating that a power loss event has occurred.

17. The device of claim 16.

20. the data is configuration data including a certificate data structure and a firmware data structure, the certificate data structure and the firmware data structure each including version data and a validity indicator, the validity indicator being a hash value calculated based at least in part on the metadata; 17. The device of claim 16.

Images