text:
US20060075395A1 - Flash card system - Google Patents
Flash card system Download PDF
Charles Lee
Ikang Yu
Super Talent Electronics Inc
2004-10-01 Assigned to SUPER TALENT ELECTRONICS, INC. reassignment SUPER TALENT ELECTRONICS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LEE, CHARLES C., YU, IKANG
2004-10-01 Application filed by Super Talent Electronics Inc filed Critical Super Talent Electronics Inc
G11C16/00—Erasable programmable read-only memories
G11C16/02—Erasable programmable read-only memories electrically programmable
G11C16/06—Auxiliary circuits, e.g. for writing into memory
G11C16/10—Programming or data input circuits
G11C16/102—External programming circuits, e.g. EPROM programmers; In-circuit programming or reprogramming; EPROM emulators
G06F8/00—Arrangements for software engineering
G06F8/60—Software deployment
G06F8/65—Updates
G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
G11C2211/00—Indexing scheme relating to digital stores characterized by the use of particular electric or magnetic storage elements; Storage elements therefor
G11C2211/56—Indexing scheme relating to G11C11/56 and sub-groups for features not covered by these groups
G11C2211/564—Miscellaneous aspects
G11C2211/5641—Multilevel memory having cells with different number of storage levels
A flash memory system is disclosed. The flash memory system includes a flash controller and at least one flash memory device coupled to the flash controller. The boot code and control code for the flash memory system are stored in the flash memory device. Because the boot code and the control code are stored in the flash memory device instead of in a ROM, the boot code and control code can be updated in the field. Also, the flash controller can support multiple brands and types of flash memory in the flash memory system to eliminate stocking issues.
The present invention relates to memory systems, and more particularly to an adaptable flash card system.
Multimedia cards (MMC) that use flash memory are popular for storing data. Flash memory-based MMCs (or "flash cards") are well known and are used in products such as digital cameras. Benefits of flash cards include low-power dissipation and high resistance to vibration. These are primary reasons why flash cards have been replacing magnetic materials such as floppy disks.
FIG. 1 is a block diagram of a conventional flash card 50 coupled with a user host 52. The flash card 50 includes a flash controller 60 and a flash memory device 62. The user host 52 can be a camera or a PC, for example. Data is transferred between the user host 52 and the flash memory device 62 via the flash controller 60. Information required for accessing the flash device 62 is stored in a read-only memory (ROM) 64 in the flash controller 60. Such information includes boot code 66 and control code 68. The boot code 66 is software that initializes the flash card 50 during the early phase of the booting sequence. The control code 68 contains both necessary information to exercise the initial booting sequence, and information that enables the flash controller 60 to access the flash memory device 62.
A problem with conventional flash memory systems is that is the boot code 66 and/or the control code 68 can have bugs, which may not be discovered until the flash memory system is already in the field. Also, the boot code 66 and/or the control code 68 may have to be updated due to bugs or due to improvements to the codes.
The conventional solution is to replace the flash controller 60 as it contains the ROM 64, in which the boot code 66 and the control code 68 are stored. A problem with this solution is that it can cause significant inventory issues for a flash card manufacturer. For instance, an entire stock of flash controllers may have to be thrown out for one fix or for an update to the boot code or to the control code. Hence, a new stock of flash controllers would have to be ordered. This can be an on-going problem if subsequent updates are required.
Accordingly, what is needed is an improved flash memory system. The system should be adaptable, simple, cost effective, and capable of being easily adapted to existing technology. The present invention addresses such a need.
A flash memory system is disclosed. The flash memory system includes a flash controller and at least one flash memory device coupled to the flash controller. Boot code and control code for the flash memory system are stored in the flash memory device. Because the boot code and the control code are stored in the flash memory device, the boot code and control code can be updated in the field.
FIG. 1 is a block diagram of a conventional flash card coupled with a user host.
FIG. 2 is a block diagram of a flash memory system in accordance with the present invention.
FIG. 3 is a block diagram of the flash controller of FIG. 2 in accordance with the present invention.
FIG. 4 is a diagram of a flash memory structure in accordance with the present invention.
FIG. 5 is a block diagram of a flash memory system, including two flash memory devices using a dual channel configuration, in accordance with the present invention.
FIG. 6 is a diagram of flash memory structures for the flash memory devices of FIG. 5 in accordance with the present invention.
FIG. 7 is a timing diagram for the flash memory system of FIG. 5 in accordance with the present invention.
FIG. 8 is a block diagram of a flash memory system including two interleaved flash memory devices in accordance with the present invention.
FIG. 10 is a diagram of flash memory structures for the flash memory devices of FIG. 8 in accordance with another embodiment of the present invention.
FIG. 11 is a timing diagram for the flash memory system of FIG. 8 in accordance with the present invention.
FIG. 12 is a chart showing an organization of data in accordance with the present invention.
FIG. 13 is a timing diagram for a flash memory system in accordance with the present invention.
FIG. 14 is a flow chart showing a method for programming a flash card using a manufacturer host in accordance with the present invention.
FIG. 15 is a flow chart showing a method for programming a flash card using a flash programmer in accordance with the present invention.
FIG. 16 is a flow chart showing a method for booting a flash card in accordance with the present invention.
FIG. 17 is a flow chart showing a method for testing a flash card before shipping in accordance with the present invention.
FIG. 18 is a block diagram of memory structures in accordance with the present invention.
FIG. 19 is a flow chart showing a method for powering up a flash card during normal operation in accordance with the present invention.
FIG. 20 is a flow chart showing a method for implementing control code during normal operation in accordance with the present invention.
FIG. 21 is a side-view diagram of a conventional multimedia card (MMC).
FIG. 22 is a side-view diagram of an MMC in accordance with the present invention.
FIG. 23 is a side-view diagram of a conventional MMC.
FIGS. 24A, 24B, and 24C are top-view, back-view, and side-view diagrams, respectively, of a conventional MMC.
FIGS. 25A, 25B, and 25C are top-view, back-view, and side-view diagrams, respectively, of an MMC in accordance with the present invention.
The present invention relates to memory systems, and more particularly to an adaptable flash card system. The following description is presented to enable one of ordinary skill in the art to make and use the invention, and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown, but is to be accorded the widest scope consistent with the principles and features described herein.
A system in accordance with the present invention for providing a flash memory system is disclosed. The boot code and the control code are stored in the flash memory instead of in the flash controller. As a result, the boot and control codes can be updated in the field without having to change the flash controller. To more particularly describe the features of the present invention, refer now to the following description in conjunction with the accompanying figures.
Although the present invention disclosed herein is described in the context of a flash card, the present invention may apply to other types of memory systems and still remain within the spirit and scope of the present invention.
FIG. 2 is a block diagram of a flash memory system 200 in accordance with the present invention. The flash memory system 200 includes a flash controller 202 and a flash memory 204. The flash memory 204 stores boot code 206 and control code 208. Note that the term flash memory represents one or more flash memory devices. If there are more than one flash memory device, the boot code 206 and control code 208 can be stored on one of the flash memory devices or alternatively can be stored on multiple flash memory devices. The flash memory system 200 is adapted to be coupled to a user host 210 during normal-mode operation. The user host 210 includes a host flash controller 212.
During programming-mode, the flash memory system 200 is adapted to be coupled to a manufacturer host 220 or alternatively to a Jedec flash programmer 230. The manufacturer host 220 can be a personal computer (PC) with special hardware. The manufacturer host 220 includes a host flash controller 222, which can be a special card interface controller dedicated to volume production of flash cards.
In normal-mode operation, the flash memory system 200 stores data that is provided by the user host 210, which may be a digital camera or PC. The flash memory system 200 is implemented as a flash card. The flash memory system 200 can store various types of data including image data and other types of multimedia data. Accordingly, the flash memory system 200 can also be referred to as a multimedia card (MMC). The data stored in the flash memory system 200 can be later sent as file attachment in an e-mail, printed, or transferred to another host.
The host card controller 212 handles flash card protocol translation between the flash memory system 200 and the user host 210, which enables the user host 210 to transfer files so that various host operating system (OS) software can share information. For example, the host card controller 212 enables data to be read by a user PC via email. Software in the user host 210 handles file system functions, such as providing a file application interface and providing a user accessible device driver.
Before the flash memory system 200 is shipped to an end user, information is stored in the flash memory system 200 to ensure that it functions correctly. The information includes the boot code 206 and the control code 208, as well as information specific to the flash memory (e.g., manufacturer, identification, etc.). The boot code 206 is software that initializes the flash memory system 200 during the early phase of the booting sequence. The boot code 206 also determines the amount of available memory and determines how to access it. The control code 208 contains necessary information for exercising the initial booting sequence and information for enabling the flash controller 202 to access the flash memory device 204. The control code 208 includes parameter settings and a detailed list of information relating to flash memory, as well as card identification (card ID) and card specific data (CSD).
Because the boot code 206 and the control code 208 are stored in the flash memory instead of the ROM, the code in the ROM as well as the physical size of the ROM can be minimized.
In programming-mode operation, the manufacturer host 220 is used to program the flash memory 204 via the flash controller. Alternatively, the Jedec programmer 230 can be used to directly program the flash memory 204. Upon completion of the programming, the manufacturer host 220 diagnoses the flash memory system 200 to ensure that it is functioning properly.
Because the boot code and control code is stored in the flash memory 200, different brands or types of flash memory can be supported by the same flash controller 202 without having to change it. As such, the flash controller is universal to various brands and types of flash memory. This is because each flash memory device of the flash memory 204 stores the boot and control code unique to each flash memory. Parameters for different types of flash memory device parameters are defined in the control code and in a library image file. Accordingly, a single flash controller can support multiple brands and multiple types of flash memory. In other words, the flash controller would not have to be changed for each brand or type of flash memory. This significantly reduces the inventory when cards having various specifications (i.e., different flash memories) are in mass production.
Furthermore, because the boot code and the control code are stored in the flash memory, the boot and control codes can be updated in the field. As such, the end user can download updated code. Such code can be provided via various means including Internet web support, e-mail, etc., and can be downloaded using a PC.
FIG. 3 is a block diagram of the flash controller 202 of FIG. 2 in accordance with the present invention. For ease of illustration, the flash controller 202 of FIG. 3 is shown in two clock domains, a card clock domain 302 and a central processing unit (CPU) clock domain 304. The card clock domain 302 is controlled by a card clock (labeled "card_clk"), which is provided by a host (not shown) to synchronize the command and data protocols. Note that the term host, when used generally, can include any type of host including but not limited to a user host, a manufacturer host, Jedec programmer, etc. All handshake signals follow the card clock to execute transactions.
The CPU clock domain 302 is controlled by a CPU clock (labeled "CPU_clk"). The CPU clock controls all flash operations as well as CPU activity. The speed of the CPU clock can be high for efficient execution (e.g., two times or more faster than the card clock). The speeds of the clocks can and will increase as technology advances, and their precise speeds will depend on the specific application.
Referring to the card clock domain, a command shifter register 310 is used to latch a command via a command line 314 from a host whenever the shift register 310 sees a start bit sending from the host. As stated previously, the term host when used generally can include any type of host including but not limited to a user host, a manufacturer host, etc. The command line 314 is bi-directional. Accordingly, responses from the flash memory system to the host can use the command line for protocol transfers.
A command decoder 312 generates a command interrupt, which is sent to a CPU 320. Double page buffers, 322 a and 322 b, are used to increase the performance of flash operations. In this specific embodiment, the page buffers 322 a and 322 b are 2 K bytes, but can be more or less depending on the specific application. The flash controller 202 alternates between the page buffers 322 a and 322 b to optimize traffic between the host and the flash controller 202. While the page buffer 322 a is in use sending data to a flash memory interface 323, the page buffer 322 b remains available to receive data from the host. Conversely, while the page buffer 322 b is in use sending data to the host, the page buffer 322 a remains available receive data from the flash memory.
A cyclic redundancy check unit 324 (labeled "CRC16") checks checksums for larger bytes of data (e.g., 512 or more bytes). A cyclic redundancy check unit 326 (labeled "CRC7") checks checksums for smaller bytes of data. Such data includes, for example, command or response packet checks. A card identification (ID) state machine 328 ensures that the flash controller 202 is recognized by the host. Each state involves complex operations handled by the firmware of the CPU 320. A data transfer state machine 330 facilitates a direct memory access/addressing (DMA) engine logic 331 to alleviate the CPU 320 when downloading boot or control code. The DMA transfers large blocks of code from the flash memory to the main memory. This speeds up execution running in RAM-based memory, as well as relieves the CPU. A response register 332 facilitates data transfer from the flash memory system to the host.
Referring to the CPU clock domain 304, the CPU 320 is the main engine for control sequencing and is also responsible for handling firmware sequencing. A phase locked loop (PLL) circuit 340 with a crystal 342 generates the CPU clock and a system clock (labeled "sys_clk"), which are primarily used for the CPU 320 and the flash memory interface 322. The clock speeds affect flash timing. A preferred speed is 20 Mhz state tracking, and may vary depending on the specific application.
A read-only memory (ROM) 350 stores code that handles the downloading of code to the flash memory device 204 and transfers control to the boot code residing in the flash memory 204. Alternatively, the ROM 350 can be replaced by a fixed-type electronically erasable ROM (EEPROM) or a NOR type flash memory. Such alternatives would be useful for engineering experiment purposes.
A main memory static random access memory (SRAM) 352 stores executable code, including the boot code and the control code, which are downloaded from the flash memory 204 when the flash memory system boots up. Depending on complexity of the control code, the RAM 352 can be integrated with the CPU 320. A rich-RAM based 8051 controller is example of a RAM integrated with a CPU.
The flash memory interface circuit 322 interfaces with the flash memory during flash memory access operations, to fulfill the task of programming/reading/erasing flash pages or blocks based on commands sent from the host.
The flash card uses a block-based addressing scheme, as opposed to a random addressing scheme, which is common with dynamic random access memory (DRAM) systems. Block-based addressing involves a command and an address, which are sent over a data bus and involves a block of data, which is read or written. A benefit of flash memory is that the data bus is used to send both commands and addresses, in addition to sending user data. As a result, fewer pins are needed on a flash memory chip. Hence, costs are reduced.
FIG. 4 is a diagram of a flash memory structure 400 in accordance with the present invention. A reserved area 406 in the last blocks of the flash memory are used for storing information associated with the flash memory operations (e.g., the boot code and the control code). Such information includes reserved blocks 408, card non-volatile (NV) registers 410, a library image file 412, boot code 414, control code 416, a bad block map 418, and operation registers 420.
The reserved area includes at least two blocks, which includes a spare block used for temporary copies of old final block data. The reserved blocks 408 are used for erase swapping. After old final block data is erased, new data is copied back. Wear leveling problems are not at issue in the reserved area, since updates to either codes or registers occur very infrequently compared to normal data transfers.
The card non-volatile (NV) registers 410 contain necessary parameters, such as card identification (CID) data that the host needs to know to transfer protocols. The library image file 412 includes a maker byte, a device byte, and other information read from a flash command.
With regard to the boot code 414 and the control code 416, at least two copies of each are stored in the flash memory device. This provides a back-up copy during updates. During an update, only one of the two copies is updated to reflect the latest changes. The other copy is saved as a backup copy without any changes, in case any unknown failures occur during the update. Also, two sections are toggled such that during a subsequent update, the original backup copy is updated with the latest code, and the copy of the first update becomes the new backup copy. While two copies are stored in this specific embodiment, more copies can exist if the memory size is sufficient. Additional blocks can be reserved to accommodate larger sizes of boot and control code.
The bad block map 418 records the bad blocks. Bad blocks in the flash memory may manifest at various times, including when the block was first created, and can occur in later stages while being erased or programmed. In a specific embodiment, each block is represented by one bit, where a logical one ("1") represents a good block and a logical zero ("0") represents a bad block. The bad block mapping table also indicates the remaining life of the flash memory based on the ratio of good blocks to bad blocks. All flash memory brands have specification-defined positions for bad blocks, which is known after reading the maker code. Such positions are typically located several bytes after the beginning position of a spare data area. The reserved area 406 would not include any bad blocks detected during a block scan.
The operation registers 420 contain checksum data and address pointers. The address pointers are shared with DMA flash address starting registers. Also stored in this sector is basic information that the card controller requires, such as pointers to the copies of the boot code and the control code, the start address, and the user storage capacity of the flash memory system.
The user storage capacity of the flash memory device is calculated from a flash chip specification volume, which is known after reading organization bytes after a "90 command" ID is read. The user storage capacity is the flash chip specification volume minus the reserved blocks minus the bad blocks.
The flash memory system can have one or more flash memory devices. The specific number of flash memory devices will depend on the requirements of the specific application. If more than one flash memory device is used, the flash memory devices are preferably the same make and type. However, they need not be the same make or typed.
FIG. 5 is a block diagram of a flash memory system 500 having two flash memory devices 502 and 504 using a dual channel configuration in accordance with the present invention. The flash memory devices 502 and 504 are coupled to a flash controller 506 via an input/output (I/O) bus 508. The I/O bus 508 is double the width of a bus that would be used for only one flash memory device. Accordingly, the performance of the I/O bus 508 is twice as fast as a bus using single line control logic.
The flash memory devices 502 and 504 are 8-bit devices and the address space of the flash memory devices 502 and 504 are rearranged by interface logic to enable access to them. Their sector sizes are 512 bytes. The ready/busy# line (labeled "FE_RB#") indicates an internal busy status.
FIG. 6 is a diagram of flash memory structures 602 and 604 for the flash memory devices 502 and 504, respectively, of FIG. 5 in accordance with the present invention. The flash memory structures 602 and 604 are similar to the flash memory structure of FIG. 4, except that the physical addresses of flash memory are separated into two flash memory devices. The flash memory structure 602 is designated for even bytes, and the flash memory structure 604 is designated for odd bytes.
FIG. 7 is a data write timing diagram for the flash memory system 500 of FIG. 5 in accordance with the present invention. First, during a command phase (labeled "CMD_WR"), a command is written to the flash memory devices 502 and 504 in accordance with their flash memory specifications. Next, during an address phase (labeled "Column Addr" and "Row Addr"), the column and row addresses are accessed in two separate consecutive cycles. The specific number of cycles will depend on the specific application. Next, during a data phase (labeled "D0"−"D3"), data sent accessed to the flash memory devices 502 and 504. This is done in a staggered format to gain performance. Two sector buffers, each having 512 bytes, are used for odd and even bytes sent to the flash memory devices 502 and 504. In a final phase (labeled "CMD_Confirm"), error correction code (ECC) bytes associated with odd bytes are written in spare locations of each sector. With regard to the last signal (FO_RB#), the waveform represents the Ready/Busy pin output for flash memory device 504. The FO_RB# pin is un-connected. Because the RB# pins for the flash memory devices 502 and 504 are tri-stated, they can alternatively be tied together.
FIG. 8 is a block diagram of a flash memory system 800 including two interleaved flash memory devices 802 and 804 in accordance with the present invention. The flash memory devices 802 and 804 are coupled to a flash controller 806 via an I/O bus 808. The flash memory devices 802 and 804 timeshare the I/O bus 808. Accordingly, commands can be sent to both flash memory devices 802 and 804 to fully utilize the bandwidth of the I/O bus 808. Because the I/O bus 808 is shared, the flash controller 806 pin count is reduced. While the flash memory devices 802 and 804 share the I/O bus 808, they each have separate chip enable lines (labeled "FE_CE#" and "FO_CE#") and ready/busy lines (labeled "FE_RB#" and "FO_RB#").
FIG. 9 is a diagram of flash memory structures 902 and 904 for the flash memory devices 802 and 804, respectively, of FIG. 8 in accordance with the present invention. The flash memory structures 902 and 904 are similar to the flash memory structures 602 and 604 of FIG. 6. All data from the registers, the library image file, and the boot and control codes are aligned sequentially and separated into the two flash memory structures 902 and 904. As shown, the flash memory structure 902 is designated for a first series of bytes (labeled "D0-D511"), and the flash memory structure 904 is designated for a first series of bytes (labeled "D512-D1023").
FIG. 10 is a diagram of flash memory structures 1002 and 1004 for the flash memory devices 802 and 804, respectively, of FIG. 8 in accordance with another embodiment of the present invention. The flash memory structures 1002 and 1004 differ from the flash memory structures 902 and 904 of FIG. 9 because the registers, boot code, and control code, library image file, bad block map, and operation registers are stored on one flash memory device. The interleave feature can be turned on after the control code is successfully downloaded. The interleave feature is turned off every time the bad block map or other bits are changed. This is also the case with the dual channel feature described above.
FIG. 11 is a timing diagram for the flash memory system of FIG. 8 in accordance with the present invention. Access to the flash memory devices begins with the first flash memory device and continues with the second flash memory device. Because the I/O bus is timeshared between the first and second memory devices, access alternates between the two. The sequence is similar to that of the timing diagram of FIG. 7. With both flash memory devices, after a confirm-command is issued, a CE# is released and an RB# is asserted for internal busy status.
FIG. 12 is a chart showing an organization of data in accordance with the present invention. Information critical to the operation of a flash memory device is provided by the manufacture. The control code provides this information to the flash controller. Each brand and type of flash memory device has its own addressing scheme and capacities. The operating register in the flash memory device provides this information, which can be grouped together into one page for easy access by the flash controller. The data organization of two major brands of flash memory, Maker T and Maker S, are shown. The first set of data includes the maker code. The second set of data includes the device ID. All brands and types of flash memory have an associated device ID. A special command ("code 90") is issued after a second address phase. This is the only necessary control for reading flash the device ID. The third set of data includes the internal chip number and cell type.
The fourth set of data returned has different meanings for different flash devices. For example, an error correction code (ECC) generation circuit will be a 1-bit circuit if using a single level cell (SLC) cell structure or will be a 4-bit circuit if using multi-level cell (MLC) cell structure. The operating registers also include an address cycle register, which facilitates read/write access. Other necessary information includes block size, page size, and spare size.
If more that one flash memory device is used, the ROM need only read the first flash memory device to gather needed information. If multiple brands or types of flash memory devices are used, the ROM would read each device. If more than one flash memory device is used, the same brand and type is preferred in order to minimize the control code.
FIG. 13 is a timing diagram for a flash memory system in accordance with the present invention. In a first phase, a read ID command is issued. In a second phase, an address is determined. In a third phase, the maker code is read. In a fourth phase, the device code is read. In a fifth phase, other types of data are read. This data includes page size, block size, spare size, etc.
FIG. 14 is a flow chart showing a method for programming a flash card using a manufacturer host in accordance with the present invention. An interrupt service routine is executed when a power-on reset is detected in the flash memory system, in a step 1402. The power-on reset is detected when the flash memory system is connected to the manufacturer host or when host power is turned on after a flash memory system has been connected to a host system. A voltage sensor in the flash memory system checks the incoming voltage as it increases to an operating voltage. A global reset synchronizes all state machines in the flash memory system and initializes all local registers to default values. The reset signal is removed when the PLL is stabilized.
A first command ("CMD0") from the manufacturer host is issued, in a step 1404. The first command initializes all of the state machines in the flash memory system.
Next, local registers are checked to ensure that they function properly, in a state 1406. If the local registers fail the check, they are rejected and failures are recorded, in a step 1408. Next, the flash memory device ID is read, in a step 1410. ROM code instructs the CPU to send the flash commands to a flash interface circuit for this purpose. Next, local control registers will be loaded for correct operation, in a step 1412. This is performed while reading parameters of the flash memory device. The parameters include address phase cycles and sizing registers, which are different for different types of flash memory devices.
After completion of steps 1410 and 1412, the flash memory system goes into a command waiting state, remaining responsive to further instructions, in a step 1414. Such instructions can include a special manufacturer host inquiry or a command. The manufacturer host uses a special command to initiate the programming. If a special manufacturer inquiry is received, in a step 1416, the flash memory system provides the type of flash memory device to the manufacturer host, in a step 1418. The type is typically provided in 4 bytes. The manufacturer host uses this information to determine the physical address of system data for the flash memory device, and writes this information to a library image file. Next, a manufacturer host sends the information file to the flash memory system, in a step 1420. The information is associated with the specific type of flash memory device and includes a library image file, card non-volatile registers, bad block maps, and operation registers. The operation registers include boot and control code starting addresses, flip pointers, and the capacity of the flash memory.
If a normal command ("CMD1") is received, in a step 1422, the flash card goes into a normal operating mode, in a step 1424. If not, a pre-hardcode VDD voltage profile is sent back, in a step 1426. The last bit, which is a busy bit, is set. The last bit indicates that the flash memory system is either "busy" (set) or is "not ready" (cleared). Next, it is determined whether the control code engine is running, in a step 1428. Next, the busy bit is cleared, in a step 1430, unless the control code engine is running.
After the step 1420, the flash card goes into programming mode, in a step 1440. The following steps are directed to programming the flash memory device. First, a primary partition is created, and the flash memory device is formatted with file structure information, in a step 1442. The file structure information can include a master block record (MBR), a partition block record (PBR), and an initial root directory and FAT16 information. The specific file structure information required will depend on the type of operation system of the host (e.g., PC, Linux or Mac OS).
Next, a write/read test is performed, in a step 1444. During this test, bad blocks are identified and handled accordingly, in a step 1446. Next, it is determined whether the number of bad blocks exceeds a specified number, in a step 1448. If so, a failure report is generated, in a step 1450. If not, a bad block map is established, in a step 1452. Bad blocks are recorded in the bad block map. Next, the user data section is erased, in a step 1454. The sections storing system data and non-volatile registers are not erased. Next, the manufacturer hose is flagged when the programming is completed, in a step 1456.
FIG. 15 is a flow chart showing a method for programming a flash card using a flash programmer in accordance with the present invention. In this specific embodiment, the flash programmer is a Jedec flash programmer instead of a manufacturer programmer. A Jedec Flash programmer directly programs flash memory. Each flash device has a unique coding sequence, which is handled by the Jedec flash programmer.
First, an interrupt service routine is executed, in a step 1502. The interrupt service routine is the same as steps 1402-1420 of FIG. 14. Next, the last available block of the flash memory is programmed, in a step 1504. The capacity of the flash memory is known before programming. Next, a block address is selected, in a step 1506. Next, an address is determined for non-volatile (NV) card register address, in a step 1508. Next, NV registers are programmed, in a step 1510. These registers include a card ID (CID) register and a card specific data (CSD) register. The card ID (CID) register includes several sections of ID, manufacturer ID (MID), original equipment manufacturer ID (OEM ID, or OID), product name (PNM), revision (PRV), and serial number, data, CRC7 values for checksum use. The CSD register provides information on how to access the card contents. All of the initial default values are stored in three pages. Read-only data are in one page. The user write-once field is on a different page, such that second programming cannot access this page, an example is card file format or one-time-programming (OTP).
All 127 bits are stored in a one page/sector for easier read access. Every card is programmed as a unique number. Next, an operation condition register (OCR) is programmed, in a step 1512. The OCR contains a card voltage window that the host must know in order to work properly. For example, if the host only supports 3.3V and the card OCR informs the host that the flash card is a 5V device, the card should not operate in the system.
Programming part of the register is achieved by using CMD27, the address of the register which is part of the flash memory physical address is known by firmware, but not accessible to end users.
A relative card address (RCA) register and a driver stage register (DSR) is programmed with default values, which can be later modified. For easier flash programming, a logical one (or "1") in a flash memory cell is defined as a default value. For example, "1" is busy if the initial card powers up. It is "0" if not busy or the card is finished with the power up sequence.
Next, a predetermined flash memory library image file is programmed, in a step 1514. The library image file stores parameters for the flash memory and is organized, for easy access, as one page. The flash memory interface circuit uses the library image file for command decoding and access timing.
Next, address entry points are determined for boot code and control codes, in a step 1516. Next, the address for the boot code is determined, in a step 1518. Next, the boot code is programmed in the flash memory, in a step 1520. Two copies of the boot code are stored. Next, a boot address pointer is initialized, in a step 1522. Next, the DMA engine and boot registers are set, in a step 1524. The DMA engine is used during a normal code relocation process. Three units are defined to facilitate this feature: the flash physical starting address register; the page length register of transfer; and the main memory address is relocated.
Next, the control code is programmed in the flash memory, in a step 1526. Two copies of the control code are stored. Next, a toggle control address pointer is initialized, in a step 1528. Next, the DMA engine and control registers are set, in a step 1530.
Next, it is determined whether the programming failed, in a step 1532. If programming fails, the last block is marked with a bad block flag ("0"), in a step 1534. The block address is changed to the previous block (last −1), in a step 1536, and the process starts over again. If in step 1514, the programming did not fail, the block number is decremented, in a step 1538. Next, the block number cleared, in a step 1540.
FIG. 16 is a flow chart showing a method for booting a flash card in accordance with the present invention. First, the power-on reset is executed, in a step 1602. This occurs when the flash card is connected to a user host. Next, the reset to card CPU causes an issued resetting address to jump to a main routine of ROM code, in a step 1604. Next, a device ID is read, in a step 1606. This step is initiated by a 90h command. Next, a "00h" address phase is initiated, in a step 1608. Next, a maker code is returned by the flash memory device if the CE# is active, in a step 1610. Various branches of software can be followed, depending on the maker code.
Next, a device code is read, in a step 1612 a or 1612 b, depending on the maker code (e.g., maker S or maker T). After all of the information is read, it is sent to the manufacturer host, in a step 1614. Next, the manufacturer host writes local volatile registers to the flash memory device, in a step 1616. The manufacturer host also writes the correct library image file to the final blocks of the flash memory.
The ROM sets up operating registers. Once the registers are set, a flash interface circuit can work properly to facilitate the manufacturer host in downloading the library image file to the flash memory device. A short ROM code is desired to facilitate the flash card in recognizing the flash memory device.
FIG. 17 is a flow chart showing a method for testing a flash card before shipping in accordance with the present invention. First, the manufacturer host is initialized, in a step 1702. The manufacturer host functions as a tester host. The manufacturer host can be a PC with a card reader and a USB or PCMCIA interface. Next, the flash card is connected into the manufacturer host, in a step 1704. For volume production, multiple flash cards can be plugged into the system to increase testing efficiency. Next, a card detection test is executed, in a step 1706. Next, if a failure is detected, in a step 1708, the flash card is marked as defective, in a step 1710. If no failure is detected, the flash card is configured, in a step 1712. The flash card undergoes a low-level format. Next, if a configuration failure is detected, in a step 1714, the flash card is marked as defective, in the step 1710. If no failure is detected, a flash card format test is executed, in a step 1716.
The flash card is formatted to a specified file system. For example, Windows 98 requires a FAT16 system for a total file storage capacity under 128 M bytes, because a 64 K cluster entry covers an entire FAT16 addressing range if the sector size is 512 bytes long. Window 2000 requires a FAT32 system for larger disk capacity. To guarantee a file read capability, FAT16 is assumed for backward compatibility as the default file system. The test program creates a partition table and then executes the formatting. Next, if a format failure is detected, in a step 1718, the flash card is marked as defective, in a step 1710. Next, it is determined if the flash card capacity matches the capacity of the specification, in a step 1720. If the flash card capacity does not match that of the specification, the flash card is marked as defective, in the step 1710. If the flash card capacity matches that of the specification, a card function test is executed, in a step 1722.
Next, if a failure is detected, in a step 1724, the flash card is marked as defective, in the step 1710. If no failure is detected, a serial number is written to the flash card, in a step 1726. Next, the initial flash card capacity is checked, in a step 1728. The flash card capacity needs to be cleared and available before shipping. Accordingly, an erase-whole-card action is performed to reset all user accessible bits to "1"s, except for the necessary tables, registers, etc.
Next, if the flash card is determined not be empty, in a step 1730, the flash card is marked as defective, in the step 1710. If the flash card is empty, the control and status register (CSR), the CID, and the OCR of the flash card is checked, in a step 1732.
Next, if it is determined that the CSR and the CID do not match those of the specification, in a step 1734, the flash card is marked as defective, in the step 1710. If there is a match, the testing sequence is complete.
FIG. 18 is a block diagram of memory structures in accordance with the present invention. The software structures include short ROM code 1802, boot code 1804, and control code 1806. One of two modes is selected when the flash card is turned on. One mode is program mode, where flash memory can be programmed as described above. The other mode is normal mode, where the flash card undergoes a normal user power-on sequence.
The type of mode is determined by the command received by the flash card. A manufacturer host would issue a command putting the flash card in programming mode. While in programming mode, the flash image file can be downloaded into the flash card. A user host (e.g., digital camera) would issue a command putting the flash card in normal mode. While in normal mode, the flash card undergoes a normal user power-on sequence.
To minimize the amount of coding in the ROM, a simple sector flash write routine and a basic response back to the manufacturer host are supported in the ROM.
After the manufacturer host knows the type of flash, an image data file is written to the predetermined final block(s) of flash memory before the flash card is shipped to the end user. Alternatively, if the manufacturer already knows the type of flash memory, the image data file can be written to the flash memory without having to determine the type of flash memory.
During normal mode, a power-on reset occurs when the card is first connected to a user host. The flash device ID cycle is issued to fill the local flash interface registers for fetching operations. After a power-on reset, the ROM code 1802 checks the flash card by performing write/reads to all internal volatile registers. A device ID is then read, and parameters are stored in the operation registers of the flash card.
The boot code is needed for DMA download to the main memory (RAM). The DMA download enables fast access to the flash memory device. Because the boot code and control code is stored in the flash memory device, the ROM code can be simple and short. An interrupt service routine (ISR) reserves all entry point addresses. The ISR supports both commands for programming mode and normal mode. At the end of the ROM code, control is passed to the boot code for necessary system operation.
The boot code downloads a more complex control code to the main memory from the reserved blocks of the flash memory device. Control is then passed to the control code. A boot code engine reduces the ROM size and enables the flash card to execute code faster, since the boot code and the control code is fetched from the RAM.
The control code engine handles all flash card protocol commands.
FIG. 19 is a flow chart showing a method for powering up a flash card during normal operation in accordance with the present invention. After being programmed by the manufacture, the flash card can be used by a user normal mode. In the flash cards normal-mode initial state, the flash device type is already known from pre-shipping programming. The flash device type is stored in the flash cards local flash registers.
First, local volatile copies of DMA engine registers are set up, in a step 1902. Next, a direct memory access (DMA) engine is initialized, in a step 1904. As a part of the DMA engine initialization, local registers are programmed. Next, the boot code is read from the flash memory device and is written to the main memory, in a step 1906. The DMA engine transfers the boot code to the main memory. As a part of the boot code read, the boot code's starting physical sector address and its sector length are read. Next, it is determined whether the transfer is complete, in a step 1908. If not, the transfer step 1906 is repeated. If the transfer is complete, the checksum (CRC16) of the boot code is checked to ensure it is correct, in a step 1910. If not, the flash card enters an error handler state, in a step 1912. Next, a flip pointer is toggled to fetch the backup copy of the boot code in the flash memory, in a step 1914. Next, DMA process is repeated starting at the step 1904. Any errors are recorded by incrementing a counter that keeps count of the number of failures. If at step 1910, the checksum is determined to be correct, the boot code engine activated, in a step 1916.
Next, the boot code is executed from the main memory, in a step 1918. Next, all blocks are scanned for bad blocks, and a bad block map is established, in a step 1920. Upon completion of the scanning, the user data capacity is known to the flash memory system and is stored in a non-volatile register. The bad block map is located in the final block of the flash memory device, and in the first flash memory device if more than one device is used. Next, bad blocks are skipped and recorded in the bad block map, in a step 1922. Next, it is determined whether the number bad blocks exceeds a predetermined tolerance, in a step 1924. If yes, the flash card is designated as a failure and a warning is issued, in a step 1926. If not, the control code is read from the flash memory device and is written to the main memory, in a step 1928. Next, the checksum (CRC16) of the control code is checked if correct, in a step 1930. If not, the backup copy of the control code transferred to the main memory, in a step 1932, and the checksum is checked, in the step 1930. If the checksum is correct, control is passed from the boot code engine to the control code engine, in a step 1934. Next, after the flash memory system has booted up, and after the loading of the control code into the main memory, the memory space occupied by the boot code is freed up for other purposes, in a step 1936. As such, execution of the control code becomes more efficient.
FIG. 20 is a flow chart showing a method for implementing control code during normal operation in accordance with the present invention. Once control code engine is initiated, a busy bit in the operation control register (OCR) is cleared, in a step 2002. Next, the control code is ready to accept further host commands and waits, in a step 2004. Next, it is determined whether the waiting time has exceeded a predetermined time limit, in a step 2006. If yes, a power saving state is initiated, in a step 2008, before receiving a new host command, in a step 2010. If the waiting time has not exceeded the predetermined time limit, the control code continues to wait until the predetermined limit is exceeded or a host command is received, in the step 2010.
Any command received, triggers an appropriate interrupt service routine, in a step 2012. Next, the command is decoded so that the control code can perform the specified task (e.g., data transferring, ID recognizing, etc.), in a step 2014. Another feature of the present invention is that a user can update the boot code or control code during field operation. This feature is valuable whenever a bug occurs or is discovered in the boot code or the control code after the flash card is shipped. As stated previously, a second copy of the boot code and the control code is stored in the flash memory in case an error occurs during the update.
In the step 2010, the host command can include a special update command, in a step 2016. The updated boot code or control code can be downloaded using a PC from various sources such as the Internet. In a specific embodiment, the updated code contains the special update command. A flip pointer points to the location of updated code copy, in a step 2018. After a successful update, the flip pointer is toggled for next revision.
Next, the checksum of the updated copy is compared to that of the old copy, in a step 2020. Next, it is determined whether the checksums match, in a step 2022. If they match, the update process is complete. If they don't match, the flip pointer is used to determine which copy to update, in a step 2024. Next, the appropriate copy is updated, in a step 2026. Next, it is determined whether the update is complete, in a step 2028. If not, the step 2026 is repeated. If the transfer is completed, the checksums checked to ensure it is the correct checksum, in a step 2030. If not, the update process repeats from the step 2018. If the checksum is correct, the address pointer is toggled, in a step 2032, before the update process is complete.
The control code can be big, since it handles the update process. However, because the control code is stored in flash memory instead of in the fixed ROM, it provides much flexibility and value to support in the field.
FIG. 21 is a side-view diagram of a conventional multimedia card (MMC) 2100. The MMC 2100 includes a printed circuit board (PCB) 2102, a flash memory device 2104, a flash controller 2106, and a cover or housing 2108. Conventional flash cards have many form factors. MMCs have strict height limitations, about 1.4 mm. This forces the flash memory device 2104 and the flash controller 2106 to use a very-very-small-outline-package (WSOP), about 0.7 mm in height. This height restriction increases the cost of card production, because it is difficult to handle thin package ICs. Also, handling the die alone (i.e., without a package) is even more difficult during board production.
FIG. 22 is a side-view diagram of an MMC 2200 in accordance with the present invention. The MMC 2200 includes a printed circuit board (PCB) 2202, a flash memory device 2204, a flash controller 2206, a cover 2208, and metal contact pads 2210. To overcome the difficulty of the conventional MMC, a thin-small-outline-package (TSOP), 1.1 mm in height, for the flash memory device can be used with the present invention. The flash controller can still use a WSOP package. As a result, the height position of the PCB can be increased on one end of the MMC 2200. For example, the height could be increased such that the cover height has about 2.1 mm thickness form factor (+−0.3 mm). Allowing the extra height can relieve the low-yield production problem, and can make it easier to insert the MMC into a host receptacle. As shown, the PCB 2202 is tilted at one end of the MMC 2200.
The flash memory device 2204 and the flash controller 2206 are located on the same side of the PCB 2202. The metal contact pads 2210 located near the leading edge of PCB 2202 on the opposite side of the PCB 2202. The PCB 2202 is positioned with a small inclined angle as it is tilted up slightly in the leading edge. The tilting results in more available space above PCB toward its trailing edge. As a result, the requirement to meet the minimum wall thickness and flexibility in the selection of flash memory chips (e.g., TSOP with a thickness of 0.1 mm) can be fulfilled and relaxed. On the other end, the metal contact pads 2210 are slightly tilted, in the same orientation of PCB 2202. The metal contact pads are received in a receptacle inside a user host (not shown) via a flexible spring (not shown). The tilted orientation enables a firm electrical contact from between the flash card and the host.
FIG. 23 is a side-view diagram of a conventional MMC. The MMC 2300 includes a printed circuit board (PCB) 2302, a flash memory device 2304, a flash controller 2306, a cover 2308, and metal contact pads 2310. A clearance of 0.7 mm under the metal contact pads 2310 is maintained in the card with a total thickness of at least 2.1 mm. This leaves the space above PCB 2302 to be about 1.1 mm. Using a PCB 2302 with a thickness of about 0.3 mm accommodates all of the IC's and the upper portion of the cover. The minimum thickness requirement for the cover is about 0.3 mm, based on standard industrial practice. This leaves about 0.8 mm for the IC's mounted above the PCB.
The disadvantage with the conventional MMC of FIG. 23 is that the PCB 2302 must be bent in two places order to accommodate the flash memory device 2304 and the flash controller 2306. As shown, the PCB 2302 is bent between the flash memory device 2304 and the flash controller 2306. The PCB is also be bent between the flash controller 2306 and the metal contact pads 2310. Such bends introduce undesired complexity and increased manufacturing costs. In contrast, the MMC of FIG. 22 uses the PCB 2204, which is simpler and easier to make than the PCB 2302 of FIG. 23.
FIGS. 24 a, 24 b, and 24 c are top-view, back-view, and side-view diagrams, respectively, of a conventional MMC 2400. The MMC 2400 has a form factor with a thickness of 1.4 mm.
FIGS. 25A, 25B, and 25C are top-view, back-view, and side-view diagrams, respectively, of a multimedia card (MMC) 2500 in accordance with the present invention. The MMC 2600 has a cover with a form factor of 2.1 mm, like that of the secure digital (SD) card form factor. Under most circumstances, a user host with an SD mechanical socket can receive both MMC and SD card protocols, because the location of the MMC metal contact pad coincides with that of the SD standard.
Because none of the write-protect hardware has been defined in the MMC specification, the data stored in a card having an MMC form factor are subject to accidental removal. This can result in data loss in personal and/or business applications. The embodiment described herein enables MMC functionality in a SD form factor, while leveraging the write-protect feature that is available in SD products. The electrical-mechanical contact inside a host device (not shown) is established, and the write-protect is activated when the card is inserted and the write-protect switch in the card is set in a proper position.
SD card protocol support extra commands such as ACMD41, which the MMC protocol does not. During the power-on card ID recognizing process, a user host knows this difference by probing with an extra command and branches to different identification states without confusion.
The present invention can be applied to any controller-embedded Flash card including but not limited to MultiMediaCard (MMC), Secure Disk (SD), Memory Stick (MS), Compact Flash (CF), as well as USB controller-based flash memory devices.
According to the system and method disclosed herein, the present invention provides numerous benefits. For example, it enables the boot and control codes to be updated in the field without having to change the flash controller. Also, it enables the flash controller to support various brands and types of flash memory devices. Also, because the boot and control codes are stored in the flash memory instead of the ROM, the code in the ROM is minimized. As a result, the ROM can be made smaller.
A system in accordance with the present invention for providing a flash memory system has been disclosed. The flash memory system stores boot code and the control code in the flash memory instead of in the ROM. As a result, the boot and control codes can be updated in the field without having to change the flash controller.
The present invention has been described in accordance with the embodiments shown. One of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and that any variations would be within the spirit and scope of the present invention. For example, the present invention can be implemented using hardware, software, a computer readable medium containing program instructions, or a combination thereof. Software written according to the present invention is to be stored in some form of computer-readable medium, such as memory or CD-ROM, or is to be transmitted over a network, and executed by a processor. Consequently, a computer-readable medium is intended to include a computer readable signal, which may be, for example, transmitted over a network. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.
1. A flash memory card system comprising:
a flash controller; and
at least one flash memory device coupled to the flash controller, wherein boot code and control code are stored in the flash memory device.
2. The system of claim 1 wherein the flash memory stores two copies of the boot code.
3. The system of claim 2 wherein during an update, one of the two copies of the boot code is updated and the other of the two copies remains a backup copy.
4. The system of claim 1 wherein the flash memory stores two copies of the control code.
5. The system of claim 4 wherein during an update, one of the two copies of the control code is updated and other of the two copies remains a backup copy.
6. The system of claim 1 wherein the flash controller comprises a main memory.
7. The system of claim 6 wherein the boot code and the control code are transferred from the flash memory device to the main memory when the flash memory system is booted.
8. The system of claim 7 wherein direct memory access (DMA) is used to transfer the boot code and the control code from the flash memory to the main memory.
9. The system of claim 7 wherein the boot code is transferred to the main memory before the control code is transferred to the main memory, and wherein the flash memory system frees up memory space in the main memory occupied by the boot code after the control code is transferred to the main memory.
10. The system of claim 1 wherein the flash controller can support multiple brands and multiple types of flash memory.
11. The system of claim 1 wherein the flash controller can interleave multiple flash memory devices.
12. The system of claim 1 wherein the flash controller can perform multiple channel operations.
13. The system of claim 12 wherein the multiple channel operations comprise dual channel operations.
14. The system of claim 1 wherein the circuit can be applied to flash cards comprising MultiMediaCard (MMC), Secure Disk (SD), Memory Stick (MS), Compact Flash (CF), and USB controller-based flash memory devices.
15. The system of claim 1 further comprising:
a printed circuit board (PCB) coupled to the flash controller and the at least one flash memory device; and
a cover, wherein the PCB is tilted relative to the cover.
16. The system of claim 15 wherein the cover has a height of substantially 2.1 mm.
17. The system of claim 15 wherein the at least one flash memory device is mounted to one side of the PCB and the flash controller is mounted to the same side of the PCB.
18. The system of claim 17 wherein the positions of the at least one flash memory device and the flash controller are offset longitudinally such that an unpopulated space exists between the flash memory device and the flash controller.
19. The system of claim 15 wherein the system can be received in a secure digital (SD) card socket.
20. A flash memory system comprising:
a host;
at least one flash memory device coupled to the flash controller, wherein boot code and control code are stored in the flash memory device, wherein the host downloads the boot code and the control code into the flash memory device.
21. The system of claim 20 wherein the host downloads the boot code and the control code into the flash memory device via the flash controller.
22. The system of claim 20 wherein the host downloads the boot code and the control code into the flash memory device directly.
23. The system of claim 20 wherein the host is a Jedec flash programmer.
24. The system of claim 20 wherein the host is a user host.
25. The system of claim 20 wherein the flash memory stores two copies of the boot code.
26. The system of claim 25 wherein during an update, one of the two copies of the boot code is updated and the other of the two copies remains a backup copy.
27. The system of claim 20 wherein the flash memory stores two copies of the control code.
28. The system of claim 27 wherein during an update, one of the two copies of the control code is updated and other of the two copies remains a backup copy.
29. The system of claim 20 wherein the flash controller comprises a main memory.
30. The system of claim 29 wherein the boot code and the control code are transferred from the flash memory device to the main memory when the flash memory system is booted.
31. The system of claim 30 wherein direct memory access (DMA) is used to transfer the boot code and the control code from the flash memory to the main memory.
32. The system of claim 30 wherein the boot code is transferred to the main memory before the control code is transferred to the main memory, and wherein the flash memory system frees up memory space in the main memory occupied by the boot code after the control code is transferred to the main memory.
33. The system of claim 20 wherein the flash controller can support multiple brands and multiple types of flash memory.
34. The system of claim 20 wherein the flash controller can interleave multiple flash memory devices.
35. The system of claim 20 wherein the flash controller can perform multiple channel operations.
37. The system of claim 20 wherein the circuit can be applied to flash cards comprising MultiMediaCard (MMC), Secure Disk (SD), Memory Stick (MS), Compact Flash (CF), and USB controller-based flash memory devices.
38. The system of claim 20 further comprising:
43. A method for implementing a flash memory system, the method comprising:
providing a flash memory device; and
storing boot code and control code in the flash memory device.
44. The method of claim 43 wherein the storing step comprises downloading the boot code and the control code into the flash memory device utilizing a host.
45. The method of claim 44 wherein the host is a Jedec flash programmer.
46. The method of claim 43 wherein the storing step comprises downloading at least two copies of the boot code.
47. The method of claim 43 wherein the storing step comprises downloading at least two copies of the control code.
48. The method of claim 43 further comprising testing the flash memory system before shipping.
49. The method of claim 48 wherein the testing comprises determining if attributes of the flash memory system match those of the specification
50. The method of claim 43 further comprising updating the boot code in the flash memory.
51. The method of claim 43 further comprising updating the control code in the flash memory.
52. The method of claim 43 further comprising transferring the boot code and the control code from the flash memory device to a main memory when the flash memory system is booted.
53. The method of claim 52 further comprising transferring the boot code and the control code from the flash memory device to the main memory utilizing a direct memory access (DMA).
54. The method of claim 52 wherein the boot code is transferred to the main memory before the control code is transferred to the main memory.
55. The method of claim 54 further comprising freeing up memory space in the main memory occupied by the boot code after the control code is transferred to the main memory.
56. The method of claim 43 wherein the method can be applied to flash cards comprising MultiMediaCard (MMC), Secure Disk (SD), Memory Stick (MS), Compact Flash (CF), and USB controller-based flash memory devices.
57. A computer readable medium containing program instructions for implementing a flash memory system, the program instructions which when executed by a computer system cause the computer system to execute a method comprising:
58. The computer readable medium of claim 57 wherein the storing step comprises program instructions for downloading the boot code and the control code into the flash memory device utilizing a host.
59. The computer readable medium of claim 58 wherein the host is a Jedec flash programmer.
60. The computer readable medium of claim 57 wherein the storing step comprises program instructions for downloading at least two copies of the boot code.
61. The computer readable medium of claim 57 wherein the storing step comprises program instructions for downloading at least two copies of the control code.
62. The computer readable medium of claim 57 further comprising program instructions for testing the flash memory system before shipping.
63. The computer readable medium of claim 62 wherein the testing step further comprises program instructions for determining if attributes of the flash memory system match those of the specification
64. The computer readable medium of claim 57 further comprising program instructions for updating the boot code in the flash memory.
65. The computer readable medium of claim 57 further comprising program instructions for updating the control code in the flash memory.
66. The computer readable medium of claim 57 further comprising program instructions for transferring the boot code and the control code from the flash memory device to a main memory when the flash memory system is booted.
67. The computer readable medium of claim 66 further comprising program instructions for transferring the boot code and the control code from the flash memory device to the main memory utilizing a direct memory access (DMA).
68. The computer readable medium of claim 66 wherein the boot code is transferred to the main memory before the control code is transferred to the main memory.
69. The computer readable medium of claim 68 further comprising program instructions for freeing up memory space in the main memory occupied by the boot code after the control code is transferred to the main memory.
70. The computer readable medium of claim 57 wherein the computer readable medium can be applied to flash cards comprising MultiMediaCard (MMC), Secure Disk (SD), Memory Stick (MS), Compact Flash (CF), and USB controller-based flash memory devices.
US10/957,089 2004-10-01 2004-10-01 Flash card system Abandoned US20060075395A1 (en)
US10/957,089 US20060075395A1 (en) 2004-10-01 2004-10-01 Flash card system
US11/742,270 US7660941B2 (en) 2003-09-10 2007-04-30 Two-level RAM lookup table for block and page allocation and wear-leveling in limited-write flash-memories
US11/767,417 US7818492B2 (en) 2004-02-26 2007-06-22 Source and shadow wear-leveling method and apparatus
US11/774,906 US7769944B2 (en) 2004-10-01 2007-07-09 Partial-write-collector algorithm for multi level cell (MLC) flash
US11/779,804 US7680977B2 (en) 2004-02-26 2007-07-18 Page and block management algorithm for NAND flash
US11/864,652 US7676640B2 (en) 2000-01-06 2007-09-28 Flash memory controller controlling various flash memory cells
US11/924,448 US20080192928A1 (en) 2000-01-06 2007-10-25 Portable Electronic Storage Devices with Hardware Security Based on Advanced Encryption Standard
US12/119,477 US20080256352A1 (en) 2000-01-06 2008-05-12 Methods and systems of booting of an intelligent non-volatile memory microcontroller from various sources
US12/947,211 US8296467B2 (en) 2000-01-06 2010-11-16 Single-chip flash device with boot code transfer capability
US10/800,228 Continuation-In-Part US7082056B2 (en) 2004-03-12 2004-03-12 Flash memory device and architecture with multi level cells
US10/956,826 Continuation-In-Part US7299316B2 (en) 2004-02-26 2004-10-01 Memory flash card reader employing an indexing scheme
US11/309,594 Continuation-In-Part US7383362B2 (en) 2003-12-02 2006-08-28 Single-chip multi-media card/secure digital (MMC/SD) controller reading power-on boot code from integrated flash memory for user storage
US11/864,696 Continuation-In-Part US8073985B1 (en) 1999-10-19 2007-09-28 Backward compatible extended USB plug and receptacle with dual personality
US12/426,378 Continuation US7865630B2 (en) 2003-12-02 2009-04-20 Single-chip multi-media card/secure digital (MMC/SD) controller reading power-on boot code from integrated flash memory for user storage
US09/478,720 Continuation-In-Part US7257714B1 (en) 1999-10-19 2000-01-06 Electronic data storage medium with fingerprint verification capability
US10/789,333 Continuation-In-Part US7318117B2 (en) 2004-02-26 2004-02-26 Managing flash memory including recycling obsolete sectors
US11/742,270 Continuation-In-Part US7660941B2 (en) 2003-09-10 2007-04-30 Two-level RAM lookup table for block and page allocation and wear-leveling in limited-write flash-memories
US11/767,417 Continuation-In-Part US7818492B2 (en) 2004-02-26 2007-06-22 Source and shadow wear-leveling method and apparatus
US11/774,906 Continuation-In-Part US7769944B2 (en) 2004-10-01 2007-07-09 Partial-write-collector algorithm for multi level cell (MLC) flash
US11/779,804 Continuation-In-Part US7680977B2 (en) 2004-02-26 2007-07-18 Page and block management algorithm for NAND flash
US11/864,652 Continuation-In-Part US7676640B2 (en) 1999-10-19 2007-09-28 Flash memory controller controlling various flash memory cells
US10/957,089 Abandoned US20060075395A1 (en) 2004-10-01 2004-10-01 Flash card system
US20060026462A1 (en) * 2004-07-07 2006-02-02 Hon Hai Precision Industry Co., Ltd. Apparatus for recovering BIOS in computer system
US20060176741A1 (en) * 2005-01-19 2006-08-10 Via Technologies Inc. Method and apparatus for driving flash memory
US20060187080A1 (en) * 2005-01-31 2006-08-24 Slatter David N Software updates for electronic appliances
US20060253484A1 (en) * 2005-05-03 2006-11-09 Bangalore Kiran Kumar G Flash memory directory virtualization
US20070050534A1 (en) * 2005-08-26 2007-03-01 Siliconmotion Inc. A method for supporting unrecognizable flash memory
US20070055823A1 (en) * 2005-08-01 2007-03-08 Samsung Electronics Co., Ltd. Multi-interface, controller, memory card having the multi-interface controller, and interface setting method
US20070074015A1 (en) * 2005-09-29 2007-03-29 Nec Corporation Control apparatus, upgrade method and program product of the same
US20070112979A1 (en) * 2005-11-16 2007-05-17 Phison Electronics Corp. [portable storage device with auto-executable program]
US20070118682A1 (en) * 2005-11-21 2007-05-24 Vimicro Corporation Method and apparatus for interfacing and managing NAND flash memory
US20080005471A1 (en) * 2000-01-06 2008-01-03 Super Talent Electronics, Inc. Flash Memory Controller For Electronic Data Flash Card
US20080010397A1 (en) * 2006-07-10 2008-01-10 Phison Electronics Corp. Flash memory with simulating system and method thereof
US20080049520A1 (en) * 2006-08-23 2008-02-28 Samsung Electronics Co., Ltd. Flash memory system and programming method performed therein
US20080086631A1 (en) * 2000-01-06 2008-04-10 Chow David Q Flash memory controller controlling various flash memory cells
WO2008074212A1 (en) * 2006-12-20 2008-06-26 Netac Technology Co., Ltd. Method for controlling flash memory
US20080162796A1 (en) * 2006-12-28 2008-07-03 Genesys Logic, Inc. Method for performing static wear leveling on flash memory
US20080228984A1 (en) * 2003-12-02 2008-09-18 Super Talent Electronics Inc. Single-Chip Multi-Media Card/Secure Digital (MMC/SD) Controller Reading Power-On Boot Code from Integrated Flash Memory for User Storage
US20080235486A1 (en) * 2007-03-20 2008-09-25 Micron Technology, Inc. Non-volatile memory devices, systems including same and associated methods
WO2008124177A1 (en) * 2007-04-10 2008-10-16 Marvell World Trade Ltd. Memory controller
US20090037643A1 (en) * 2006-01-23 2009-02-05 Noboru Ohtsuka Semiconductor memory device including control means and memory system
US20090307418A1 (en) * 2008-06-04 2009-12-10 Ming-Dar Chen Multi-channel hybrid density memory storage device and control method thereof
US20100017557A1 (en) * 2006-07-26 2010-01-21 Panasonic Corporation Memory controller, nonvolatile memory device,access device, and nonvolatile memory system
US20100095044A1 (en) * 2008-10-15 2010-04-15 Phison Electronics Corp. Motherboard system, storage device for booting up thereof and connector
US20100105251A1 (en) * 2007-07-05 2010-04-29 Super Talent Electronics, Inc. Micro-SD To Secure Digital Adaptor Card And Manufacturing Method
US20100138617A1 (en) * 2006-04-07 2010-06-03 Stmicroelectronics Sa Method for initializing a memory
US20100312947A1 (en) * 2009-06-04 2010-12-09 Nokia Corporation Apparatus and method to share host system ram with mass storage memory ram
US20110016088A1 (en) * 2009-07-20 2011-01-20 Spackman Stephen Philip System and method for performance and capacity monitoring of a reduced redundancy data storage system
US20110047366A1 (en) * 2009-08-21 2011-02-24 Micron Technology, Inc. Booting in systems having devices coupled in a chained configuration
US20110055625A1 (en) * 2009-08-28 2011-03-03 Toshiyuki Honda Nonvolatile memory device and memory controller
US20110252413A1 (en) * 2008-12-24 2011-10-13 Panasonic Corporation Bus controller and method for patching initial boot program
US20110271038A1 (en) * 2010-04-30 2011-11-03 Micron Technology, Inc. Indexed register access for memory device
US20110302358A1 (en) * 2007-02-22 2011-12-08 Super Talent Technology Corp. Flash-Memory Device with RAID-type Controller
US8166230B2 (en) * 2008-01-31 2012-04-24 Samsung Electronics Co., Ltd. Memory systems and methods of initializing the same
US20120110242A1 (en) * 2010-11-03 2012-05-03 Nvidia Corporation Programmable memory controller
US20120124417A1 (en) * 2010-11-11 2012-05-17 Samsung Electronics Co., Ltd. Display apparatus and method for updating micom code thereof
US20120173799A1 (en) * 2010-12-29 2012-07-05 Sony Corporation Data storage apparatus, information processing apparatus, information processing method, and program
US8429391B2 (en) 2010-04-16 2013-04-23 Micron Technology, Inc. Boot partitions in memory devices and systems
CN103823704A (en) * 2012-11-19 2014-05-28 群联电子股份有限公司 Flash memory simulation method and simulator
US20150006797A1 (en) * 2007-02-13 2015-01-01 Google Inc. Interface for extending functionality of memory cards
TWI479502B (en) * 2007-07-19 2015-04-01 Samsung Electronics Co Ltd Solid state disk controller and data processing method thereof
US9063850B2 (en) 2008-02-28 2015-06-23 Memory Technologies Llc Extended utilization area for a memory device
TWI492054B (en) * 2012-11-05 2015-07-11 Phison Electronics Corp Simulator and simulating method for flash memory
US9116820B2 (en) 2012-08-28 2015-08-25 Memory Technologies Llc Dynamic central cache memory
US20150280749A1 (en) * 2014-03-28 2015-10-01 Karsten Gjorup Boot management in a non-volatile memory system
US9164804B2 (en) 2012-06-20 2015-10-20 Memory Technologies Llc Virtual memory module
US9208108B2 (en) 2008-12-19 2015-12-08 Nvidia Corporation Method and system for improved flash controller commands selection
US20160055068A1 (en) * 2013-04-23 2016-02-25 Hewlett-Packard Development Company, L.P. Recovering from Compromised System Boot Code
WO2016048703A1 (en) * 2014-09-26 2016-03-31 Intel Corporation Nand memory addressing
US9311226B2 (en) 2012-04-20 2016-04-12 Memory Technologies Llc Managing operational state data of a memory module using host memory in association with state change
US9417998B2 (en) 2012-01-26 2016-08-16 Memory Technologies Llc Apparatus and method to provide cache move with non-volatile mass memory system
JP2016524771A (en) * 2014-06-27 2016-08-18 華為技術有限公司Huawei Technologies Co.,Ltd. How to update the program data and device
US9594675B2 (en) 2009-12-31 2017-03-14 Nvidia Corporation Virtualization of chip enables
US9990255B2 (en) 2013-04-23 2018-06-05 Hewlett-Packard Development Company, L.P. Repairing compromised system data in a non-volatile memory
US5502797A (en) * 1994-10-04 1996-03-26 Lexmark International, Inc. Apparatus with flash memory control for revision
US5596738A (en) * 1992-01-31 1997-01-21 Teac Corporation Peripheral device control system using changeable firmware in a single flash memory
US6272628B1 (en) * 1998-12-14 2001-08-07 International Business Machines Corporation Boot code verification and recovery
US6289449B1 (en) * 1998-12-14 2001-09-11 International Business Machines Corporation Creating boot code image on a storage medium
US6354858B1 (en) * 2000-08-17 2002-03-12 International Business Machines Corporation Retention apparatus for flash memory card
US20040139290A1 (en) * 2003-01-10 2004-07-15 Gilbert Wolrich Memory interleaving
US20040195339A1 (en) * 2003-04-02 2004-10-07 Carry Computer Eng. Co., Ltd. Micro card and passive commutate device suitable for micro card
US6823435B1 (en) * 1997-11-20 2004-11-23 Advanced Micro Devices, Inc. Non-volatile memory system having a programmably selectable boot code section size
US20040236936A1 (en) * 2003-05-21 2004-11-25 Mallik Bulusu Methods and apparatus to update a basic input/output system (BIOS)
US20040250057A1 (en) * 2003-05-07 2004-12-09 International Business Machines Corporation Startup system and method using boot code
US20050060528A1 (en) * 2003-09-17 2005-03-17 Samsung Electronics Co., Ltd. Booting and boot code update method and system thereof
US20050283598A1 (en) * 2004-06-22 2005-12-22 International Business Machines Corporation Method and system for loading processor boot code from serial flash memory
US7237103B2 (en) * 2004-02-18 2007-06-26 Wyse Technology, Inc. Computing device deployment using mass storage device
US7676640B2 (en) * 2000-01-06 2010-03-09 Super Talent Electronics, Inc. Flash memory controller controlling various flash memory cells
US7702831B2 (en) 2000-01-06 2010-04-20 Super Talent Electronics, Inc. Flash memory controller for electronic data flash card
US7552251B2 (en) * 2003-12-02 2009-06-23 Super Talent Electronics, Inc. Single-chip multi-media card/secure digital (MMC/SD) controller reading power-on boot code from integrated flash memory for user storage
US7215578B2 (en) * 2005-01-19 2007-05-08 Via Technology, Inc. Method and apparatus for driving flash memory
US7634494B2 (en) * 2005-05-03 2009-12-15 Intel Corporation Flash memory directory virtualization
US7987308B2 (en) * 2005-08-01 2011-07-26 Samsung Electronics Co., Ltd. Multi-interface controller, memory card having the multi-interface controller, and interface setting method
US7739490B2 (en) * 2005-09-29 2010-06-15 Nec Corporation Control apparatus, upgrade method and program product of the same
US8069296B2 (en) * 2006-01-23 2011-11-29 Kabushiki Kaisha Toshiba Semiconductor memory device including control means and memory system
US7925848B2 (en) * 2006-04-07 2011-04-12 Stmicroelectronics Sa Method for initializing a memory
US7765359B2 (en) * 2006-08-23 2010-07-27 Samsung Electronics Co., Ltd. Flash memory system and programming method performed therein
US8700839B2 (en) * 2006-12-28 2014-04-15 Genesys Logic, Inc. Method for performing static wear leveling on flash memory
US8321597B2 (en) * 2007-02-22 2012-11-27 Super Talent Electronics, Inc. Flash-memory device with RAID-type controller
US10037153B2 (en) 2007-03-20 2018-07-31 Micron Technology, Inc. Memory device, electronic system, and methods associated with modifying data and a file of a memory device
US8655927B2 (en) 2007-03-20 2014-02-18 Micron Technology, Inc. Memory device, electronic system, and methods associated with modifying data and a file of a memory device
US20110161613A1 (en) * 2007-03-20 2011-06-30 Micron Technology, Inc. Memory device, electronic system, and methods associated with modifying data and a file of a memory device
US7917479B2 (en) 2007-03-20 2011-03-29 Micron Technology, Inc. Non-volatile memory devices, systems including same and associated methods
US7958301B2 (en) * 2007-04-10 2011-06-07 Marvell World Trade Ltd. Memory controller and method for memory pages with dynamically configurable bits per cell
US8166271B2 (en) 2007-04-10 2012-04-24 Marvell World Trade Ltd. Memory controller for setting page length and memory cell density for semiconductor memory
US20110238884A1 (en) * 2007-04-10 2011-09-29 Pantas Sutardja Memory Controller for Setting Page Length and Memory Cell Density for Semiconductor Memory
US20080256319A1 (en) * 2007-04-10 2008-10-16 Pantas Sutardja Memory controller
US8102658B2 (en) 2007-07-05 2012-01-24 Super Talent Electronics, Inc. Micro-SD to secure digital adaptor card and manufacturing method
US8539143B2 (en) 2008-01-31 2013-09-17 Samsung Electronics Co., Ltd. Memory systems and methods of initiallizing the same
US8429332B2 (en) * 2008-06-04 2013-04-23 A-Data Technology Co., Ltd. Multi-channel hybrid density memory storage device and control method thereof
US7908417B2 (en) * 2008-10-15 2011-03-15 Phison Electronics Corp. Motherboard system, storage device for booting up thereof and connector
US9983800B2 (en) 2009-06-04 2018-05-29 Memory Technologies Llc Apparatus and method to share host system RAM with mass storage memory RAM
US8874824B2 (en) 2009-06-04 2014-10-28 Memory Technologies, LLC Apparatus and method to share host system RAM with mass storage memory RAM
US8245024B2 (en) 2009-08-21 2012-08-14 Micron Technology, Inc. Booting in systems having devices coupled in a chained configuration
US8738974B2 (en) * 2009-08-28 2014-05-27 Panasonic Corporation Nonvolatile memory device and memory controller
US8539189B2 (en) * 2010-04-30 2013-09-17 Micron Technology, Inc. Indexed register access for memory device
US8832392B2 (en) 2010-04-30 2014-09-09 Micron Technology, Inc. Indexed register access for memory device
US9465728B2 (en) * 2010-11-03 2016-10-11 Nvidia Corporation Memory controller adaptable to multiple memory devices
US8819480B2 (en) * 2010-11-11 2014-08-26 Samsung Electronics Co., Ltd. Display apparatus and method for updating micom code thereof
US8799604B2 (en) * 2010-12-29 2014-08-05 Sony Corporation Data storage apparatus, information processing apparatus, information processing method, and program
US10042586B2 (en) 2012-04-20 2018-08-07 Memory Technologies Llc Managing operational state data in memory module
US9858366B2 (en) 2012-11-05 2018-01-02 Phison Electronics Corp. Simulator and simulating method for flash memory background
US9880908B2 (en) * 2013-04-23 2018-01-30 Hewlett-Packard Development Company, L.P. Recovering from compromised system boot code
US9424134B2 (en) * 2014-03-28 2016-08-23 Intel Corporation Boot management in a non-volatile memory system
US9502118B2 (en) * 2014-09-26 2016-11-22 Intel Corporation NAND memory addressing
US20160093379A1 (en) * 2014-09-26 2016-03-31 Umberto Siciliani Nand memory addressing
US7340566B2 (en) 2008-03-04 System and method for initializing a memory device from block oriented NAND flash
JP4406339B2 (en) 2010-01-27 Controller, memory card and a method of controlling the same
US5459850A (en) 1995-10-17 Flash solid state drive that emulates a disk drive and stores variable length and fixed lenth data blocks
JP3372964B2 (en) 2003-02-04 Computer system
US6442067B1 (en) 2002-08-27 Recovery ROM for array controllers
US6480932B1 (en) 2002-11-12 Computer system having a host computer coupled to a disk drive with a drive-selected-application partition for storing data for execution by the host computer in response to drive-determined conditions
EP1248976B1 (en) 2003-09-24 Computer system initialization via boot code stored in sequential access memory
US6317827B1 (en) 2001-11-13 Method and apparatus for fault tolerant flash upgrading
US7454557B2 (en) 2008-11-18 System and method for booting from a non-volatile application and file storage device
CN1307555C (en) 2007-03-28 Data storage device
EP1920317B1 (en) 2016-04-20 Mass data storage system
DK1797645T3 (en) 2018-11-19 Systems and methods for providing non-volatile memory management in wireless telephones
US7853772B2 (en) 2010-12-14 Method for managing partitions in a storage device
JP4852548B2 (en) 2012-01-11 Erasable / rewritable method and apparatus for use once or several times a programmable memory in the host device designed for memory
US5406529A (en) 1995-04-11 Flash non-volatile memory
US6834384B2 (en) 2004-12-21 Methods and apparatus for upgrading firmware in an embedded system
US5898869A (en) 1999-04-27 Method and system for PCMCIA card boot from dual-ported memory
EP2110746A1 (en) 2009-10-21 A nand flash memory controller exporting a nand interface
JP4129381B2 (en) 2008-08-06 Nonvolatile semiconductor memory device
US6308265B1 (en) 2001-10-23 Protection of boot block code while allowing write accesses to the boot block
US20030079077A1 (en) 2003-04-24 Method and system for a compact flash memory controller
US20030156473A1 (en) 2003-08-21 Memory controller
US6725178B2 (en) 2004-04-20 Use of hidden partitions in a storage device for storing BIOS extension files
CN101484882B (en) 2013-10-02 Method for flash-memory management
US7039754B2 (en) 2006-05-02 Detachably mounted removable data storage device
Owner name: SUPER TALENT ELECTRONICS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LEE, CHARLES C.;YU, IKANG;REEL/FRAME:015871/0386


text:
Q: I am trying to scrape a website, but it returns 404 not found error Here I am trying to retrieve all the internship offers(stage in French) from LinkedIn.
If I do the same on a simple website and change my search parameters, it works. I cannot see what I am doing wrong.
const PORT = 8000
const express = require('express')
const axios = require('axios')
const cheerio = require('cheerio')

const app = express()
const articles = []

app.get('/', (req, res) => {
    res.json('Scraping')

})

app.get('/news', (req, res) => {

    axios.get('https://www.linkedin.com/jobs/')
         .then((response) => {
            const html = response.data
            const $ = cheerio.load(html)

            $('a:contains("stage")', html).each(function () {

                const title = $(this).text()
                const url = $(this).attr('href')
                articles.push({
                    title,
                    url
                })

            })

            res.json(articles)
         }).catch((err) => console.log(err))
})

app.listen(PORT, () => console.log('server running on PORT ${8000}'))

A: I was able to scrape for data engineers with this : remove " , html" and replaced it like that :  $('a:contains("Data")').each. Made a console log on the http://localhost:8000/news. And it printed some URLs.
    const PORT = 8000
    const express = require('express')
    const axios = require('axios')
    const cheerio = require('cheerio')

    const app = express()
    const articles = []

    app.get('/', (req, res) => {
res.json('Scraping')
})

app.get('/news', (req, res) => {
axios.get('https://www.linkedin.com/jobs/')
     .then((response) => {
        const html = response.data
        const $ = cheerio.load(html)

        // Find <a> elements with a title attribute that contains the word "stage"
        $('a:contains("Data")').each(function () {
            const title = $(this).text()
            const url = $(this).attr('href')
            articles.push({
                title,
                url
            })
        })
        console.log(articles)
        res.json(articles)
     }).catch((err) => console.log(err))
  })

  app.listen(PORT, () => console.log('server running on PORT ${8000}'))

redpajama_set_name: RedPajamaStackExchange


text:
Eternal (Hardcover)
By Lisa Scottoline
Forthcoming - Available for Pre-Order, Check Format + Release Date
#1 bestselling author Lisa Scottoline offers a sweeping and shattering epic of historical fiction fueled by shocking true events, the tale of a love triangle that unfolds in the heart of Rome...in the creeping shadow of fascism.
What war destroys, only love can heal.
Elisabetta, Marco, and Sandro grow up as the best of friends despite their differences. Elisabetta is a feisty beauty who dreams of becoming a novelist; Marco the brash and athletic son in a family of professional cyclists; and Sandro a Jewish mathematics prodigy, kind-hearted and thoughtful, the son of a lawyer and a doctor. Their friendship blossoms to love, with both Sandro and Marco hoping to win Elisabetta's heart. But in the autumn of 1937, all of that begins to change as Mussolini asserts his power, aligning Italy's Fascists with Hitler's Nazis and altering the very laws that govern Rome. In time, everything that the three hold dear--their families, their homes, and their connection to one another--is tested in ways they never could have imagined.
As anti-Semitism takes legal root and World War II erupts, the threesome realizes that Mussolini was only the beginning. The Nazis invade Rome, and with their occupation come new atrocities against the city's Jews, culminating in a final, horrific betrayal. Against this backdrop, the intertwined fates of Elisabetta, Marco, Sandro, and their families will be decided, in a heartbreaking story of both the best and the worst that the world has to offer.
Unfolding over decades, Eternal is a tale of loyalty and loss, family and food, love and war--all set in one of the world's most beautiful cities at its darkest moment. This moving novel will be forever etched in the hearts and minds of readers.
Lisa Scottoline is the New York Times-bestselling author of thirty-two novels. She has 30 million copies of her books in print in the United States and has been published in thirty-five countries. Scottoline also writes a weekly column with her daughter for The Philadelphia Inquirer. Lisa has served as President of Mystery Writers of America and has taught a course she developed, "Justice in Fiction" at the University of Pennsylvania Law School, her alma mater. She lives in the Philadelphia area.
"In this book of her heart, Lisa Scottoline delivers what her readers expect and so much more, fast-paced intrigue, but also an authentic, tender coming of age tale of three best friends navigating the complexities of fascism, war, political and family strife and romantic competition."--Lisa Wingate, author of Before We Were Yours and The Book Of Lost Friends
"Powerful and absorbing…at the heart of the novel is an enduring message, that what's perhaps most heroic in any life is to love fiercely and completely, in spite of loss and betrayal, and even beyond death."--Paula McLain, author of The Paris Wife and When the Stars Go Dark
"With characters who change and grow and enough twists and turns to keep you guessing, Eternal is blockbuster with cinematic intensity."--Christina Baker Kline, author of Orphan Train and The Exiles
"A beautiful, heartbreaking, wrenching love story set in the Second World War. It's alive with characters I cared about deeply - including the remarkable city of Rome, itself - and their courage in the face of Fascism."--Chris Bohjalian, author of Midwives and The Flight Attendant
"This nuanced take on WWII Italy offers a variety of perspectives, but at its heart, this is a love story, with heroes lost being warmly remembered and love conquering all….Best-selling crime writer Scottoline successfully changes course in a coming-of-age WWII love story that will entrance fans and newcomers alike."--Booklist
"Scottoline's admirable foray into historical fiction…expertly brings historical events to life. Fans of WWII fiction will be drawn to this immersive, emotional novel."--Publishers Weekly
"Eternal is remarkable historical fiction that brings to life Rome in the years leading up to and during WWII on the shoulders of unforgettable characters caught up on all sides of terrible events spinning beyond their control. Scottoline's research is impeccable, her storytelling is propulsive, and the emotional times she describes are deep, moving, and yes, eternal." --Mark Sullivan, bestselling author of Beneath a Scarlet Sky
"The master storyteller Lisa Scottoline is at the height of her powers with Eternal. This magnificent epic is the story of three childhood friends who come of age during World War II Italy. You are with them in the worst of times as they navigate their lost dreams. You will root for their survival as they find redemption in a post-war world they must build with hope. Love. Faith. Friendship. Courage. It's all here and it is essential reading."--Adriana Trigiani, bestselling author of Lucia, Lucia and The Shoemaker's Wife
"In Eternal, Lisa Scottoline expands her formidable talents to World War II Italy and the heartwarming tale of three families whose intersecting worlds are torn apart. Scottoline captures the tragic beauty of wartime Rome through the eyes of unforgettable characters with whom readers will hope and mourn and cheer. A passionate story of friendship, loyalty, and unbridled heroism."--Pam Jenoff, bestselling author of The Lost Girls of Paris
"Eternal is a gripping story of suffering and survival. It unspools at a heart-stopping pace, yet each page resonates with emotions: fear, hope, sorrow, yearning, love, empathy, sympathy, and, ultimately, joy. The book lives up to its title. It will echo in the minds of readers for a long time."--Sandra Brown
"What Elena Ferrante did with her Neapolitan Quartet, Scottoline does for war-time Rome: brings it to life as the city is ripped apart by men in power and barely held together by the courage and decency of those who stand against them. Eternal is a must read."--Lorenzo Carcaterra
"At its heart, Eternal is a beautiful, heartbreaking, yet ultimately uplifting love story. Meticulously researched, this riveting World War II-era novel explores what happens when beautiful Elisabetta must choose between lifelong best friends Sandro and Marco. As they get caught up in the madness that overtakes Italy when it becomes a satellite of Hitler and the Third Reich, each must make a gut-wrenching choice that determines the course of the rest of their lives. Action-packed and haunting, Eternal will stay with you for a long time after you finish reading it. I loved this book!"--Karen Robards, author of The Black Swan of Paris
"Lisa Scottoline is a magnificent storyteller. Eternal is a triangular story of first love, told against the backdrop of WWII in Rome, that is both terrifying and magical; three young people at one of the worst times in history are filled with love, hate, fear, rage, and at the end, survival and hope. Eternal is brilliantly written. Scottoline hits new heights in this spellbinding tale of decades-old family secrets and rips apart the fragility of first loves. I was pulled in from the first page by the lives of Scottoline's characters as they tried to make their way through events beyond their control in this richly detailed story that makes you feel like you're right alongside them." --Andrew Mayne, author of The Naturalist and The Girl Beneath the Sea
Publication Date: March 23rd, 2021
Kobo eBook (March 23rd, 2021): $12.99
Paperback, Large Print (March 23rd, 2021): $30.00
CD-Audio (March 23rd, 2021): $40.00

redpajama_set_name: RedPajamaCommonCrawl