JP6814327B1 - Memory devices, systems, and methods for updating firmware with a single memory device - Google Patents

Abstract

The memory device can include a memory cell array and a remap data structure. The remap data structure can include a mapping history part and a state part, the mapping history part is configured to store a set of mappings between the logical and physical addresses of the region, and the state part is a set of mappings. It is configured to identify one of them as a valid set for the device. The control logic can be coupled to the memory cell array and the remap data structure and can be configured to allow access to the storage location and the remap data structure. Also disclosed are firmware update systems and methods that include memory devices and include firmware wireless communication (FOTA).

Description

This application is an international application of US Patent Non-Provisional Application No. 16/005262, filed June 11, 2018, and this US Patent Non-Provisional Application is US Patent Provisional Application No. 62/597709, December 12, 2017. Priority is claimed by application and the entire contents of these patent applications are incorporated herein by reference.

Technical Field The present invention generally relates to a system that updates data in a non-volatile memory from time to time, and more specifically, a system that uses a firmware-over-the-air (FOTA) method. It is about a system that updates a firmware image for system applications such as.

Background Firmware wireless communication (FOTA) (firmware update by wireless communication) and other firmware update methods can be major requirements for computer systems. The FOTA update generally needs to be transparent, i.e., it instantly switches between the old FW (firmware) image and the new FW image. Traditionally, systems that require firmware updates use two or more separate flash memory devices, which map to different ranges of processor address space (eg, by using base registers). (Associated). Each base address in a different address range controls a single chip select (chip select) that selects the desired flash memory device. Therefore, the instantaneous switching occurs by swapping the base address stored in the base address register.

FIG. 16A shows a conventional system 1691 including FOTA updates. The system 1691 can include a microcontroller (MCU) 1693 and a plurality of flash memory devices 1695-0-1695-2. The storage location (storage location) in the flash memory device (1695-1695-2) can be mapped to the system address space 1697. Flash memory device 0 1695-0 can accommodate base address 0x000 and can store the old firmware image 1607-0 (ie, the expired version and thus the replaced version). Flash memory device 1 1695-1 can support base address 0x100 and can store the current firmware image (ie, the version currently accessed by the system). The flash memory device 2 1695-2 can support a base address of 0x200 and can store a new firmware image 1697-2 (ie, a version intended to update the current image).

The MCU1693 can update the firmware image using the addressing mechanism inside the MCU1693. The MCU 1693 can have a base address register 1699, which stores the base address corresponding to the firmware image. The base address register is used to generate the respective chip selection signals CS0 to CS2 for the flash memory devices 1695-0695-2. The base address register "ba_new_image" can store the base physical address (0x200 before update) of the new firmware image. The base address register "ba_cur_image" can store the base physical address (0x100 before update) of the current firmware image. The base address register "ba_old_image" can store the base physical address (0x000 before update) of the old firmware image.

System 1691 can update from the current image (eg, 1697-1) to a new image (eg, 1697-1) by switching the values in the base address register 1699. Specifically, the value in the base address register ba_cur_image can be switched from "cfg_cur" to "cfg_new". Following this work, when the system 1691 goes to read the firmware, the addressing mechanism inside the MCA1693 generates the chip selection signal CS2 (instead of the CS1 that occurred before the update work).

FIG. 16B is a block diagram of a conventional system 1691, showing a method of using chip selection. The MCU1693 dedicates one output terminal (for example, an I / O (input / output) terminal) as a chip selection (CS1, CS2) for each flash memory device 1695-0 / 1. As will be understood from the above, such chip selection (CS1, CS2) can be activated according to the value in the base address register. One flash memory (eg, 1695-1) can store the firmware image currently in use, while the other flash memory (eg, 1695-1) is not currently in use (ie, 1695-1). , The old firmware image, or the new firmware image that should be in use by switching the base address register value) can be stored.

Disadvantages of conventional FOTA methods can be cost and performance limitations. When using a typical controller (eg, MCU) that dedicates one I / O terminal as a chip selection terminal for each flash memory device (ie, for each firmware image), this controller can be a dynamic RAM (ie, each firmware image). It may not have an unused I / O terminal for other required devices such as DRAM: dynamic random access memory or static RAM (SRAM). As a result, a controller with additional I / O terminals may have to be used, which can increase the cost of the system. Traditional systems allow multiple flash memory devices to be connected to the same bus, but the capacitive load on the bus can increase with each additional flash memory device. Therefore, the greater the number of flash memory devices on the bus, the slower the bus will operate. As just one example, for an octal SPI (serial peripheral interface) bus, adding two flash memory devices is compared to the same bus, which has only one flash memory device. The maximum bus speed can be reduced from 200 MHz to 133-166 MHz.

1A-1D are a series of block diagrams showing a system and firmware update operation according to one embodiment. 2A and 2B are block diagrams showing how the memory device can include receiving instructions and / or register writes in the update operation. It is a schematic block diagram of the memory device according to one Embodiment. It is a figure which shows the remap data structure of the memory device by one Embodiment. It is a flow chart which shows the firmware update work by one Embodiment. 6A and 6B are diagrams showing an array configuration of memory cells that can be included in the embodiment. It is a block diagram which shows the data structure which can be included in embodiment and the corresponding memory cell array. It is a figure which shows the memory cell array which can be divided into a variable number pool which can be included in an embodiment. 9A-9D are diagrams showing inputs to the memory device for updating the firmware according to the embodiment. It is a figure which shows the system which can include the firmware radio communication (FOTA) update by one Embodiment. It is a block diagram of the system by one Embodiment. 12A and 12B are perspective views of the memory device according to the embodiment. 13A-13C are diagrams of suitable devices according to embodiments. It is a flow chart of the method by one Embodiment. It is a flow chart of the method by another embodiment. 16A and 16B are diagrams showing a conventional system for updating FOTA.

Detailed Description Various embodiments showing memory devices, systems, and methods for updating system firmware are described below. The update can be performed on a single memory device without copying the firmware image between the storage locations of the memory device.

According to the embodiment, the new firmware image can be programmed in the same memory device that stores the current firmware image. Once the new firmware image is stored, the memory device can switch to the new firmware image by a switching operation using an internal remapping (remapping, relocation) data structure. Switching to such a new firmware image can be done instantly.

In the various embodiments below, similar items are referenced by the same reference letter, but with a leading figure corresponding to the figure number.

1A-1D are a series of flow charts showing the system 100 and the corresponding firmware update work. The system 100 can include a memory device 102, a controller 104, and a controller memory 106. The memory device 102 can include a non-volatile memory array 108, a remap (remapping, relocation) data structure 110, and an input / output (I / O) and control circuit 112. The non-volatile memory array 108 can include a plurality of non-volatile memory cells, which can store data in a non-volatile manner. That is, the stored data can be retained when there is no power. The storage position can be accessed by a physical address (PA). The non-volatile memory 108 can include any suitable type of non-volatile memory cell, but in some embodiments it can include a "flash" type memory cell. The non-volatile memory array 108 can have sufficient storage capacity for at least two or more firmware images.

The remap data structure 110 can store the logical address-physical address (LA (logical address) → PA) mapping of the firmware image and the data for recording the state of each LA → PA mapping. For example, entry 110-0 stores a valid mapping (LA_FW = PAx) indicated by the display of VAL (valid). Entry 110-1 stores the invalid mapping indicated by the INV (invalid) display. The remap data structure 110 resides on the memory device 102 and stores the data in a non-volatile manner. As shown in other embodiments below, the remap data structure 110 is a LA → PA lookup stored in a volatile memory (not shown) for high speed translation between logical and physical addresses. It can contain a table (look-up table) or other structure. The remap data structure 110 can utilize non-volatile memory cells located outside the non-volatile memory array 108 and / or non-volatile memory cells located inside the non-volatile memory array 108.

In some embodiments, the memory device 102 can be a single integrated circuit device. In such a configuration, the non-volatile memory array 108, the remap data structure 110, and the UI / O / control circuit 112 can be part of the same integrated circuit package. In certain embodiments, the non-volatile memory array 108, the remap data structure 110, and the I / O and control circuit 112 can be part of the same integrated circuit board (ie, within a single "chip". It is formed).

The I / O and control circuit 112 can allow access to the non-volatile memory cells 108 and the remap data structure 110. In order to access the firmware stored in the non-volatile memory array 108, the I / O and control circuit 112 uses the remap data structure 110 to identify which LA → PA mapping is valid. Then, these mappings can be used to direct the logical address of a valid firmware image to the physical address.

In some embodiments, the memory device 102 remaps the data structure 110 in response to a predetermined operation (eg, power-on / reset, received instructions, register settings). The LA → PA mapping structure can be created in volatile memory (not shown) by accessing.

The controller 104 can include logic circuits for performing various functions of the system 100. In some embodiments, the controller 104 may include one or more processors and associated circuits capable of executing the stored instructions 116. However, alternative embodiments may include any other suitable circuitry, including custom logic and / or programmable logic. The controller 104 can access the controller memory 108 different from the memory device 102. The controller memory 104 can be formed of any suitable memory circuit and, in certain embodiments, can be volatile memory such as dynamic random access memory (DRAM) or static RAM (SRAM).

The components of the system 100 have been described. The update work in the system 100 will be described below.

With reference to FIG. 1A, the system 100 can first store the current firmware image 114 at a location starting at the physical address PAx of the non-volatile memory array 108. During system operation, the current firmware image 114 is read from the memory device 102 by the I / O and control circuit 112, which logically accesses the remap data structure 110. Translates an address (which can start with LA_FW) to a physical address (which can start with PAx).

Further referring to FIG. 1A, the system 100 can receive the new firmware image (shown in operation 103). The controller 104 can store the new firmware image 118 in the controller memory 106. The new firmware image 118 can be received from network 120. In some embodiments, the network 120 can be a wireless network and the update operation can be a FOTA operation.

With reference to FIG. 1B, the controller 104 can program the new firmware image 118 into the non-volatile memory array 108. It is clear that the new firmware image 118 is programmed in a physical location that the current firmware image 114 does not occupy. In the illustrated embodiment, the new firmware image 118 can occupy a range of physical addresses starting with PAy, which range does not overlap with the range of physical addresses storing the current firmware 114. The new firmware image 118 can be programmed by any technique suitable for the type and architecture of the non-volatile memory array 108. In some embodiments, the controller 104 can generate a physical address for the new firmware image 118. However, in other embodiments, such physical addresses can be generated by the I / O and control circuit 112 in response to one or more instructions from the controller 104.

With reference to FIG. 1C, the controller 104 can also program a logical address-physical address (correspondence) that maps the new firmware image 118 to the remap data structure 110. Such an operation is shown in FIG. 1C by programming "LA_FW = PAy" in entry 110-1. In this way, the logical address intended for the system 100 to access the firmware can be assigned to the physical address of the new image 118. However, as shown in FIG. 1C, such mapping does not work because entry 110-1 remains in an invalid state.

With reference to FIG. 1D, the controller 104 can “enable” the new firmware image by effectively programming the new mapping entry. Such an operation is shown in FIG. 1D by changing entry 110-1 to valid (VAL) and invalidating entry 110-0. As shown in the non-volatile memory array 108, once the new mapping is enabled, the firmware image in PAx becomes an invalid (eg expired) firmware image 115 and the firmware image in PAy becomes It becomes the current firmware image and is accessed by the system.

Once the new firmware image is enabled (eg, alive), it can be accessed immediately or in response to certain conditions. As just a few of the many possible examples, the new mapping can take effect after any or all of the following: the next power-up or reset (POR) of the device or system. ) Operation, the memory device 102 receives a given instruction, or a given value is written to the configuration register of the memory device 102.

Operations such as those shown in FIGS. 1A-1D can make firmware updates transparent and immediate, eliminating the need to copy data between locations within the same memory device. Note that in some embodiments, the memory device 102 can hold two positions for firmware and "swap" each of the new firmware images between these two positions. However, in other embodiments, the memory device 102 can include three or more storage locations for firmware and circulates between these various locations when a new firmware image is received (various locations). Can be used in order).

The controller 104 can track the physical address for the firmware location, but in some embodiments the I / O and control logic 112 is responsible for these tasks for the firmware data values received from the controller 104. A physical address can be generated.

The embodiments shown herein can include various actions performed by the memory device, which are programming firmware data to a storage location in a non-volatile memory array, a remap data structure. Includes programming values within (eg, LA-PA mapping data, state values, etc.) and making a new version of the firmware "enabled" (ie, made available to the system). Such operations can be achieved in any suitable way, but FIGS. 2A and 2B show two ways according to the embodiment.

2A and 2B are block diagrams of memory devices 202 and 202'. In certain embodiments, the memory devices 202/202'can be a particular realization of what is shown in 102 in FIGS. 1A-1D.

FIG. 2A shows writing data to the configuration register in the memory device 202. The memory device 202 may include an I / O circuit 212-0, a control logic circuit 212-1, a remap data structure 210, and a configuration register 222. The data value DATA can be written to the configuration register 222 to initiate or enable operation in the firmware update operation. As just a few examples, according to this register setting, any or all of the following can occur: PA → LA mapping data (210-x) that can "enable" the new firmware image: The memory device can be put into a mode that allows the controller to program the new firmware to a storage location (ie, access by physical addressing). Writing to the configuration register 222 can include giving the data and register address (data + address) to the memory device. In addition, such actions can also include instructions (eg, write to registers, etc.).

FIG. 2B shows a memory device 202'that receives a specific instruction for firmware update work. The memory device 202'can include the same items as in FIG. 2A. However, unlike FIG. 2A, the operation during the firmware update operation can be executed by a command dedicated to the memory device 202'. Therefore, the control logic circuit 212-1 can include an instruction decoder 224. In response to one or more instructions, the control logic 212-1'can perform any of the operations described for register writing in FIG. 2A (ie, "enable" the new firmware, etc.). it can. In some embodiments, one or more data values (+ data) can be attached to the instruction (instruction).

FIG. 3 is a block diagram of the memory device 302 according to another embodiment. In a particular embodiment, FIG. 3 can be one implementation of what is shown in FIGS. 1A-1D, 102, or in FIGS. 2A / B.

The memory device 302 can include an I / O circuit 312-0, a control logic circuit 312-1, a remap data structure 310, a memory cell array 308, X and Y decoders 334 and 336, and a data latch 338. The I / O circuit 312-0 can provide any suitable interface for the memory device 302, and in a very specific embodiment illustrated, a chip selection input terminal CS, a clock input terminal CLK, a serial I / O. It can include (SI / O0) terminals and optionally one or more additional serial I / O (SI / On) terminals. According to a well-understood technique, the memory device 302 can be accessed by an active CS signal and CLKs an instruction, address value, or data value on the SI / O0 (and SI / On) terminal. It can be received in synchronization with the clock received at the terminal. However, these particular interfaces should not be considered limited. Alternative embodiments may include I / O circuits with various interfaces, including those having dedicated address and data lines, asynchronous timing, parallel buses, and the like.

The remap data structure 310 stores data in a non-volatile manner to track and access the latest firmware images. In the illustrated embodiment, the remap data structure 310 can include pointer data 328, remap history data 330, and map memory 332. The remap history data 330 can store LA → PA mapping data each time a new firmware image is programmed into the memory cell array 308. Therefore, the remap history data 330 can store a history of all mappings for a particular firmware (here it will eventually overwrite the oldest entry). The pointer data 328 can indicate the entry of the latest remap history data, and thus can indicate the entry of the latest firmware image. The data in the map memory 332 can be accessed faster than the remap history data 330 and can be configured to provide faster LA → PA conversions. In some embodiments, the map memory 332 can have a volatile memory structure, in which the remap history data instructed by the pointer data 328 is inserted. In some embodiments, the pointer data 328 and the remap history data 330 are stored in the non-volatile memory circuit. Such a non-volatile memory circuit can be part of the memory cell array 308 or can be separate from the memory cell array 308. The map memory 332 can include a volatile memory circuit such as a SRAM and / or a DRAM.

The control logic circuit 312-1 can execute the operation of the memory device 302 according to the signal received by the I / O circuit 312-0. In the illustrated embodiment, the control logic circuit 312-1 may include a POR circuit 326, an instruction decoder 324, and a configuration register 322. The POR circuit 326 can detect and / or initiate a power-on or reset operation. The instruction decoder 324 can decode the instruction received by the I / O circuit 312-0. The configuration register 322 can store configuration data that can indicate how the memory device 302 operates. In some embodiments, the new firmware image can be brought into operation in response to any of the following: POR circuit 326 has detected a power-on or reset event, instruction decoder 324. Decryption of one or more instructions by, or writing predetermined data to configuration register 322. Bringing the new firmware image into operation can include the control logic 312-1 accessing the pointer data 328 to find the LA → PA mapping for the latest firmware from the remap history data 330. Next, the control logic circuit 312-1 can create a LA → PA lookup structure from the remap history data 330 in the map memory 332. Next, the control logic circuit 312-1 accesses the map memory 332 and provides a read request made to the logical address of the firmware.

The memory cell array 308 can include non-volatile memory cells, which are accessed by physical addresses decoded by the X and Y decoders (334/336). The non-volatile memory cell can be of any suitable technique and, in certain embodiments, can be a single transistor "flash" type memory. The memory cell array 308 can have any suitable organization and, in certain embodiments, can be organized sector by sector.

The data latch 338 can store the read data received from the memory cell array 308 for output to the SI / O0 (and SI / On if present) terminals by the control logic circuit 312. The data latch 338 can also store write data received on the SI / O0 (and SI / On if present) terminals.

FIG. 4 is a diagram showing a remap data structure 410 according to a particular embodiment. The remap data structure 410 can be one particular implementation of what is shown for other embodiments herein. The remap data structure 410 can include pointer data (FR_VEC) 428, remap history data (SMFLASH) 430, and map memory (SMRAM) 432. The pointer data 428 can include a bit value, which is an index of each entry in the remap history data 430. The final bit value of the pointer data 428 has a value of "0" and can be the latest entry. Therefore, in FIG. 4, the pointer data 428 is an index of the entry “n-1” that stores the LA → PA mapping for the latest version of the firmware. Therefore, it should be understood that the data stored in the map memory 432 is derived from the data stored in the entry n-1 of the remap history data 430.

Upon receiving the new firmware image, the LA → PA mapping can be programmed into entry "n" to "enable" these new firmware images and set the pointer bit value for index n to 1-0. Can be changed.

The various systems, devices, and corresponding methods have been described above. Another method will be described below with reference to FIG. FIG. 5 is a flow chart of a method of updating firmware by a controller and a single memory device. Method 540 can be performed by any of the systems described herein, and their equivalents. In method 540, the memory device can be a flash memory device, but other embodiments can include non-volatile storage devices based on any other suitable technique.

The method 540 can include a memory device in which an initialization event occurs, and in the illustrated embodiment can be a POR-type event 540-0. In response to these events, the memory device can load the LA → PA mapping from the remap history (eg SMFLASH) into the map memory (eg SMRAM). Other initialization events that can cause the same behavior (putting a value in SMRAM) are just a few examples of a particular instruction or command (instruction word) to a memory device, or one or more of a memory device. It can include configuration register settings.

The controller (eg MCU) can boot the current firmware image. Such an operation can include the controller setting the LA to the value of the last known firmware image. In addition, the controller can also have a record of the physical address (in memory device) of the latest image. In the illustrated embodiment, it is assumed that the current logical address is equal to the current physical address. In FIG. 5, it is understood that the current firmware image is stored in sector "C", which includes physical addresses c1, c2, and the like.

The controller can receive the new firmware image 540-4. Such operations may include any or equivalent of those described herein, including receiving a new firmware image over a wireless connection and storing it in controller memory (RAM).

The controller can program the new firmware in the memory device 540-6. Such operations can include the controller assigning and recording logical and physical addresses for the data. In the illustrated embodiment, it is assumed that the assigned logical address is equal to the assigned physical address. In FIG. 5, it is understood that the new firmware image is stored in the sector "N", and the sector "N" includes the physical addresses n1, n2, and the like. It is understood that the sector "N" is different from the sector "C" and does not overlap with the sector "C". Action 540-6 shows how LA → PA mapping can be shown to the application / user in some embodiments.

The controller then updates the remap history data (SMFLASH) on the memory device to store the location 540-8 of the new firmware image. Such actions can include the controller exchanging the logical address of the current firmware image with the logical address of the new firmware image. In FIG. 5, this can include swapping multiple logical addresses.

Method 540 can further include enabling the firmware update to be "enabled" by the controller setting a valid bit in memory device 540-10. In FIG. 5, this can include setting bits in the data structure as in FIG. 4 (ie, bit values in the pointer FR_VEC).

When the new firmware image is "enabled" and the memory device undergoes another initialization event 540-0 (eg, POR, special instructions / commands, writing configuration registers), the controller creates a new image. Start, that is, LA (cur_img) = N, where N = (n1, N2, ...). In this way, the firmware update takes effect immediately.

6A and 6B are diagrams showing the configuration for the memory cell array 608 that can be included in the embodiment. FIG. 6A shows a memory cell array 608 that is physically divided into different pools 642, 644-0, 644-1. Each pool (642, 644-0, 644-1) can be addressed by pointers (WL_PTR0-2), and these pointers can indicate the base address of the pool. One pool 642 can be designated as firmware pool 642 and has a size capable of accommodating at least two firmware images. As shown, the firmware pool 642 can program the new firmware image 618 (to physical addresses n0 to ni) while storing the previous firmware image 614 (to physical addresses c0 to ci). In some embodiments, the position can be swapped while the firmware is constantly updated. For example, once the new firmware image 618 is "enabled", the firmware image 618 becomes the current firmware image and the next new firmware image is programmed to physical addresses c0-ci.

FIG. 6 shows a swap operation. The logical address for the new firmware image is stored as a temporary value (tmp = LA (new_img)). The logical address for the new firmware image is set to the logical address for the current firmware image (LA (new_img) = LA (cur_img)). These actions specify the current firmware image (which is now expired) as the destination for the next new firmware image. Next, set the newly received firmware image as the current firmware image (LA (cur_img) = tmp).

Of course, in other embodiments, the firmware pool 642 can accommodate three or more firmware images, so updates are not swapped between just two address ranges, but rather in multiple address ranges. Do it all in order.

With reference to FIG. 6A, in some embodiments, the pool (642, 644-0, 644-1) can be a wear leveling pool. The memory device containing the memory cell array 608 can change the logical address-physical address mapping so that wear is leveled between the pools. In some embodiments, the firmware pool 642 can be treated like any other pool (eg, 644-0 / 1) during wear leveling operation. That is, once the number of accesses to the firmware pool 642 exceeds a certain threshold value, a new pool (for example, 644-0 / 1) can be designated as the firmware pool. In such an embodiment, when a plurality of firmware images are stored in the same pool, a pool with wear leveling operation is removed from the operation and replaced with a different pool to circulate the pool (used in order), mapping data is used. Can be avoided from losing.

With reference to FIG. 7, the memory device 702 according to another embodiment is shown in the form of a block diagram. The memory device 702 can be one particular realization of what is shown herein. The memory device 702 can include a memory cell array 708 that is divided into a plurality of pools 742 / 744- to 744-k. For each pool (742 / 744-0-744-k), there can be a corresponding remap structure 710-0-710-k. The remap structure (710-0 to 710-k) can also take the form of any of those described herein, or an equivalent thereof, so that FIG. 7 has a structure similar to that of FIG. It is shown in.

In some embodiments, the pool (742 / 744-0-744-k) can be a wear leveling pool, thus leaving it unused based on wear leveling criteria and using the pool in sequence. be able to. In the memory device 702 of FIG. 7, any pool (742 / 744-0-744-k) can function as a firmware pool because there is a remap data structure corresponding to that pool. Is.

In some embodiments, the memory cell array can have a physical area of programmable size. FIG. 8 shows an example of such a memory cell array 808. The memory cell array 808 can include a plurality of storage areas that can be divided into different areas shown as pools 842/844. The size and physical location of these pools can be programmed according to pointer values (WL_PTR0 to WL_PTR2), which can indicate the base physical address. In some embodiments, such pools can be wear leveling pools. Therefore, access to these pools should be monitored or otherwise tracked to remove pools that have been used more often than other pools from circulation (sequential use) and remap addresses to less worn pools. Can be (remapped).

FIG. 8 includes an example 848 of a method in which the memory cell array 808 can be divided using pointer values (WL_PTR0 to WL_PTR2). Example 848 includes only one pool, two pools, and three pools. Of course, any number of pools can be created, provided that a sufficient number of pointer values are available. In such a configuration, the size of the pool can be adjusted according to the size of the firmware (ie, large enough to store at least two images).

According to embodiments, the memory device may store a mapping data structure that can be accessed and modified to allow a quick switch from the current firmware image to the newly received firmware image. it can. The memory device can be accessed in any suitable way and according to any suitable protocol, but in some embodiments the memory device is accessed by a chip selection signal (CS) and one or more I / O lines. be able to. 9A-9D are timing diagrams showing input signals to the memory device for updating the firmware according to the embodiment. In response to these input signals, the memory device can do one of the following: "enable" the new firmware image, update the remapping history data (eg, new LA → PA mapping): (Add), prepare the memory device to program the new firmware image.

Each of FIGS. 9A-9D shows the waveforms of the chip selection signal (CSB) and the I / O signal (I / O). The I / O can be one I / O line of the memory device, or a plurality of such I / O lines. In the illustrated example, the data on the I / O line can be received in synchronization with the clock CLK. The data rate of the data received on the I / O line can be in any suitable format: single data rate (1 bit cycle), double data rate (2 bits per cycle), quad data rate (2). Includes octal data rate (2 bits per cycle on 4 I / O lines) or octal data rate (2 bits per cycle on 4 I / O lines).

FIG. 9A shows a register write instruction. At time t0, the chip selection signal can become active. At time t1, the memory device can receive the instruction "WriteRegX". Configuration data (DATA (Reg)) at time t2 can follow. In response to such an instruction, the memory device can write DATA (Reg) to one or more registers indicated by the instruction WriteRegX. Writing data to such registers can control, provide, or initiate data for the firmware update operations or their equivalents described herein.

FIG. 9B shows a register write instruction that can specify an address. At time t0, the chip selection signal can be activated. At time t1, the memory device can receive the instruction "WriteAddReg". The address data (ADD) at time t2 and the configuration data at the next time t3 can follow. In response to these instructions, the memory device can write DATA to the register indicated by the address data ADD. Writing data to such registers can control, provide, or initiate data for the firmware update operations described herein.

FIG. 9C shows a mapping instruction according to one embodiment. At time t0, the chip selection signal can be activated. At time t1, the memory device can receive the instruction "NewMap". The data (DATA (Map)) at time t2 can follow this. In response to such an instruction, mapping data for the new image (eg, LA → PA mapping) can be stored in the remap history data structure or its equivalent as described herein. The value DATA (Map) can contain this mapping data.

FIG. 9D shows an instruction to "enable" the new firmware image according to one embodiment. At time t0, the chip selection signal can be activated. At time t11, the memory device can receive the instruction "NewMapLive". Optionally, data (DATA (Ptr)) can follow. In response to these instructions, the latest set of mapping data can be shown as the firmware image to be provided is being transferred. In some embodiments, no data is required because the memory device control logic can update the value of the new mapping set. However, in other embodiments, DATA (Ptr) can be used to program remap data structures (eg, pointer values). These instructions can be swapped between firmware images in an atomic (indivisible) and immediate manner.

Embodiments can include systems, devices, and methods that include firmware updates for devices or modules, but embodiments are systems with multiple devices / modules, each of which may require a firmware update of its own. Can also be included. FIG. 10 is a block diagram of such a system 1000.

The system 1000 includes a telematics control unit (TCU) (for example, a controller) 1004, a controller bus 1050, a system development life cycle unit 1052, a module bus 1054 to 1054-2, and Modules 1055-1055-1 can be included. Each of the modules (1055 to 1055-1) operates with the firmware stored in the memory device (1002 to 1002-2). The TCU 1004 can include a processor, which can issue instructions to memory devices (1002-0-1002-2). The TCU 1004 may also include a wireless transceiver (or receiver) 1058, which receives firmware updates over the wireless network. In certain embodiments, the system 1000 can be an automotive control system, where the TCU 1004 comprises one or more processors and controller memory (GPS) global positioning system (GPS). Further can be included.

FIG. 10 shows separate module buses 1054- to 1054-2, but in other embodiments two or more modules can be connected to the same bus. Furthermore, in other embodiments, the controller bus 1050 can be the same as the module bus (1054- to 1054-2).

The various components of the system 1000 have been described. The FOTA operation of the system 1000 will be described below.

First, each of the memory devices 1002 to 1002-2 can store the current firmware image 1014/1015 (which should be updated).

The TCU 1004 can receive the new firmware on the wireless transceiver 1058, and the new firmware is transmitted over the wireless connection 1057 of the network 1020. The network 1020 can be any suitable network and, in some embodiments, the Internet and / or cellular network. In the illustrated example, new firmware for all modules 1055-1055-2 can be received. However, it is clear that other update work can update a smaller number of modules.

Then, the TCU 1004 can transmit the new firmware image to the respective memory devices 1055-1055-2. Such an operation can include the TCU 1004 transmitting a new firmware image on the controller bus 1050 and the module bus 1054-0. In one embodiment, such an operation can include transmitting data on a controller area network (CAN) type bus.

Modules 1055-1055-2 can now program the new firmware module at their respective locations in the corresponding memory devices 1002-0-1002-2. Such operations may include any of those described herein, or their equivalents. In one particular embodiment, the new firmware image 1018/14 can be programmed into the "secondary" memory page of the memory device (the primary memory page stores the current firmware 1014/15). In some embodiments, programming of the new firmware image can be implemented on the local processor (not shown) of modules 1055-1055-2. However, in other embodiments, such programming can be performed by the TCU 1004.

Allows the new firmware image 1018/1014 to be "enabled" (other firmware images 1014/1015 can be designated as inactive). Such an operation can be performed in response to the input received from the TCU 1004. Such inputs are the instructions or register writes described herein, or their equivalents, as well as out-of-band signaling or operation by the local processor of modules 1055-1055-2, or any other suitable. Signaling methods can be included, but are not limited thereto.

FIG. 11 is a block diagram of the system 1100 according to another embodiment. The system 1100 can include a controller (MCU) 1104 and a memory device 1002. The memory device 1002 can allow switching between at least two different firmware images (1114, 1118). As shown, the controller 1104 can supply two chip selective outputs (CS1, CS2) as in the conventional system shown in FIG. 16B. However, since memory device 1002 can manage switching between firmware images with a single memory device 1002 and a single chip selection (CS1), controller 1104 is an additional application available to other applications. It can have a chip selection output CS2.

Embodiments can include systems with memory devices that work with one or more controller devices, but embodiments can switch internally between different firmware images and their equivalents as described herein. It can also include stand-alone memory devices that can be enabled. Such memory devices can include multiple integrated circuits formed within the same package, but in some embodiments the memory device can be a compact single integrated circuit (ie, a chip). Is advantageous. 12A and 12B show two packaged single-chip memory devices 1202A and 1202B. However, it is clear that the memory device according to the embodiment can include any other suitable package type, including direct bonding of the memory device chip to the circuit board.

With reference to FIGS. 13A-13C, various devices according to embodiments are shown in a series of figures. FIG. 13A shows a vehicle 1360A capable of having a number of subsystems (two of which are indicated by 1300A-0 and 1300A-1) operating with updatable firmware. Such subsystems (1300A-0, 1300A-1) can include an electronic control unit (ECU) and / or an advanced driver assistance system (ADAS). However, in other embodiments, such subsystems can include dashboard display / control subsystems and / or infotainment subsystems as just two of the many possible examples. Each subsystem (1300A-0, 1300A-1) may include a controller and a memory device, and may use the firmware operations described herein, including FOTA-type updates, or equivalents thereof. it can.

FIG. 13B shows a handheld computer device 1360B. The handheld computer device 1360B may include system 1300B, which is a memory device 1302 and controller 1304 (proportional to actual size) for performing firmware updates for device 1360B or its equivalent as described herein. (Not shown).

FIG. 13C shows the controller device 1360C. Controller device 1306C can be a device deployed to control industrial or residential operation. As just a few of the many possible examples, the controller device 1360C can control machinery on the production line, can be an electronic lock for a building, and can control home appliances. You can control the lighting system, or you can control the irrigation system. The device 1360C may include a system 1300C, which includes a memory device 1302 and a controller 1304 (not shown) for performing firmware updates for the device 1360C or its equivalent as described herein.

Here, referring to FIG. 14, the method according to one embodiment is shown in a flow chart. Method 1462 can include the step of receiving new firmware data in a memory device that stores firmware for the system (block 1462-0). Such an operation can include the memory device receiving a program or write instruction for firmware data through an interface on the memory device. In certain embodiments, such an operation can include the memory device receiving an instruction from the controller to program the firmware data to a predetermined physical address.

The received firmware data can be programmed in a non-volatile memory cell at a location different from the location where the current firmware 1462-2 is stored. In certain embodiments, such an operation can include the memory device programming the firmware data into one or more sectors of the flash memory array, which sectors are designated for the new firmware. It is different from the address range that stores the current firmware. Note that such an operation does not include copying firmware data from one location in the memory cell array of the memory device to another location in the memory cell array in the same memory device.

Method 1462 can also include programming a new LA → PA mapping for the new firmware into a non-volatile storage area on the memory device 1462-4. In some embodiments, such behavior can include programming such data within a remap history data structure, which retains such mappings for previous versions of firmware.

Method 1462 can also include a step of programming a non-volatile state value on the memory device to indicate a new LA → PA for the latest version of the firmware (block 1462-6). In some embodiments, such an action may include programming a value in a pointer data structure, which indicates one entry in the remap history data structure.

FIG. 15 shows method 1564 according to another embodiment in the form of a flow chart. Method 1564 can be the FOTA method and can include a step of identifying when data for a new firmware image is received over the wireless connection 1564-0. Such actions can include the controller detecting when the system's wireless receiver receives a firmware update.

If the data for the new firmware image is not received ("no" from block 1564-0), method 1564 can access the required firmware by means of a lookup structure (block 1564-18). In some embodiments, such an operation can include the memory device receiving a read request for a logical address of the firmware, which is translated into a physical address by data from the lookup structure. In certain embodiments, the lookup structure can reside in volatile memory. At this point, it is clear that the system lookup structure corresponds to the current firmware image (which will be replaced by any newly received firmware image).

When new firmware image data is received (“yes” from block 1564), the new firmware image data can be stored in system memory (block 1564-2). In some embodiments, such an operation may include storing the data of the new firmware image in a volatile system memory such as a DRAM or SRAM accessed by a controller or the like.

The programming operation of the memory devices in the system can be started in block 1564-4. Such actions can include determining a particular memory device to store the new firmware image. In some embodiments, such an operation can include the controller issuing instructions or the like to the memory device. The new firmware image can be programmed in the non-volatile sector of the memory device at a location different from where the current firmware image is stored (block 1564-6). Such an operation can include the controller programming the firmware image stored in the system memory to the non-volatile storage location of the memory device.

The LA → PA mapping for the new firmware image can be programmed into the non-volatile storage area of the memory device (block 1564-8). Such behavior may include any or equivalent of those described herein, including programming such data within the remap history data structure, the remap history data structure being the previous firmware. -Image mappings can be kept in the same memory device.

A pointer pointing to a new LA → PA mapping can be programmed (block 1564-10). Such behavior is one of those described herein, or an equivalent thereof, including setting one bit in a multi-bit value corresponding to one entry in the remap history data structure. Can be included. Such pointers can be stored in the non-volatile storage area of the memory device.

Method 1564 can determine whether a reset-type event has occurred (block 1564-12). A reset event can be an event that causes the memory device to reset the logical address mapping from the current firmware image to the newly programmed (“valid”) firmware image. Reset-type events can take any suitable form, including POR events, memory devices receiving specific instructions or register writes, or signals at special input pins, to name a few. , Not limited to them.

If it is determined that no reset-type event has occurred ("No" from block 1564-12), method 1564 can continue to access the firmware through the lookup structure (block 1564-18). This can continue to replace the firmware image with the newly received firmware image.

If it determines that a reset-type event has occurred (“yes” from block 1564-12), the memory device can access the latest LA → PA mapping set with a pointer (block 1564-14). ) (This set corresponds to the newly received firmware image). The memory device can then create a new LA → PA lookup structure corresponding to the new firmware image (block 1564-16). As a result, access to the firmware in block 1564-18 now becomes the new firmware image.

The embodiments described herein include an application programming interface (API) that can be called to perform a firmware image update or equivalent thereof as described herein. be able to. The new firmware image can be loaded into any address range within a memory device, which stores the current firmware image within another address range (addr_cur_img). The API can perform a firmware update using such address information. For example, the API can have the form "fota_switch (addr_cur_img, addr_new_img)".

Such a configuration "relocates" the firmware in the address space without having to copy the firmware data from one location in the memory device to another (eg, write / program the firmware data once). It can be made possible to "(transfer)" (ie, switch from access to the old firmware to access to the new firmware). This relocation operation is "atomic" (ie, a single-bus transaction) and is essentially immediate. For example, as described herein, an instruction or register write to a memory device can introduce remapping to new firmware.

It is advantageous that embodiments of the present invention can reduce or eliminate the use of multiple flash memories for storing different firmware images, because different firmware images can be stored in one memory device. Then, once the new image is memorized, it is possible to immediately switch to the new image. This can reduce the cost of the system because it requires fewer memory devices. In addition, a system that typically contains multiple flash memories with different firmware images on the same bus can achieve the same result with only one device (or fewer devices) on the bus. .. This can reduce the capacity of the bus and increase the performance of the system (ie, increase the bus speed).

Embodiments of the present invention allow the system to make an instant switch between firmware images with one memory device connected to one chip selective output. This reduces costs because controller devices with fewer chip selective outputs can be used. In addition to, or instead, there may be greater degrees of freedom in system design, because one or more chop selection outputs are now being accessed by another user (ie, a user who is not accessing the firmware image). ) Will be free.

These and other advantages are apparent to those skilled in the art.

Throughout this specification, references to "one embodiment" or "embodiments" include specific features, structures, or properties described in connection with that embodiment in at least one embodiment of the invention. It should be clear that it means that. Therefore, it is noted that more than one reference to an "embodiment" or "one embodiment" or "alternative embodiment" in various parts of the specification does not necessarily refer to the same embodiment. Emphasize, that should be clear. Moreover, in one or more embodiments of the invention, specific features, structures, or properties can be combined appropriately.

Similarly, in the description of preferred embodiments of the invention above, various features of the invention are sometimes described in order to simplify disclosure of one or more of the various aspects of the invention. It is clear that they are grouped together in a single embodiment, drawing, or description thereof. However, such disclosure methods should not be construed as reflecting the intent that the claims require more features than expressly stated in each claim. Rather, aspects of the invention are smaller in scope than all features of the single embodiment disclosed above. Therefore, the scope of claims following the detailed description is thereby expressly included in this detailed description, and each claim is self-sustaining as a separate embodiment of the present invention.

Claims (21)

A memory cell array with multiple storage locations accessible by physical address,
Remap data structure and
A memory device including the memory cell array and a control logic circuit coupled to the remap data structure.
Each of the storage locations is located in a separate area
The remap data structure
A mapping history part with multiple non-volatile entries
A set of mappings between a logical address (LA) and a physical address (PA) for different versions of firmware stored in the area is stored, and a plurality of versions of firmware stored in the memory device are stored. A mapping history portion configured to form a history of LA-PA mappings for
Includes a non-volatile state portion configured to identify one of the set of mappings as a valid set in the memory device.
The control logic is configured to allow access to the storage location and the remap data structure .
The memory cell array and the remap data structure are memory devices formed on the same integrated circuit board . Further equipped with a volatile memory circuit configured to store the logical address-physical address mapping of the valid set.
The memory device according to claim 1, wherein the control logic circuit is configured to access the volatile memory circuit in response to a received logical address. The memory device of claim 1, wherein the control logic further includes an instruction decoder, the instruction decoder being configured to allow access to the remap data structure in response to a received instruction. .. The control logic further includes at least one configuration register, the configuration register being accessible by register write operation to the memory device, and the at least one configuration register being the mapping history. The memory device according to claim 1, wherein the memory device is configured to store any selected from a group consisting of data for a portion and data for the state portion. The control logic further includes a power-on reset circuit, which delivers the valid set of logical addresses to the memory device in response to a power-on or reset event in the memory device. The memory device according to claim 1, which is configured to be set as the latest address for stored firmware. It further comprises an input / output (I / O) portion, which includes at least one chip selection input terminal, at least one clock input terminal, and at least one bidirectional serial data input / output terminal. The memory device according to claim 1. The memory cell array comprises a plurality of flash memory cells arranged in the form of a plurality of pools, and the separate areas are arranged in the first pool.
The memory device according to claim 1, wherein the control logic circuit is configured to change access to the remaining pools according to a wear leveling algorithm. The steps to receive the new firmware image in the memory device,
A step of programming the new firmware image into a non-volatile storage location of the memory device, wherein the current firmware image in the memory device having the same storage location for the new firmware image is stored. Steps different from the memory position
The step of programming the set of logical address (LA) -physical address (PA) mappings for the new firmware image into one of a plurality of different entries in the non-volatile mapping circuit of the memory device. Thus, one entry in the mapping circuit also contains a set of LA-PA mappings for the current firmware image, and the entry is stored in the memory device for multiple versions of LA for firmware. -Steps to form a history of PA mapping,
A state value is programmed into the non-volatile state circuit of the memory device to show the set of LA-PA mappings for the new firmware image as a valid firmware image stored in the memory device. A step of showing the set of LA-PA mappings for the current firmware image as an invalid firmware image, wherein the state circuit includes a state value for each entry forming a different history.
How to include. 8. The method of claim 8, wherein the step of programming the new firmware image into the non-volatile storage location of the memory device comprises programming a sector of the flash memory device. The step of programming the state value comprises programming at least one bit in a multi-bit pointer data structure having one bit for each set of LA-PA mappings stored in the memory device. The method according to claim 8. The step of programming a set of LA-PA mappings for the new firmware consists of receiving predetermined instructions and data in the memory device and writing data to at least one predetermined register in the memory device. 8. The method of claim 8, comprising the action selected from the group. The step of programming the state value in the new firmware image is selected from a group consisting of receiving predetermined instructions and data in the memory device and writing data to at least one predetermined register in the memory device. The method according to claim 8, wherein the operation is included. In response to a predetermined condition, a step of generating an LA-PA mapping in one of the LA-PA mapping sets of the new firmware image in volatile memory.
With the step of accessing the volatile memory and reading data from the new firmware image
8. The method of claim 8. The predetermined condition was selected from a group consisting of a power-on / reset operation in the memory device, receiving a predetermined instruction in the memory device, and writing data to at least one predetermined register in the memory device. 13. The method of claim 13, comprising any of these. With non-volatile memory devices
Processor circuit and
A system with a wireless transceiver
The non-volatile memory device is
A memory cell array that has areas with different physical addresses and stores different firmware images for the system.
The logical address (LA) -physical address (PA) mapping for the received firmware image is stored in one of a plurality of entries in the non-volatile storage circuit, and the LA for the received firmware image is stored. -A mapping history part configured to keep a history of PA mappings,
Includes a firmware state portion configured to store data identifying the current firmware image accessed by the system in a non-volatile storage circuit.
The processor circuit executes a stored processor instruction and
Store the new firmware image in system memory
The new firmware image from the system memory is programmed into one of the areas in the non-volatile memory device without disturbing the current firmware image stored in the non-volatile memory device. And
The LA-PA mapping for the new firmware image is programmed into the mapping history portion of the non-volatile memory device.
The LA-PA mapping for the new firmware image is read by the system to access firmware data that is different from any of the previous versions of the firmware image stored in the non-volatile memory device. Program the firmware state portion as shown
Is configured as
The wireless transceiver is a system configured to receive the new firmware image over a wireless network. Programming the LA-PA mapping for the new firmware image causes the processor circuit to issue predetermined instructions and data to the non-volatile memory device, and the processor circuit issues the non-volatile memory device. 15. The system of claim 15, comprising any selected from a group consisting of writing data to at least one predetermined register of. Programming the firmware state portion causes the processor circuit to issue a predetermined instruction to the non-volatile memory device, and the processor circuit sends data to at least one predetermined register of the non-volatile memory device. 15. The system of claim 15, comprising any selected from a group consisting of writing. The processor circuit is configured to access the previous firmware image stored in the non-volatile memory device by a chip selection signal before receiving the new firmware image.
The processor circuit is configured to access the new firmware image by the same chip selection signal after receiving the new firmware image.
The system according to claim 15. The non-volatile memory device comprises at least one pool, each of which pools
With multiple registers
The mapping history part for the pool and
With the firmware state part for the pool
15. The system of claim 15. The memory device of claim 1, wherein the state portion comprises at least one bit in a multi-bit pointer data structure having one bit for each entry in the mapping history portion. 15. The system of claim 15, wherein the firmware state portion comprises at least one bit in a multi-bit pointer data structure having one bit for each entry in the mapping history portion.