Data loss protection for memory systems and devices

Abstract

Systems, methods, and devices for preventing data loss in a memory device. For example, a system may include a non-volatile memory device including a first data unit configured to store data of the non-volatile memory device and associated metadata, and a second data unit configured to store data of the non-volatile memory device and associated metadata, where the first data unit is configured to store data of the non-volatile memory device and the associated metadata, and the second data unit is configured to store data of the non-volatile memory device and the associated metadata. The first data unit and the second data unit are configured to alternately store the data and the latest version of the associated metadata. The system may also include control circuitry configured to: read metadata from the first data unit and the second data unit; identifying the first data unit as an inactive data unit based on contents of the first data unit and the second data unit; and performing 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.

Description

[0001] Cross - Reference to Related Applications

[0002] This application is an international application of U.S. non - provisional application Ser. No. 18 / 379,331, filed on Oct. 12, 2023, which claims the benefit of U.S. Provisional Patent Application Ser. No. 63 / 449,644, filed on Mar. 3, 2023, and the entire disclosure of the U.S. provisional application is incorporated herein by reference for all purposes. Technical Field

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

[0004] Memory devices can include various memory cells configured to store data values according to a memory architecture. For example, in one example, such data values can be stored by writing or programming using various word lines and bit lines. Special data such as configuration data in a configuration registry can be stored in such memory devices and can be used during various memory device operations (e.g., device power - on). Accordingly, when the memory device reads such configuration data, such data can undergo a read operation, and when updated data is received, such data can undergo a write / program operation. Traditional memory devices still have limited ability to store and maintain such special data in a manner that is not affected by unexpected system events such as power - off events. Brief Description of the Drawings

[0005] Figure 1 An example of a memory device configured according to some embodiments is shown.

[0006] Figure 2 An example of a memory system that can include a memory device configured according to some embodiments is shown.

[0007] Figure 3 A flowchart showing an example of a method for data protection performed according to some embodiments is shown.

[0008] Figure 4 A flowchart showing another example of a method for data protection performed according to some embodiments is shown.

[0009] Figure 5 A flowchart showing yet another example of a method for data protection performed according to some embodiments is shown.

[0010] Figure 6A flowchart showing additional examples of methods for data protection performed in accordance with some embodiments.

[0011] Figure 7 A flowchart showing yet another example of a method for data protection performed in accordance with some embodiments.

[0012] Figure 8 A flowchart showing another example of a method for data protection performed in accordance with some embodiments.

[0013] Figure 9 A flowchart showing another example of a method for data protection performed in accordance with some embodiments.

[0014] Figure 10A A diagram showing an example of an erased sector configured in accordance with some embodiments.

[0015] Figure 10B A diagram showing the progress of data included in a data field during an update of special data in accordance with some embodiments.

[0016] Figure 11 A diagram showing the progress of data included in a data field during an update of a certificate and firmware in accordance with some embodiments.

[0017] Figure 12 A flowchart showing another example of a method for data protection performed in accordance with some embodiments.

[0018] Figure 13 A flowchart showing another example of a method for data protection performed in accordance with some embodiments.

[0019] Figure 14 A flowchart showing another example of a method for data protection performed in accordance with some embodiments. Detailed Description

[0020] 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 described concepts. While some concepts will be described in conjunction with specific examples, it should be understood that these examples are not intended to be limiting.

[0021] A memory device may include portions configured to store special data for system purposes. For example, a particular portion of the memory device may be configured to store special data, such as, for example, a configuration registry. Such data may be used by the memory device upon power-up, as well as for various other system operations. Additionally, such data may be periodically updated based on updated data received at the memory device. For example, the memory device may receive a data object (also referred to herein as updated data), which may include a data payload that includes an update to such configuration registry data. As will be discussed in more detail below, in a secure environment, such data may also include a security certificate data structure for authentication purposes, as well as a firmware data structure that may be used to manage firmware.

[0022] Accordingly, one or more memory operations may be performed to effect such an update operation and ensure that the updates included in the received update are implemented in the stored special data. However, during such an update operation, one or more events may occur, sometimes unexpectedly. For example, during such an update operation, the memory device may experience a power loss. In such an example, the special data may be corrupted and unusable by the memory device, as may occur when the configuration registry is corrupted. Conventional techniques remain limited in dealing with such power loss events because they typically require additional dedicated hardware, such as, for example, a one-time programmable (OTP) array, and the dedicated hardware cannot handle a large number of requests. Accordingly, conventional techniques cannot provide data loss protection in an efficient and effective manner.

[0023] Embodiments disclosed herein provide at least two data units for storing special data and associated metadata, where one data unit is designated as an active unit and another data unit is designated as an inactive unit. As will be discussed in more detail below, update operations, as well as reset or erase operations, may be managed such that prior data is maintained through an update process and the prior data is deactivated only upon completion of the update. As update operations increase, the active data unit and the inactive data unit may switch back and forth. In this manner, in the event of a power loss event or other interrupt event during an update operation, a prior version of the special data may be maintained. As will also be discussed in more detail below, one or more read operations may be performed to read data from the data units and generate one or more messages identifying the state of the data units and whether one or more errors have been detected. Accordingly, the embodiments provide data loss protection, which may or may not require additional hardware, such as an additional memory array, and is implemented in a manner that provides specific messages regarding any errors that may occur.

[0024] Figure 1Shows an example of a memory device configured according to some embodiments. Thus, the memory device, such as device 100, may include memory cells stored in a memory cell array 104. As will be discussed in more detail below, device 100 may be configured to manage the use of active data units and inactive data units in such a way as to provide protection against data loss that may occur due to one or more system events, such as a power outage event. More specifically, device 100 may alternate the use of active data units and inactive data units for storing sensitive and special data, such as configuration registry or credential data. Such use of active data units and inactive data units can ensure that the previous version of the data is available in the event of a power outage during an update with new data.

[0025] In various embodiments, device 100 includes components that may be implemented as one or more integrated circuits. More specifically, device 100 may include a memory module, e.g., memory 102. In various embodiments, memory 102 includes an input / output interface, e.g., I / O 114, which may be configured to facilitate communication with one or more other components of the memory system. Memory 102 also includes a controller 108 configured to perform various memory operations of device 100. As will be discussed in more detail below, such operations may include read, write, program, and / or erase operations as may be determined based on the type of memory included in device 100. Thus, controller 108 may include one or more processing elements configured to perform such operations. Such processing elements may be included in a processor and / or control circuitry implemented in any suitable manner. In some embodiments, controller 108 additionally includes a comparator 110 configured to perform one or more comparison operations, which may be included in the verification of one or more memory operations, e.g., the verification of the completion of a memory operation. In one example, comparator 110 may be configured to compare an erase power loss indicator (EPLI) codeword programmed in a memory sector during an erase operation with a specified EPLI code to verify the completion of the erase operation. Such a specified EPLI code may be generated or stored within controller 108. Memory 102 may also include array access circuitry 112 configured to provide additional access to the components of memory 102 to controller 108.

[0026] In various embodiments, the memory 102 further includes a memory cell array 104 configured to include multiple rows and columns of memory cells. Depending on the configuration of the memory 102, the memory cell array 104 may have various sectors, such as sector 106, and each sector may have an associated EPLI bit. In one example, the memory cell array 104 may be configured as a flash memory device, e.g., a NOR flash memory. In this example, the memory cell array 104 may include multiple erase sectors. In another example, the memory cell array 104 is a resistive random access memory (RRAM) device and does not have block or sector constraints. Although the embodiments disclosed herein describe RRAM devices, it should be understood that any suitable type of non-volatile memory may be used. For example, any suitable single bit switching modality may be used herein. As will be discussed in more detail below, associated active data units and inactive data units may be used to store and update special data included in the memory cell array 104 in a manner that provides protection against power-off events.

[0027] Figure 2 An example of a memory system configured according to some embodiments that may include a memory device is shown. According to a particular example embodiment, the system 200 may be suitable for implementing the various components described above, e.g., the device 100 and the active data units and inactive data units described above and further described in detail below. In various embodiments, the system 200 may include a processor 201 configured to implement one or more processing operations. For example, the processor 201 may be configured to implement read and write operations, as well as programming and erase operations, associated with the memory 102. The system 200 may also include a bus 215 configured to enable communication between the various components of the system 200.

[0028] In various embodiments, system 200 may further include a memory 102, which, as discussed above, may include a controller. Thus, memory 102 may be configured to implement the active data unit and the inactive data unit discussed above and to be discussed in more detail below. In various embodiments, processor 201 may be configured to implement one or more memory operations. In this way, system 200 may have a dedicated processing unit, such as processor 201, that may be configured to implement the memory operations disclosed herein. It should be understood 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 reprogrammable logic of a field programmable gate array. In some embodiments, processor 201 may be implemented in a programmable system or controller that also includes a non-volatile memory device, such as a programmable system on a chip or PSoC commercially available from Cypress Semiconductor of San Jose, California, and Infineon Technologies of Neubiberg, Germany. TM Controller. In various embodiments, one or more components of system 200 may be implemented on the same circuit die and in the same package. For example, processor 201 and memory 102 may be implemented on the same circuit die. In some embodiments, processor 201 and memory 102 may be implemented on different dies and in different packages.

[0029] In various embodiments, communication interface 211 may be configured to send and receive data to and from other system components or may be configured to send and receive packets or data segments over a network. For example, communication interface 221 may be communicatively coupled to a user interface device via a bus such as bus 215 or via a communication network. As discussed above, communication interface 212 may be configured to receive data from such a user interface device that may be included in a data processing system or a 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, and a DSL interface. Additionally, various very high-speed interfaces may be provided, such as a Fast Ethernet interface, a Gigabit Ethernet interface, a HSSI interface, a POS interface, an FDDI interface, etc. Generally, these interfaces may include ports suitable for communicating with an appropriate medium. In some cases, these interfaces may also include a separate processor and, in some cases, may also include volatile RAM.

[0030] Figure 3A flowchart showing an example of a method for data protection performed according to some embodiments is shown. Accordingly, a method such as method 300 can be executed to determine which update operations are suitable for a memory device and to perform such update operations. More specifically, active data units and inactive data units can be managed based on the state of such data units and the characteristics of the data being updated. In this way, the use of active data units and inactive data units in this manner can ensure that the previous version of the data is available in the event of a power failure during an update with new data. As will be discussed in more detail below, such data units can be implemented in various memory environments such as secure flash memories using a sector-based architecture.

[0031] Method 300 can perform operation 302, during which one or more update operations can be determined based on data associated with an update of a data value stored in a memory. In various embodiments, such update operations can 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 has been detected. Thus, an update parameter can be one or more data values that identify the conditions that trigger an update operation. Such update parameters can include data values such as version data and a valid code status indicator. As will be discussed in more detail below, specific update operations can be dynamically determined based on such update parameters for each update, thereby reducing unnecessary repeated update operations.

[0032] Method 300 can perform operation 304, during which the data units to be updated can be identified at least in part based on the determined update operations. Thus, the data units to be updated can be identified based on the update parameters discussed above and one or more active / inactive identifiers. As will be discussed in more detail below, active data units and inactive data units can be identified by one or more flags or identifiers. For example, active units can be identified based on a specified valid code. Thus, during operation 304, the data fields of the data units can be used to identify the inactive identifiers and their associated inactive data units.

[0033] Method 300 can perform operation 306, during which one or more update operations can be performed based on the identified data units. In some embodiments, one or more update operations can be performed on the inactive data units, and once the update is complete, the inactive data unit can be set to an active data unit. In addition, the previously identified active unit can be set to an inactive data unit. Thus, the inactive data units can be used to perform the update while the previous version of the data is retained and remains available in the active unit in the event of a system event such as a power failure.

[0034] Figure 4A flowchart showing another example of a data protection method performed according to some embodiments is presented. Thus, a method such as method 400 can be executed to determine which update operations are suitable for a memory device and to perform such update operations. As will be discussed in more detail below, active data units and inactive data units can be managed based on the state of such data units and the characteristics of the data being updated. In this way, the use of active data units and inactive data units in this manner can ensure that the previous version of the data is available in the event of a power failure during an update with new data.

[0035] Method 400 can perform operation 402, during which it can be determined whether the content of the update includes new data. In various embodiments, a data file or object can be received at a memory module, and the data object can include an update to special data to be applied to the memory module. As discussed similarly above, special data can refer to configuration data such as a configuration registry or other system data. As disclosed herein, special data can refer to any data that undergoes an update operation and has also been identified as being subject to power failure protection. Thus, such data can be system or device data for managing the operation of a device according to one or more specifications and / or standards, and such data can be transparent to the user. Thus, depending on the type of memory, the update can include such special data and / or other data objects, e.g., certificates and firmware updates for secure memory. During operation 402, the data included in the received data object can be compared with the existing data stored in the memory to determine whether the data is the same or to determine whether the received digital object includes new data.

[0036] If it is determined that the data object includes new data, method 400 can proceed to operation 404, during which an update operation can be performed to update the special data with the new data included in the update. As will be discussed in more detail below, such an update operation can include managing the data stored in inactive data units and active data units to complete the update while providing protection against system events such as power failure. More specifically, an inactive data unit can be updated and set as an active unit, while the previous data stored in the previously active unit is retained for redundancy purposes and then the unit is set as an inactive data unit.

[0037] Return to operation 402. If it is determined that no new data exists, method 400 may proceed to operation 406. During operation 406, it may be determined whether an error indicator exists. Such a determination may be made based on a status indicator associated with the active data unit. Thus, the status indicator may be checked to determine whether it identifies an error, such as an error that may occur during a power-off event. In some embodiments, such a status indicator may trigger the generation of an error message or a separate flag or indicator. Thus, during operation 406, such an additional message may also be queried. If it is determined that an error message exists, method 400 may proceed to operation 404, where an update operation is performed to ensure that valid data has been entered and the error indicator has been processed.

[0038] If it is determined that no error message exists, method 400 may proceed to operation 408. During operation 408, a portion of the update operation is performed. Accordingly, since the update does not include new data and no error message exists, a portion of the update operation may be performed to avoid repeating unnecessary write / program operations and to extend the operating life of the memory device. For example, a portion of the update operation may include refreshing the valid status indicator without rewriting all of the data included in the update. Additionally, since avoiding the repetition of unnecessary write / program operations increases the available resources and throughput associated with processing commands, the command performance may also be improved.

[0039] Figure 5 A flowchart illustrating another example of a method for data protection performed in accordance with some embodiments is shown. As will be discussed in more detail below, a method such as method 500 may be performed to implement an update operation of a memory device. More specifically, the active data units and the 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, the use of active data units and inactive data units in this way may ensure that the previous version of the data is available in the event of a power-off during an update with new data.

[0040] Method 500 may perform operation 502, during which a first data unit may be identified. As discussed similarly above, the first data unit may be a currently active data unit included in a configuration register that is configured to store data such as registry data or other special data. As will be discussed in more detail below, the first data unit may be identified as active based on a stored index value such as a valid code state and additional metadata that may include status information. In one example, a counter included in a component such as a controller may be incremented based on an update operation. A data unit may be a storage location included in a configuration register that may each include 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 indexes. During operation 502, in response to determining that an update is to be performed, the currently active data unit may be identified based on the current value of the counter and / or the highest count index and one or more other data fields for determining a valid code state for identifying the active data unit.

[0041] Method 500 may perform operation 504, during which a data value identifying a first valid indicator may be written. Accordingly, the active data unit may be identified, and the valid indicator of the active data unit may be refreshed, for example, by rewriting the valid indicator. In this way, the validity of at least one version of the data may be ensured.

[0042] Method 500 may perform operation 506, during 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 for a previous update operation. Thus, the inactive data unit may be identified based on the lower count index and other data fields for determining a valid code state or based on its associated pairing with the active data unit.

[0043] Method 500 may perform operation 508, during which a data value identifying a second valid indicator may be reset. Accordingly, the valid indicator field of the inactive data unit may be rewritten with one or more data values identifying the reset. As will be discussed in more detail below, the valid indicator may be set to this state during the duration of an update operation to indicate that an update is being performed.

[0044] Method 500 may perform operation 510, during which the content of the counter identifier may be written to identify an increment. Accordingly, the content of the count index field may be rewritten with a new count index representing the increment of the current count value. For example, if the current count is "n", the value "n+1" may be written to the count index.

[0045] Method 500 may perform operation 512, during which a data value including updated data may be written. Accordingly, the data field may be updated to include the new data included in the update. In this way, 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 failure event occurs during method 500, the previous version of the data remains available, such that the previous version of the data may be used in case the new data is corrupted and becomes unavailable due to the power failure event.

[0046] Method 500 may perform operation 514, during which a data value identifying a second valid indicator may be written. Thus, as similarly discussed above, the valid indicator may change from the reset code back to the valid code, thereby indicating that the update is complete and the content of the data unit is valid. Since the counter has been incremented, the inactive data unit is now set as the active data unit, and the active data unit identified during operation 502 is now set as the inactive data unit. Additional iterations of method 500 may be performed for subsequent update operations. In this way, the data unit may switch back and forth between inactive and active to provide redundancy for the data stored in the configuration register.

[0047] Figure 6 A flowchart showing additional examples of a method for data protection performed according to some embodiments is shown. As will be discussed in more detail below, a method such as method 600 may be performed to read a data value from an active data unit. Additionally, as will be discussed in more detail below, method 600 may also be performed to identify one or more error states. Thus, the data read from the data unit may be used to determine whether a memory error exists and whether a power failure event has occurred.

[0048] Method 600 may perform operation 602, during which a valid indicator and a counter value may be read from the data unit. As similarly discussed above, one or more data units may be used to store special data and associated metadata, and such data units may switch between active and inactive states to provide redundancy for storage and update operations. During operation 602, the valid indicator and the count value may be retrieved from each data unit.

[0049] Method 600 may perform operation 604, during which it may be determined whether there is a valid active data unit. As discussed similarly above, a count value may be used to identify the active data unit. Additionally, system components such as a controller may also retrieve the current count value from a counter that may also be used for verification purposes. As will be discussed in more detail below with reference to Table 1, a data unit with a higher count value may be identified as an active unit, and the status of its valid indicator may be used to evaluate its validity. More specifically, if neither of the two valid indicator codes stores an acceptable valid code, and / or if both of the two valid indicator codes store an acceptable valid code but their counters differ by a value other than 1, it may be determined that no active unit can be reliably identified, and method 600 may proceed to operation 606, where an error message indicating that no active data unit has been found and a memory error has occurred is generated. If both of the two valid indicator codes store an acceptable valid code and their counters differ by a value of 1, and / or if only one of the valid indicators is valid, method 600 may proceed to operation 608.

[0050] Accordingly, during operation 608, it may be determined whether the active data unit is identified incorrectly. Once the active data unit has been identified, method 600 may determine whether the data unit itself includes any errors. As will be discussed in more detail below with reference to Table 1, a lookup table may be utilized to determine whether there are errors based at least in part on the retrieved valid indicator and count value.

[0051] If it is determined that the data unit includes an error, method 600 may perform operation 610, during which 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 there is an error in the data, method 600 may proceed to operation 606, where an error message is generated. If it is determined that there is no error in the data, method 600 may proceed to operation 614, where a message identifying a power-off event is generated.

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

[0053]

[0054] Table 1

[0055] As shown above, Table 1 shows the mapping of valid indicators and count values to one or more output decisions made by, for example, a controller, as similarly discussed above. These decisions (also referred to as specifications above) can be used as the valid code states discussed above. The values labeled "other" can be any set of data values because in this case, these data fields do not determine the state. Thus, such a lookup table can be used to map the retrieved valid indicator values and count values to decisions regarding active data units and whether an error has occurred.

[0056] Figure 7 A flowchart showing another example of a method for data protection performed in accordance with some embodiments is shown. As will be discussed in more detail below, a method such as method 700 can be performed to implement an update operation of a memory device. More specifically, the memory device can be a flash memory device that manages data and memory operations such as erase operations using erase sectors. Thus, as will be discussed in more detail below, active data units and inactive data units can be managed in a manner that ensures the availability of a previous version of the data in the event of a power outage while conforming to erase-sector-based operations determined according to the flash memory architecture. For example, data units can be implemented on the basis of erase sectors such that different data units and associated data structures have different erasable sectors that can be independently programmed and erased. In one example, each erase sector can have 16 word lines, where the first word line is reserved for metadata and the remaining word lines are for special data.

[0057] Method 700 can perform operation 702, during which the first erase sector can be identified as active. As similarly discussed above, the first erase sector can be the currently active erase sector configured to store data. In various embodiments, a particular erase sector can have a number of word lines, for example, 16 word lines. Other details regarding such word lines will be discussed in more detail below with reference to Figure 10A Other details regarding such word lines will be discussed in more detail below.

[0058] Accordingly, during operation 702, as discussed similarly above, the first erasure sector can be identified based on the valid code state. In one example, a counter included in a component such as a controller can be incremented based on an update operation. As discussed similarly above, each erasure sector can include a count index field and a data field configured to store data. The erasure sector can also include a version data field and a security data field. In various embodiments, one or more pairs of erasure sectors can be included in a configuration register having even and odd counter indices. During operation 702, in response to determining that an update is to be performed, the currently active erasure sector can be identified based on one or more data fields that can be used to determine the valid code state, such as the current value of the counter and / or the highest count index.

[0059] Method 700 can perform operation 704, during which the data value identifying the first valid indicator can be programmed. Accordingly, the active erasure sector can be identified, and the first valid indicator of the active erasure sector can be refreshed, for example, by reprogramming the valid indicator. In various embodiments, the valid indicator is a specified flag or bit sequence configured to be recognized by a system component, such as a controller, as an indicator of valid data after a successful programming or erasure operation. In some embodiments, the valid indicator can include multiple bits, for example, an error power-down indicator bit.

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

[0061] Method 700 can perform operation 708, during which the data value identifying the second valid indicator can be reset. Accordingly, the valid indicator field of the second erasure sector can be rewritten with one or more data values, such as all zeros. In various embodiments, such data rewriting can be the start of an update process, in which any previously stored data is invalidated and destroyed by rewriting it with a specified value, such as all zeros.

[0062] Method 700 may perform operation 710, during which a second erase sector may be erased. Accordingly, an erase operation may be performed on the second erase sector, and the second erase sector may be readied to be reprogrammed with updated data. Additionally, one or more data fields such as a count index field and a valid indicator field may store data values representing a reset operation. For example, such fields may be erased with the data value "FF". As will be discussed in more detail below, such an indicator may be set to this state during the duration of the update operation until it is rewritten to indicate that an update is being performed.

[0063] Method 700 may perform operation 712, during which a counter identifier may be programmed to identify an increment. Accordingly, the content of the count index field may be written to include a new count index representing an increment of the current count value. For example, if the current count is "n", the count index may be written the value "n+1".

[0064] Method 700 may perform operation 714, during which data values including the updated data may be programmed. Accordingly, the data fields may be updated to include the new data included in the update. Additionally, the version data may also be updated. In this way, 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.

[0065] Method 700 may perform operation 716, during which data values identifying a second valid indicator may be programmed. Thus, as similarly discussed above, the valid indicator may change back from the reset code to the valid code, thereby indicating that the update is complete and the content of the second erase sector is valid. Since the counter has been incremented, the second inactive erase sector is now set as the active erase sector, and the previously active first erase sector identified during operation 702 is now set as the inactive erase sector. Additional iterations of method 700 may be performed for subsequent update operations. In this way, the erase sectors may be toggled back and forth between inactive and active to provide redundancy for the data stored in the secure memory.

[0066] Figure 8A flowchart is shown that illustrates another example of a data protection method performed in accordance with some embodiments. As will be discussed in more detail below, a method such as method 800 may be performed to implement an update operation for a memory device that may be a secure memory device. Accordingly, the data stored in the memory device may include secure data, such as a certificate data structure. In addition, the secure data may also include a firmware data structure. Thus, the data may include the previously described special data and its associated metadata, as well as certificate data and firmware data. In one example, during a firmware version update, both the firmware data structure and the certificate data structure may be updated. Thus, different iterations of an update process (e.g., the update process discussed in more detail below with reference to Figure 9 may be performed for each data structure type during a firmware version update. As will be discussed in more detail below, active data units and inactive data units may be managed to ensure that a previous version of the special data can be obtained in a manner compliant with security standards in the event of a power loss.

[0067] In various embodiments, the secure system and device are configured to securely store data and may store data in accordance with 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 an active sector. The previous version may be retained during an update process to make it available in the event of a power loss event. At the end of the update process, the previous version may be deleted.

[0068] In addition, the secure system and device may include a command counter that may be used to provide count metadata instead of a dedicated increment counter. Thus, a count value may be obtained from the command counter during an update operation, and the count value may not be an incrementing count value. Further, since the special data of the secure system and device is hashed for security purposes, a hash code may be used as a valid code. As will be discussed in more detail below, various data types may be included in such a secure system and device, e.g., certificates and firmware that may each have an associated update operation.

[0069] Method 800 may perform operation 802, during which a first update operation associated with a data certificate may be performed. As will be discussed in more detail below, the first update operation may be determined based on update data associated with the data certificate. More specifically, during operation 802, a first update operation may be determined and implemented for the certificate data structure. As will be discussed in more detail below, the first update operation may be determined in response to the firmware version being updated and for a first data structure type, such as the certificate data structure. In various embodiments, version data may be stored in a metadata column. Thus, as will be at least referred to Figure 11As discussed in more detail, in a secure flash environment, additional metadata columns can be used to store data such as version data.

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

[0071] Method 800 may perform operation 806, during which the security data may be updated to activate a new version. Accordingly, the security data may be updated with new data included in the update, and if new data is included, new certificates and new firmware data structures may be activated. As similarly discussed above and will be discussed in more detail below, the activation of the updated data structure may be performed by updating a count value. More specifically, the secure storage location may be updated to identify the updated version, which may be a storage area different from the storage area used for special data. For example, the version number in the secure storage location may be updated. In this example, the version number stored in the secure storage location will match the version number stored in the version data field associated with the certificate data structure and the firmware data structure. In the case of these versions matching, the security data is determined to be activated and may be used for subsequent memory operations. Once the stored version data matches, method 800 may proceed to operation 808.

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

[0073] Figure 9A flowchart showing another example of a method for data protection performed in accordance with some embodiments is shown. As will be discussed in more detail below, a method such as method 900 can be performed to implement an update operation of a memory device, which can be a secure memory device and can include, for example, secure data such as certificate data structures and firmware data structures. As similarly discussed above, such an update operation can be performed for each of the certificate and the firmware data. Thus, as will be discussed in more detail below, an iteration of a portion of method 900 can be performed for the certificate or other secure verification data structure, and another iteration of a portion of method 900 can be performed for the firmware in its corresponding data fields.

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

[0075] Method 900 can perform operation 904, during which the data value in the inactive data unit can be reset. In various embodiments, resetting the inactive data unit confirms that the reset operation has been performed and ensures that only one active version of the special data exists, thus complying with the security standard. Thus, the second data unit can be identified as the inactive data unit, and the value of the second data unit can be reset. Accordingly, both the metadata and the special data can be written with a specified reset code, such as "FF". It should be understood that any suitable reset code recognized by system components such as a memory controller can be used for the reset data value.

[0076] Method 900 can perform operation 906, during which the counter value, version data, and update data can be written into the inactive data unit. Thus, during operation 906, the count value can be updated to identify an incremented value. As similarly discussed above, the count value can be obtained from the command counter. In addition, the version data included in the update data, such as a version, can also be written into its corresponding field in the inactive data unit. In various embodiments, the version data identifies the version of the special data included in the update. In addition, the special data included in the update can also be written as the updated data into its corresponding data field.

[0077] Method 900 may perform operation 908, during which the integrity of the data values stored in the inactive data unit may be verified. In various embodiments, such verification may be performed according to verification and / or authentication processes defined by security standards. For example, such verification operations for data integrity may include checking error detection codes or some other data integrity data values determined and calculated according to memory security standards.

[0078] Method 900 may perform operation 910, during which a validity indicator may be generated for the inactive data unit. Accordingly, as similarly discussed above, a hash value may be calculated and stored as the validity indicator of the inactive data unit. The hash value may be calculated based on the newly updated data. Thus, the calculated hash value is also the updated validity indicator.

[0079] Method 900 may perform operation 912, during which it may be determined whether the update also includes a firmware data structure or a certificate data structure. Thus, operations 902 to 910 may have been performed for special data, and operation 912 may be performed to determine whether additional update operations should be performed for both the certificate data structure and the firmware data structure. Among other things, such determination may be made based on whether the update includes a certificate data structure or a firmware data structure, such as may be determined based on one or more identifiers included in the update that are configured to identify these types of data structures. Accordingly, the content of the update may be analyzed, and if it is determined that the update does not include a firmware data structure or a certificate data structure, method 900 may proceed to operation 914, during which the inactive data unit may be reset, and the pointer may be updated to identify the active data unit.

[0080] If it is determined during operation 912 that the update does include a firmware data structure or a certificate data structure, method 900 may proceed to operation 916, during which the version data of the firmware or certificate may be verified. As will be discussed in more detail below, the version identified in the updated data may be compared with the version data stored in a secure storage location. Accordingly, the version data of the firmware or certificate may be compared with the version data stored in a secure storage location that provides reference version data for such comparison. If it is determined that the versions match, method 900 may proceed to operation 914 discussed above. If it is determined that the versions do not match, method 900 may terminate. In one example, the reset of the inactive data unit may occur after additional update operations that may be associated with another data structure, such as another certificate version or firmware version.

[0081] Figure 10AA diagram showing an example of an erased sector configured according to some embodiments. As will be discussed in more detail below, the erased sector 1000 shows the storage of metadata and special data in a flash memory device that utilizes erased sectors to manage data and memory operations. As Figure 10A shown, an erased sector, such as erased sector 1000, may include a number of word lines configured to store data. In one example, erased sector 1000 includes 16 word lines. In some embodiments, the first word line 1002 is configured to store metadata. For example, the first word line 1002 may include data fields, such as a first data field 1004 configured to store a count value and a second data field 1006 configured to store a valid indicator. Additionally, erased sector 1000 may include additional word lines, such as a second word line 1008, which is configured to store data that may be the target of various update operations.

[0082] Figure 10B A diagram showing the progression of data included in a data field during an update of special data according to some embodiments. As will be discussed in more detail below, the graph 1030 shows an update operation associated with a security system, where the update includes new data but does not include a new version associated with a firmware or certificate update. More specifically, the graph 1030 shows data included in a data field during a special data operation, such as the special data operation described above with reference to Figure 9 description. As Figure 10B shown, the graph 1030 shows a first data unit 1032 and a second data unit 1034. In this example, the first data unit 1032 is the currently active data unit, and the second data unit 1034 is an inactive data unit. During a first operation 1036, a first valid indicator is rewritten to the first data unit 1032 and the second data unit 1034 is reset. As similarly discussed above, the first valid indicator may be a calculated hash value. During a second operation 1038, the count value of the 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, the special data included in the second data unit 1034 is updated. During a fifth operation 1044, a second valid indicator is written to the second data unit 1034, thereby activating the second data unit 1034. As discussed above, the second valid indicator may be a second hash value calculated based on the updated data. During a sixth operation 1046, the content of the first data unit 1032 may be reset by writing a reset code to the content of the first data unit 1032.

[0083] Figure 11A diagram showing the progress of data included in data fields during the update of a certificate and firmware. As will be discussed in more detail below, the diagram 1100 shows an update operation associated with a security system, where the update includes a new version of the firmware and the certificate. Accordingly, consecutive iterations of the update method are performed for each of the firmware and the certificate, and the data is not reset or erased until each corresponding update method ends. More specifically, the diagram 1100 shows the data included in the data fields during certificate and firmware operations such as the certificate and firmware operations described above with reference to Figure 9 As described. Figure 11 As shown, the diagram 1100 shows a first data unit 1102 and a second data unit 1104 for the certificate data structure. The diagram 1100 also shows a third data unit 1106 and a fourth data unit 1108 for the firmware data structure. In this example, the first data unit 1102 is the currently active data unit for the certificate, and the second data unit 1104 is the inactive data unit for the certificate. In addition, the third data unit 1106 is the currently active data unit for the firmware, and the fourth data unit 1108 is the inactive data unit for the firmware.

[0084] Accordingly, during a first operation 1110, a first valid indicator is rewritten to the first data unit 1102 and the second data unit 1104 is reset. As similarly discussed above, the first valid indicator can be a calculated hash value. During a second operation 1112, the count value of 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 valid indicator is written to the second data unit 1104. As discussed above, the second valid indicator can be a second hash value calculated based on the updated data.

[0085] In addition, during a sixth operation 1120, a third valid indicator is rewritten to the third data unit 1106, and the fourth data unit 1108 is reset. As similarly discussed above, the third valid indicator can be a calculated hash value. During a seventh operation 1122, the count value of 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 valid indicator is written to the fourth data unit 1108. As discussed above, the fourth valid indicator can be a hash value calculated based on the updated data.

[0086] As Figure 11As shown, the chart 1100 further shows a secure storage location, such as the secure storage location 1130, which is configured to store the version number of the firmware, and this version number can be used as a reference version number for the special data stored in the data unit. For example, during operation 1119, the version number stored in the secure storage location 1130 can be compared with the version number of the second data unit 1104, and during operation 1129, the version number stored in the secure storage location 1130 can be compared with the version number of the fourth data unit 1108. Such comparison operations can be performed to verify which data units have the correct version number and to activate the data units with matching version numbers. In some embodiments, the version number included in the secure storage location 1130 can be updated last, so as to activate the data unit via such an update. For example, the version numbers stored in the second data unit 1104 and the fourth data unit 1108 may have been updated to k + 1 during operations 1114 and 1124 respectively. Once the operations associated with the data unit are completed, the version number stored in the secure storage location 1130 can be updated during operation 1132, such 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 now activated because their version numbers now match.

[0087] Figure 12 The flowchart shows another example of a method for data protection performed according to some embodiments. As will be discussed in more detail below, a method such as method 1200 can be performed to identify active data units and read data values from the active data units. In addition, as will be discussed in more detail below, method 1200 can also be performed to identify one or more error states, such as failure to identify an active data unit. Therefore, the data read from the data unit can be used to determine whether there is a memory error and whether a power failure event has occurred.

[0088] Method 1200 can perform operation 1202, during which it can be determined whether the first valid indicator is correct. As discussed similarly above, the first valid indicator can be the first hash value stored in the first data unit. Therefore, the first hash value can be recalculated and compared with the hash value stored in the first data unit. If it is determined that the first valid indicator has been correctly calculated and stored, method 1200 can proceed to operation 1204.

[0089] Accordingly, during operation 1204, it can be determined whether the second validity indicator is correct. As discussed similarly above, the second validity indicator can be the second hash value stored in the second data unit. Thus, the second hash value can be recalculated and compared with the hash value stored in the second data unit. If it is determined that the second validity indicator is not correctly calculated and stored, method 1200 can proceed to operation 1206.

[0090] During operation 1206, it can be determined whether the data unit being analyzed includes a data structure associated with firmware or a certificate. As discussed similarly above, such a determination can be made based on known sector information such as the mapping of sectors. Accordingly, if it is determined that the data unit being analyzed is not associated with firmware or a certificate, method 1200 can proceed to operation 1208, where the first data unit can be identified as the active data unit, and data can be read from the first data unit. Additionally, if it is determined that the data unit being analyzed is associated with firmware or a certificate, method 1200 can proceed to operation 1210.

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

[0092] Returning to operation 1204, if it is determined that the second validity indicator is correct, method 1200 can proceed to operation 1214, where it can be determined whether the data unit being analyzed includes a data structure associated with firmware or a certificate. As discussed similarly above, such a determination can be made based on known sector information such as the mapping of sectors. Accordingly, if it is determined that the data unit being analyzed is not associated with firmware or a certificate, method 1200 can proceed to operation 1216, where the data unit with a higher count value can be identified as the active data unit. The data values included in the active data unit can be refreshed to solidify them, and a reset value can be written to the inactive data unit. It should be understood that one or more additional read operations can be performed to read data from the active unit. Returning to operation 1214, if it is determined that the data unit being analyzed is associated with firmware or a certificate, method 1200 can proceed to operation 1218.

[0093] Accordingly, during operation 1218, it can be determined whether the data unit being analyzed is associated with the firmware. As discussed similarly above, the data unit can be associated with the firmware and / or a certificate, and during operation 1218, it can be determined whether they are specifically associated with the firmware. Also as discussed above, such a determination can be made based on the known sector information. Thus, if it is determined that the data unit being analyzed is associated with the firmware, method 1200 can proceed to operation 1220.

[0094] Accordingly, during operation 1220, it can be determined whether one of the firmware version numbers stored only in the special data is the same as the version number stored in the corresponding secure storage location. If one of the firmware versions does match the version stored in the secure storage location, method 1200 can proceed to operation 1222, where the matching firmware version can be used to identify the active data unit, and any suitable read operation can be performed. Additionally, the data included in the active data unit can be solidified, and the reset code can be written to the inactive data units. If none or all of the firmware versions match, method 1200 can proceed to operation 1212, where no active data unit is identified.

[0095] Returning to operation 1218, if it is determined that the data unit is not associated with the firmware, method 1200 can proceed to operation 1224, where it can be determined whether the versions of the two data units both match the version of the secure data (also referred to herein as special data). Such a determination can be made based on the retrieval and comparison of the versions in different data structures, as discussed similarly above. If it is determined that neither version matches the version of the special data, method 1200 can proceed to operation 1220 discussed above to see if one of the versions matches. If it is determined that both versions do match, method 1200 can proceed to operation 1216, where any suitable read, hardening, and reset operations can be performed. In some embodiments, the data unit with the higher count value can be identified as the active data unit.

[0096] Returning to operation 1202, if it is determined that the first valid indicator is incorrect, method 1200 can proceed to operation 1226, where it can be determined whether the second valid indicator is correct. Such a determination can be made based on the calculation and comparison of the hash values, as discussed similarly above. If it is determined that the second valid indicator is incorrect, method 1200 can proceed to operation 1212, where no active data unit is identified, and one or more error messages can be generated.

[0097] 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 associated with firmware or a certificate. Such a determination may be made based on known sector information such as the mapping of sectors, as discussed similarly above. Thus, if it is determined that the data unit being analyzed is not associated with firmware or a certificate, method 1200 may proceed to operation 1230, where the second data unit may be identified as the 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 associated with firmware or a certificate, method 1200 may proceed to operation 1232.

[0098] Accordingly, during operation 1232, it may be determined whether the version of the firmware and / or the certificate matches the version stored in the secure storage location. Thus, these 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 1230, where the second data unit may be identified as the active data unit and data may be read from the second data unit. If it is determined that the versions are different, method 1200 may proceed to operation 1212, where it may be determined that no valid active data unit has been found. Additionally, as discussed similarly above, one or more error messages may be generated.

[0099] Figure 13 A flowchart illustrating another example of a method for data protection performed in accordance with some embodiments is shown. As will be discussed in more detail below, a method such as method 1300 may be executed to implement an update operation for a memory device that may be a secure flash device. Thus, the data stored in the memory device may include secure data, such as a certificate data structure. Additionally, the secure data may also include a firmware data structure. Thus, the data may include the special data and its associated metadata described previously, as well as certificate data and firmware data. As will be discussed in more detail below, in the context of secure flash, additional metadata columns may be used for data such as version data, and different data structures may be implemented and managed in different storage sectors.

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

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

[0102] Method 1300 may perform operation 1306, during which the security data may be updated and a new version may be activated. Accordingly, the security data may be updated using new data included in the update, and if new data is included, the new certificate and the new firmware data structure may also be updated. As similarly discussed above and as will be discussed in more detail below, the version data associated with the updated data structure may also be updated such that they match the version data number stored in the secure storage location and are used as a reference for the version number written in the special structure metadata. Once the updated version number matches the reference version number, the updated data structure may be activated.

[0103] Method 1300 may perform operation 1308, during which one or more inactive data sectors may be erased. In some embodiments, the sectors of the inactive data units that are now used to store the certificate and the firmware may be reset by, for example, erasing the data units. Such a reset and rewrite of the previous security data may be performed to comply with one or more security standards associated with the security data storage.

[0104] Figure 14 A flowchart showing another example of a method for data protection performed according to some embodiments is shown. As will be discussed in more detail below, a method such as method 1400 may be performed to implement an update operation for a memory device, which may be a secure flash device that may include security data such as a certificate data structure and a firmware data structure. In various embodiments, the memory device may be a secure flash device that uses erase sectors for the erase operation. Accordingly, method 1400 may be performed to support the update operation of the security data in the context of flash memory.

[0105] Method 1400 may perform operation 1402, during which the valid indicator in the active data unit may be reprogrammed. As discussed similarly above, the valid indicator is a security code or verification code calculated at least in part based on the content of the metadata word line of the first data unit that can currently be identified as the active data unit based on, for example, the command count value. In one example, the valid indicator may be a hash value calculated based on the content of the special data and its associated metadata. During operation 1402, the hash value may be recalculated and reprogrammed into the active data unit to refresh the valid indicator of the first data unit. As discussed similarly above, in the context of a flash memory device, the data unit may be a data sector.

[0106] Method 1400 may perform operation 1404, during which the sector associated with the inactive data unit may be erased. As discussed similarly above, erasing the inactive data unit confirms that the erase operation has been performed and ensures that only one active version of the special data exists, thus meeting the security standard. Accordingly, the second data unit may be identified as the inactive data unit, and the sector including the inactive data unit may be erased. It should be understood that the active data units are implemented in different sectors. Thus, both the metadata word line and the data word line may be erased by executing an erase command.

[0107] Method 1400 may perform operation 1406, during which the counter value, version data, and update data may be programmed to the inactive data unit. Thus, during operation 1406, the command count value may be updated to identify an incremented value. In addition, the version data included in the update data, such as the version, may also be programmed to its corresponding field in the inactive data unit. In various embodiments, the version data identifies the version of the special data included in the update. In addition, the special data included in the update may also be programmed to its corresponding data field as the updated data.

[0108] Method 1400 may perform operation 1408, during which the integrity of the data values stored in the inactive data unit may be verified. In various embodiments, the verification may be performed according to a verification and / or authentication process defined by the security standard. For example, such a verification operation for data integrity may include checking an error detection code or some other data integrity data value determined and calculated according to the memory security standard.

[0109] Method 1400 may perform operation 1410, during which an active indicator may be generated for an inactive data unit. Thus, as similarly discussed above, a hash value may be calculated and programmed as the active indicator for the inactive data unit. The hash value may be calculated based on newly updated data. Thus, the calculated hash value is also the updated active indicator.

[0110] Method 1400 may perform operation 1412, during which it may be determined whether an update includes updated data for a firmware sector and / or a certificate sector. Thus, operations 1402 to 1410 may have been performed for sectors including special data, and operation 1412 may be performed to determine whether additional update operations should be performed for sectors associated with the certificate data structure and the firmware data structure. Among other things, such a determination may be made based on whether the update includes a certificate data structure or a firmware data structure, as may be determined based on one or more identifiers included in the update that are configured to identify these types of data structures. Such a determination may also be made 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 by the system as a mapping table or a 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 to program the update data to any certificate sector or firmware sector. Thus, the content of the update may be analyzed, and if it is determined that the update does not include a firmware data update or a certificate data update, method 1400 may proceed to operation 1414, during which the pointer may be updated and the first data unit may be erased.

[0111] If it is determined during operation 1412 that the update does include a firmware data update or a certificate data update, method 1400 may proceed to operation 1416, during which the version data of the firmware data structure or the certificate data structure may be verified. As similarly discussed above, such verification may be performed based on whether the version number of the firmware or the certificate matches the reference version number stored in a secure storage location. If it is determined that the version numbers match, method 1400 may proceed to operation 1414 discussed 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 terminate.

[0112] Although the foregoing concepts have been described in relatively great detail for purposes of clear 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 the processes, systems, and devices. Therefore, this example should be considered illustrative and not restrictive.

Claims

1. A system comprising: A non-volatile memory device comprising: 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 latest versions of the data and the associated metadata; and a control circuit system configured to: reading metadata from the first data unit and the second data unit; Based on the contents of the first data unit and the second data unit, identifying the first data unit as an inactive data unit; and One or more update operations are performed such that upon completion of the update operations, the first data unit is updated and set as the active unit.

2. The system according to claim 1, wherein: The one or more update operations include: storing the updated data in the first data unit; incrementing a count value stored in the first data unit to determine that the first data unit is the active data unit; activating the first data unit; and Reset the second data unit.

3. The system according to claim 2, wherein: The update data is included in an update data object received by the control circuitry.

4. The system according to claim 1, wherein: The first data unit is identified based on a count value included in metadata stored in the first data unit and metadata stored in the second data unit.

5. The system according to claim 1, wherein: The control circuit system is also configured to: In response to determining that no active data unit exists, an error message is generated.

6. The system according to claim 1, wherein: The control circuit system is also configured to: Generates an error message indicating that a power outage event has occurred.

7. The system according to claim 1, wherein: The data is configuration data including a certificate data structure and a firmware data structure.

8. The system according to claim 7, wherein: Each of the certificate data structure and the firmware data structure includes version data and a validity indicator.

9. The system according to claim 8, wherein: The validity indicator is a hash value calculated based at least in part on the metadata.

10. A method comprising: reading metadata from a first data unit and a second data unit storing data and associated metadata of a non-volatile memory device using control circuitry; identifying, using the control circuitry, the first data unit as an inactive data unit based on the contents of the first data unit and the second data unit; as well as One or more update operations are performed using the control circuitry such that when the one or more update operations are completed, the first data cell is updated and set as an active cell.

11. The method according to claim 10, wherein: The one or more update operations further include: storing the updated data in the first data unit; incrementing a count value stored in the first data unit to determine that the first data unit is the active data unit; activating the first data unit; and Reset the second data unit.

12. The method according to claim 10, wherein: The identifying the first data as an inactive data unit further comprises: retrieving a count value included in metadata stored in the first data unit and metadata stored in the second data unit; and It is determined that the count value of the first data unit is lower than the count value of the second data unit.

13. The method according to claim 10, further comprising: Generates an error message indicating that a power outage event has occurred.

14. The method according to claim 10, wherein: The data is configuration data including at least one of a certificate data structure and a firmware data structure.

15. The method according to claim 14, wherein: Each of the certificate data structure and the firmware data structure includes version data and a validity indicator, and wherein the validity indicator is a hash value calculated based at least in part on the metadata.

16. An apparatus comprising: A non-volatile memory array comprising: 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 device, wherein the first data unit and the second data unit are configured to alternately store the latest versions of the data and the associated metadata; and one or more processors configured to: reading metadata from the first data unit and the second data unit; identifying the first data unit as an inactive data unit based on contents of the first data unit and the second data unit; and One or more update operations are performed such that when the one or more update operations are completed, the first data unit is updated and set as the active unit.

17. The device according to claim 16, wherein: The one or more update operations include: storing the updated data in the first data unit; incrementing a count value stored in the first data unit to determine that the first data unit is the active data unit; activating the first data unit; and Reset the second data unit.

18. The device according to claim 16, wherein: The first data unit is identified based on a count value included in metadata stored in the first data unit and metadata stored in the second data unit.

19. The device according to claim 16, wherein: The one or more processors are further configured to: Generates an error message indicating that a power outage event has occurred.

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

Images