Patent Application
20160147594
The present invention relates to managing computer memory contents, and more particularly to a method and apparatus for preventing corruption of code and allowing for recovery when data corruption occurs in a flash memory.
Flash memory is used in a variety of computer applications. For parallel types of flash memory, the signal interface between a computer processor and an external flash memory is controlled as specified by the external flash manufacturer. Some manufactures provide mechanisms via this interface to prevent or help recover from the effects of corruption of flash memory contents, such as that which can occur when the power supply to the computer processor and/or flash memory is interrupted. However, serial types of flash memory have become more popular and do not typically include such mechanisms. Accordingly, there exists a need to address this problem, among others.
The present invention relates to methods and apparatuses for eliminating or mitigating the effects of the corruption of contents in a flash memory, such as that which can occur during a power interruption. Embodiments of the invention include methods for preventing the corruption of code stored in flash memory. Such methods can include partitioning code in separate physical blocks as data in a flash memory. Embodiments of the invention also include methods for mitigating the effects of corruption of data stored in flash memory. Such methods can include a book-keeping mechanism that allows for the detection of corruption events, along with the affected locations in flash memory.
In accordance with these and other aspects, a method of preventing corruption of code in a flash memory device according to embodiments of the invention includes identifying physical blocks of the flash memory device, storing code in a partition of one or more of the identified physical blocks, and preventing data from being programmed and erased in the partition.
In further accordance with these and other aspects, a method of managing corruption of data in a flash memory device according to embodiments of the invention includes maintaining a book-keeping structure in non-volatile memory separate from the flash memory device, identifying a portion of the flash memory device in which an erase or program operation is to be commenced, and setting a field in the book-keeping structure that includes the identified portion and indicates that an erase or program operation is being performed, such that if a corruption event occurs during the erase or program operation, a possible corruption of the identified portion of the flash memory can be determined from the book-keeping structure.
These and other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures, wherein:
The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention to a single embodiment, but other embodiments are possible by way of interchange of some or all of the described or illustrated elements. Moreover, where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Embodiments described as being implemented in software should not be limited thereto, but can include embodiments implemented in hardware, or combinations of software and hardware, and vice-versa, as will be apparent to those skilled in the art, unless otherwise specified herein. In the present specification, an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration.
The present invention provides techniques to prevent code corruption and mitigating effects of data corruption in an external serial flash memory coupled to a computer processor. According to certain aspects, the computer processor is configured to boot from ROM and to validate code in external flash memory by performing a CRC check. According to further aspects, code corruption prevention includes partitioning code and data in separate physical blocks of a flash memory to prevent code corruption due to sudden loss of power during data erase or programs. According to still further aspects, by limiting each data program or erase operation to a single sector, an on-chip flash manager limits the potential damage due to sudden loss of power to one sector. According to yet further aspects, a book-keeping mechanism helps in detecting data corruption events and possible recovery without impacting the device performance.
Embodiments of the invention will be described in connection with a useful application in global satellite positioning systems. However, the invention is not limited to this application, and those skilled in the art will understand how to implement the invention in other types of systems after being taught by the present examples.
Device 102 can be a cellular or other type of telephone with built-in GPS functionality (e.g. iPhone, Galaxy or other Android smartphone, etc.), or it can be a notebook or tablet computer (e.g. iPad, Galaxy Note, Surface, etc.) with similar built-in positioning functionality, or it can be a personal navigation device (PND, e.g. from Garmin, TomTom, etc.) or a tracking device (e.g. automotive tracking from Trimble, package or fleet management tracking from FedEx, child locator tracking applications etc), or an automobile navigation/media system, or a watch (e.g. Nike sport watch), etc.
GNSS module 122 can be implemented using any combination of hardware and/or software, including chipsets such as SiRFstar V from CSR Technology, as adapted and/or supplemented with functionality in accordance with the present invention, and described in more detail herein. More particularly, those skilled in the art will be able to understand how to implement the present invention by adapting and/or supplementing such chipsets and/or software with the code and data corruption improvement techniques of the present invention after being taught by the present specification.
In operation, using signals from at least four SVs 114, 116, 118, 120, receiver 122 provides a 3-dimensional navigation solution (only three satellites are required for a 2-dimensional navigation solution, e.g. by using known height), for example by performing trilateration techniques and using PVT filters and algorithms known to those skilled in the art. This solution can be also be based on, or supplemented by, inertial signals such as those from accelerometers. The navigation solution from receiver 122 can be used by device 102 in a variety of ways, depending on the type of device. As shown, device 102 can also include hardware/software functionality for communicating with a network 106 (e.g. telephone, WiFi, Internet, etc.).
In typical operation, when desired by host processor 202, navigation processor 204 provides a GNSS-derived navigation solution (e.g. location and time) to host processor 202 at defined intervals such as one report every one second. In embodiments, host processor 202 can also provide initial software (i.e. code) setups or updates to navigation processor 204, which navigation processor 204 stores in non-volatile memory 206 when provided.
As further shown in
More particularly, in one example embodiment, non-volatile memory 206 is a serial flash memory. The present inventors have discovered that, due to the physical architecture of the serial flash memory device, other data within the same physical block being erased or programmed can be corrupted. Data within a physical block share bit lines. When a specific bit is not completely erased or programmed, the value read from other bits within that physical block can either be incorrect or inconsistent. If the corrupted data is fully erased, the value read from the other bits within the physical block will now be correct. The physical block sizes vary based on the manufacturer and serial flash memory size. Physical block sizes include 4 KB, 64 KB, 128 KB, 256 KB and 512 KB.
According to certain aspects, the present invention eliminates the risk of code corruption and detects data corruption due to such events. According to further aspects, if there is a possibility of data corruption, an attempt is made to restore the data. Example embodiments in furtherance of these and other aspects will be described herein below.
As shown in the example of
As shown in
In some embodiments, the particular configuration of memory 206, including block size and the particular locations and sizes of partitions 402, 404 for each flash manufacturer is pre-determined and stored in LUT 314. In other embodiments, only the physical block size is stored in LUT 314, and the locations and/or sizes of some or all of partitions 402, 404 are determined dynamically based on the physical block size, the amount of code, and the number of sizes of data types. In any event, once the partitions are determined, information regarding them is stored in flash map/index 320 for subsequent use by FM 304 for reading and writing data from and to data partitions 404.
It should be noted that although partitions 402 and 404 are illustrated as occupying contiguous physical blocks, this is not necessary in all embodiments. The only requirement is that code partition 402 is in separate physical block(s) 408 from block(s) 408 occupied by data partitions 404.
As further shown in
Returning to
It should be further noted that boot code 312 can also include functionality for causing code in flash memory 206 to be initially loaded or updated, for example by host processor 202. In these and other embodiments, boot code 312 can include functionality for communicating with host processor 202 to receive the code, write the code to partition 402 of memory 206, and calculate a CRC. In embodiments, as part of a code update, host processor 202 is required to provide power to processor 204 while code is being loaded into flash memory 206 to prevent it from being corrupted.
Upon successful verification that the code stored in memory 206 is valid, boot code 312 configures processor 204 for regular operation. In the illustrated example of processor 204, this includes initiating applications 302 (e.g. GNSS navigation applications that process satellite data to obtain navigation solutions), flash manager (FM) 304, and drivers 306. Generally, and as will be described in more detail below, flash manager 304 handles all accesses to flash memory 206 requested by applications 302 and using drivers 306. Meanwhile, the particular implementation details of applications 302 and drivers 306 are not necessary for an understanding of the present invention, and so they will be omitted here for the sake of clarity of the invention. The code for causing processor 204 to execute applications 302, FM 304 and drivers 306 can be stored in one or both of memory 206 and ROM 310, and boot code 312 can load some or all of this code in volatile program memory in processor 204, as will be appreciated by those skilled in the art.
Requests from applications 302 to access data in flash memory 206 are placed in a queue 308 by FM 304. In embodiments, these requests are executed by FM 304 using information in flash map/index 320 at the end of each processing cycle if there is enough time left for execution. This ensures that performance of high priority tasks is not impacted by flash access operations. For example, applications 302 can be executed in threads, with certain operations that are scheduled to be completed every cycle (e.g. processing to produce a navigation solution once every second). In these and other embodiments, FM 304 executes at a lower priority than these operations, and only during the remaining time of each processing cycle.
In embodiments to be described in more detail below, FM 304 causes all requested erase or program accesses to flash memory 206 to be protected from corruption by storing key details into book-keeping structure 316 prior to the start of the operation using a book-keeping mechanism. In embodiments shown in
Serial flash memory book-keeping structure 316 also includes a CRC32 which is used to determine if the book-keeping information is valid. The following shows an example of data structure 316 according to embodiments of the invention.
In this example, the P/E bit is set to 1 immediately before processor 204 begins programming or erasing a sector, and is set to 0 after the program or erase has been completed. The P/E Sector is the sector that is currently being programmed or erased. This is valid only if the P/E bit is set to 1. The data type bit mask includes one bit for every data type. Each bit has a value of 0 if the corresponding data element is good, and is set to 1 if the corresponding data element needs to be erased before writing.
The following Table lists one non-limiting example of the bits in the data type bit mask, along with the corresponding data type. This example is in connection with an embodiment of the invention where applications 302 perform GNSS positioning programs, and the data stored in flash memory includes almanac, ephemeris, extended ephemeris, etc. for a plurality of GNSS satellites, as well as for several different GNSS systems including GPS, GLONASS, etc.
In embodiments to be described in more detail below, FM 304 ensures that all data stored in flash memory 206 are stored in terms of data records. All serial flash memory manufacturers define a sector to be 4 KB, and so embodiments of FM 304 define data records in terms of flash memory sectors. Given that sectors are typically the same size or smaller than physical block sizes, a sector will only contain data for one data element type. In embodiments, FM 304 causes drivers 306 to erase data in partitions 404 of the flash memory 206 using the serial flash memory sector erase command. All serial flash memory manufacturers also support a page program command where 1 to 256 bytes are written, and in embodiments FM 304 causes drivers 306 to perform all program operations using a page program command.
Before an erase or program begins, FM 304 updates structure 316 to indicate that an erase or program is in progress (P/E bit). In addition, FM 304 also stores the corresponding sector number being erased or programmed in structure 316. After drivers 306 complete the erase or program operation, FM 304 updates structure 316 indicating that an erase or program is no longer in progress.
If a power loss occurs and then power is reapplied to GNSS module 122, boot code 312 will configure processor 204 as described above, and initiate FM 304. When first initiated, FM 304 will perform a CRC on the bits in the structure 316 to see whether it is valid by comparing the determined CRC to the stored CRC. If so, and if the P/E bit indicates an erase or program was in progress, then FM 304 causes the sector identified in structure 316 to be erased. This will prevent a partially erased or programmed sector from corrupting other sectors within the same physical block. If FM 304 determines that the serial flash memory book-keeping information in structure 316 is not valid based on the CRC32 comparison, then FM 304 updates the book-keeping structure 316 to indicate that all data elements stored in serial flash memory need to be erased.
Example aspects of how FM 304 performs a program operation based on requests from applications 302 will now be described in more detail in connection with the flowchart in
When applications 302 request a data element to be written to flash memory 206, in step S502 FM 304 first looks up information regarding the designated location for the data element type in flash memory map/index 320. In embodiments, this information includes the identification of one or a plurality of sectors 410 in flash memory 206 corresponding to the data element type. In these and other embodiments, this information also includes the sector(s) where the next or newest copy of data for this data element type should be stored. For example, FM 304 and flash memory map/index 320 can implement a circular buffer for multiple copies of the same data element type, wherein the newest copies of the data element type overwrite the oldest copies stored in flash memory 206. This can be done, for example, for wear leveling reasons, so that erases and programs are more evenly distributed among sectors 410. It should be noted that multiple copies may not be stored for all data element types. For example, there may be only one most recent copy of a given data element type stored in flash memory 206.
Next in step S504, FM 304 checks the bit in data type bit mask of the book-keeping structure 316 corresponding to the data element to determine whether the data element needs to be erased. If an erase is indicated by the bit mask, processing branches to step S506 where, for one sector at a time, and for all sectors associated with the data element (and possibly also including all copies thereof), FM 304 updates structure 316 to indicate that the sector is being erased, instructs drivers 306 to erase that sector, and then updates structure 316 when the erase operation has completed.
Next in step S508, FM 304 breaks the data to be written into sectors. For each sector amount of data (e.g. 4 kB), in step S510 FM 304 calculates a CRC32 for that data. Next in step S512 FM 304 updates the book-keeping information 316 to indicate that the sector is being programmed. In step S514 FM 304 causes drivers 306 to store the data and CRC32 together in the designated sector in memory 206. Then in step S516 FM 304 updates the book-keeping information 316 to clear the P/E bit.
Example aspects of processing performed by FM 304 when applications request data to be read from flash memory 206 will now be described.
As mentioned above, there may be several copies (i.e. data records) of a data element type in memory 206. So, in this case, first FM 304 uses information in flash index 320 to determine the sector(s) containing the data element type. In embodiments, along with each copy, a time tag is stored. Using this time tag information, FM 304 identifies the most up-to-date data record of the data element type. For each sector of data, FM 304 causes drivers 306 to read the data record from serial flash memory 206 and writes the data record to local copy 318. FM 304 then performs a CRC and validates it with the CRC32 stored along with the record. The data record is only used if it is valid.
If the data record is valid, only the local copy 318 is thereafter used by applications 302 because the data read from serial flash memory 206 may be inconsistent. If FM 304 determines the newest data record(s) read from flash memory 306 is not valid, the above steps are repeated with the next oldest data record. The local copy 318 is still used regardless of whether the book-keeping structure 316 indicates the data element needs to be erased. This allows valid data records in serial flash memory 206 to be used when power was removed from non-volatile memory (normally, a rare event). As mentioned above, when power is applied the very first time, FM 304 marks all data elements as invalid.
Although the present invention has been particularly described with reference to the preferred embodiments thereof, it should be readily apparent to those of ordinary skill in the art that changes and modifications in the form and details may be made without departing from the spirit and scope of the invention. It is intended that the appended claims encompass such changes and modifications.
