Non-volatile memory devices, systems, and methods for fast, secure, and resilient system booting.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- INFINEON TECHNOLOGIES LLC
- Filing Date
- 2022-01-21
- Publication Date
- 2026-08-05
Smart Images
Figure 0007900923000001 
Figure 0007900923000002 
Figure 0007900923000003
Abstract
Description
Technical Field
[0001] Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 139,944, filed on January 21, 2021, and U.S. Provisional Patent Application No. 63 / 166,283, filed on March 26, 2021, the contents of which are hereby incorporated by reference in their entirety.
[0002] The present disclosure generally relates to non-volatile memory devices that store a system's boot code, and more particularly, non-volatile memory devices that can enable fast and resilient system boot.
Background Art
[0003] System NOR flash memory has conventionally been used for code storage in applications that require high reliability over a wide temperature range. Embedded systems within automobiles are an example of such applications. Current-generation automotive microcontroller units (MCUs) rely on embedded NOR flash. As automotive MCU manufacturers migrate to more advanced process nodes, integrating flash memory on the same silicon die as the MCU processor can be a technically and manufacturingly difficult challenge. When adding embedded flash memory to existing MCU logic (such as CMOS), more manufacturing masks are required, increasing manufacturing cost and complexity. Alternatives such as MRAM have been proposed as replacements for embedded NOR flash memory, but such alternative memory types have not yet been reliably adopted.
[0004] To address these challenges, two different approaches have emerged: one is system-in-package (SiP) integration, and the other is the adoption of standalone NOR flash memory. In both cases, the NOR flash memory device can be isolated from the corresponding MCU (e.g., a different die or integrated circuit package). Both the SiP and standalone approaches can provide highly cost-effective solutions. However, one drawback of isolated devices is security concerns, including the ability to modify critical code stored within the NOR device, particularly boot code executed by the MCU during startup.
[0005] To address these security concerns, traditional approaches have focused on securing the boot process. These traditional approaches relied on encryption to verify the code before the MCU could execute it. However, code verification can increase boot time. Several traditional methods have been proposed to speed up a secure boot process, such as performing code verification in parallel with the boot operation or deferring verification to a later point in the boot process. However, these traditional methods have not proven practical.
[0006] To better understand the features and benefits of the disclosed embodiments, the boot options and configurability of conventional systems using an MCU and a separate NOR flash device are described.
[0007] Figure 16 shows the conventional boot options for system 1601. Once operational, a flashless MCU (i.e., an MCU without built-in flash memory) performs an immutable hardware configuration procedure (A) before allowing the execution of boot code. Modern MCUs are generally designed to support multiple boot options (B0-BN) based on available interfaces for various types of non-volatile memory. MCU manufacturers provide boot options that can be configured either once or dynamically. The boot options are shown as 1603 in Figure 16.
[0008] Dynamic configurability is achieved by relying on external pin 1605, while the use of a single-boot option can be ensured by blowing an internal, non-resettable fuse 1607. Once configured, system 1601 is booted as predefined. Immutable code (A) performs minimal system initialization and hands control over to the first variable code. The first variable code (B0-BN) initializes complex peripherals and hands control over to the operating system.
[0009] Security-enabled systems provide boot options, where hardcoded branches are conditional. Therefore, the MCU either executes verified code or fails to boot. This technique can be extended to create a set of layers or blocks of code that are executed only if verified. However, the impact of adding code verification routines on system performance is not linear with respect to time, but inversely proportional to the time these routines are executed. In other words, the earlier code verification occurs in the boot process, the greater the negative impact on boot performance (such as boot time). One reason for this impact may be the calculation of the availability of computing resources within the MCU during startup (such as after a power-on reset). Some multi-core processors boot from a single core, while the remaining cores await software enablement. Therefore, if code to enable secondary cores flows from off-chip memory and requires verification, not all computing resources may be available until verification is complete. Even if verification does not require additional cores, such as with MCUs that include hardware encryption blocks, these MCUs can initially boot with fail-safe performance settings such as a reduced system clock frequency, which hinders the goal of fast boot times.
[0010] In addition to the performance impact, the integration and maintenance efforts associated with incorporating verification into the boot code present further practical considerations. Developing the boot process in embedded systems involves multiple stakeholders, including MCU manufacturers, memory (such as NOR flash) manufacturers, and developers who generate bootloader code, operating system code, and application code. These can all be separate entities. While such separation can result in highly performing individual components, specialization can necessitate significant coordination and integration efforts to optimize the system's boot process.
[0011] The functionality of an MCU is primarily defined by the code stored in non-volatile memory. MCUs typically include on-chip read-only memory (ROM). The size of the on-chip ROM is determined by the amount of logic that the MCU manufacturer can securely finalize before tapeping it out. ROM size tends to be minimal compared to the initialization and boot logic that is pushed to an external flash device. Unlike ROM code, which is inherently trusted due to its immutability, location, and extensive design review, flash code requires periodic verification. Many traditional standalone NOR flash devices lack an on-chip security infrastructure that provides a level of assurance close to that of on-chip ROM, thus establishing the need for periodic verification.
[0012] For systems with an MCU and external memory (such as NOR flash), a combination of device authentication and code verification can provide a certain level of code assurance. Device authentication involves cryptographic exchange between the MCU and the external flash device, which allows for verification of the flash device's identity. Device authentication helps prevent the physical replacement of the flash die and ensures that the state of the flash device is not compromised. Currently, some form of security infrastructure is being implemented even for standalone flash devices, and the standards organization JEDEC is working on developing a NOR flash authentication standard. As a result, MCU manufacturers are increasingly likely to include flash authentication support in the ROM of their MCUs.
[0013] Code verification can take various forms, including, but is not limited to, an MCU that compares a code received from external memory with an expected value such as a hash or other value generated for the code. Some verification processes may also include cryptographic exchange. While some systems may include device authentication, code verification is a critical step in securing the boot process.
[0014] Figure 17 is a block diagram illustrating the boot operation of a conventional embedded system 1701. System 1701 may include an MCU 1703, NAND flash memory 1705, NOR flash memory 1707, and DRAM 1709, all of which are formed on different chips (e.g., dies). The MCU 1703 may include a processor (e.g., CPU) 1711, ROM 1713, SRAM 1715, and one-time programmable (OTP) memory 1717. The address space 1719 accessible by the CPU 1711 may include various memory types, including on-chip (i.e., on the MCU 1703) and off-chip memory.
[0015] Figure 17 shows the components and control transfer points in time. At time t=0, the CPU can execute ROM code (boot loader 1) 1721-0. Once the system is further booted from external NOR flash memory 1707, ROM code 1721-0 can initialize the Serial Peripheral Interface (SPI) controller, allowing initialization routine 1721-1 (boot loader 2) to be fetched from NOR flash memory 1707 to SRAM 1715 (between times t=1 and t=2). These routines constitute several peripherals, one of which is the DRAM controller. Once DRAM becomes available, at time t=3, the operating system kernel 1721-2 is copied from NOR flash memory 1707 to DRAM 1709, and control is passed to the system kernel. Subsequently, application code 1721-3 stored in NAND flash memory 1705 can be executed.
[0016] A critical control transfer occurs when ROM code 1721-0 branches to SRAM code 1721-1. If code verification is not performed before this point, there is an opportunity for unverified code to take over the execution flow. As mentioned earlier, performing code verification before this point can be costly in terms of boot performance. Therefore, conventional systems may include a delay in code verification. In a code verification delay, the system is allowed to boot (with some safety measures in place), and then the code is verified. If verification fails, the system can enter a recovery state.
[0017] Thus, traditional embedded systems that rely on external NOR flash memory for booting can take two approaches to the boot operation. One is fast booting, which is achieved by deferring code verification and therefore lacks recovery functionality; the other is slow (secure) booting, which has recovery functionality. While slow booting can provide security, it may be unsuitable for some applications, such as those that require the boot operation to complete within a limited time.
[0018] Figure 18A is a timing diagram showing a slow and secure boot operation. The application processor (such as a flashless MCU) is booted from internal ROM (bootloader 1). Bootloader 1 pre-configures the MCU and fetches subsequent code (bootloader 2) from external non-volatile memory (such as NOR flash).
[0019] At time t=0, the MCU can authenticate an external NOR device by manipulating code from bootloader 1. Once the NOR device is authenticated, at time t=1, the MCU can transfer or inspect the code stored by the NOR device (e.g., bootloader 2), which is designated as "Content Verification". Since bootloader #2 is supplied off-chip (e.g., the MCU chip), it needs to be verified before control is passed. Existing solutions rely on encryption to verify subsequent code. Code verification is a slow operation and may not meet some system deadlines. This is shown at time t=2, which may be the MCU availability deadline, at which point the MCU needs to be available to communicate with other devices in the system. For example, in a car, the MCU might need to communicate via the CAN bus within 50 milliseconds, but may not necessarily be ready to perform application-specific actions.
[0020] At time point t=3, various actions may occur based on the code validation results. If the code from the NOR device (e.g., bootloader 2) passes validation, the code can execute normally. However, if the code fails, the system can perform recovery actions, which may attempt to fix the faulty code. At time point t=4, an application deadline may occur. At this point, the system must be ready to execute the application code.
[0021] Figure 18B is a timing diagram showing a faster boot operation that sacrifices security for speed. The "availability deadline" issue can be addressed by having the ROM code (bootloader 1) pass control to the NOR code (bootloader 2) without completing the verification of the NOR code.
[0022] At time t=0, the NOR device can be authenticated. At time t=1, before the availability deadline, the MCU can execute the NOR code. Validation of the NOR code can also be started before the availability deadline, but the code validation will not be completed. At time t=3, the system can continue normal operation or perform recovery actions depending on the code validation results.
[0023] An approach like B in Figure 18 can meet the availability deadline, but because control is passed to potentially unverified code, the system loses its ability to recover in all cases.
[0024] It is known that embedded systems use a watchdog timer by their application processor. However, in systems booted from external flash memory, the boot code may be maliciously modified to allow such a watchdog timer to be deferred, even while executing unverified code. To circumvent this problem, traditional systems typically offload detection to a remote authority. If the embedded system cannot prove its integrity to the remote authority, the watchdog expires. Making watchdog deferral a verified procedure allows for communication between the embedded system and the remote authority over an insecure channel.
[0025] Figures 19A-C illustrate a conventional system including an authenticated watchdog timer. Figure 19A shows a conventional system 1901 with an MCU 1903 having a watchdog timer 1923. The MCU 1903 can first be booted with boot code from an internal ROM (boot loader 1), and then continue booting with boot code (boot loader 2) on an external NOR device 1907. The MCU 1903 can communicate with a remote authority 1925 using an authenticated procedure.
[0026] B in FIG. 19 is a timing diagram showing a "good" boot operation. At time t = 0, the MCU becomes bootable using the code from the internal ROM (bootloader 1). At time t = 1, the MCU becomes bootable using the code from the external NOR device (bootloader 2). Almost simultaneously, the MCU can start the watchdog timer (WD). The watchdog timer (WD) can be postponed by a postponement message from the remote authority (RA). B in FIG. 19 shows the MCU reporting to the RA and the RA postponing the WD at time t = 2. At time t = 3, the system can be successfully booted with the code of bootloader 2.
[0027] C in FIG. 19 shows a timing diagram of a boot operation that results in a watchdog failure. C in FIG. 19 shows the same operation as B in FIG. 19. However, since the code of bootloader 2 is invalid, the RA does not postpone the WD. As a result, the WD expires at time t = 3, and a failure state (e.g., power-on / reset) occurs.
[0028] With the addition of an authenticated watchdog, the MCU can maintain control and transition the system to a known state, and execute the ROM code (e.g., bootloader 1) after a configurable timeout. This is useful, but since the recovery code cannot be incorporated into the ROM, the response is limited. As a result, as shown in C of FIG. 19, the watchdog expiration cycle will repeat itself. That is, adding a watchdog timer enables a fast and secure boot, but results in a non-resilient system that cannot easily recover from a failure state.
[0029] In a system that stores the boot code in an external non-volatile memory, it is desirable to reach a fast, secure, and resilient boot operation or provide such a resilient boot operation by some means.
Brief Description of the Drawings
[0030] [Figure 1]A timing diagram illustrating the boot operation of a system according to one embodiment. [Figure 2] This is a block diagram of a system according to one embodiment. [Figure 3A] This is a block diagram of a system equipped with an external non-volatile memory (NVM) device according to an embodiment. [Figure 3B] This is a block diagram of a system equipped with an external non-volatile memory (NVM) device according to an embodiment. [Figure 3C] This is a block diagram of a system equipped with an external non-volatile memory (NVM) device according to an embodiment. [Figure 4] This is a block diagram of the memory address remapping operation of an NVM device according to one embodiment. [Figure 5] This is a block diagram of an NVM device according to another embodiment. [Figure 6] Block diagram showing an embedded system and corresponding memory address mapping according to one embodiment. [Figure 7A] This figure shows the boot-up and related operations of the system according to the embodiment. [Figure 7B] This figure shows the boot-up and related operations of the system according to the embodiment. [Figure 7C] This figure shows the boot-up and related operations of the system according to the embodiment. [Figure 7D] This figure shows the boot-up and related operations of the system according to the embodiment. [Figure 8A] This figure shows the boot and recovery operations of the system according to the embodiment. [Figure 8B] This figure shows the boot and recovery operations of the system according to the embodiment. [Figure 8C] This figure shows the boot and recovery operations of the system according to the embodiment. [Figure 9] A is a block diagram of a system-in-package device according to an embodiment, and B is a block diagram of an embedded system according to an embodiment. [Figure 10]This is a schematic diagram of an NVM array that may be included in the embodiment. [Figure 11] This is a diagram of a standalone NVM device according to one embodiment. [Figure 12] This is a diagram of an automobile system according to one embodiment. [Figure 13] This is a diagram of a vehicle according to one embodiment. [Figure 14] This is a flowchart of a method according to one embodiment. [Figure 15] This is a flowchart of the method according to another embodiment. [Figure 16] This is a block diagram of the system's boot options. [Figure 17] This is a block diagram of a conventional system and its corresponding memory address space. [Figure 18] Both A and B are timing diagrams that show the conventional boot operation. [Figure 19] Figures A through C show conventional systems equipped with a watchdog timer and corresponding boot operation. [Modes for carrying out the invention]
[0031] According to one embodiment, a system having a controller device (e.g., an MCU) that relies on an external non-volatile memory (NVM) device (e.g., NOR flash) to store boot code can be rapidly booted while maintaining a recovery function from failure conditions (i.e., resilience).
[0032] According to some embodiments, boot time can be reduced by shifting the integrity check of externally stored boot code (i.e., the period after basic boot functions are completed) to the application layer, thereby avoiding early boot integration. In some embodiments, the operation of the application layer can communicate with a standalone NVM device that stores the boot code in order to transition the system to a known state at the boot level.
[0033] In the various embodiments described below, similar items are referred to by the same reference letter, but the leading digit corresponds to the figure number.
[0034] Figure 1 is a timing diagram of a boot operation according to one embodiment. In Figure 1, the system can meet the availability deadline while maintaining recoverability. Assume that at time t=0, the system processor (e.g., MCU) executes initial boot code (e.g., boot loader 1) from internal memory such as ROM (e.g., on-chip memory, embedded memory, integrated memory). The system processor can authenticate an external (i.e., off-chip, standalone) NVM device 102-0. Such operation can take any suitable form, including cryptographic exchanges that include an identification value unique to the NVM device.
[0035] At time t=1, the system can execute code stored in the authenticated NVM device. However, unlike the conventional approach, the code executed depends on the non-volatile state of the NVM device. If the NVM device has not previously experienced a failure state, the code accessed from the NVM device becomes boot code, and the system performs the normal boot operation 102-1. However, if the NVM device is in a (previously established) failure state, the code accessed from the NVM device becomes recovery code, and the system performs the recovery operation 102-2. Note that the reading and execution of code by the system processor at time t=1 may involve the same type of access to the NVM device; that is, the system processor is unaware of the failure state. It is the non-volatile state of the NVM device that controls whether to perform normal operation or recovery operation.
[0036] Recovery operations are designed to address invalid boot code in NVM devices and can take an appropriate form based on the system configuration. Recovery operations include, but are not limited to, restoring known working boot code, reading boot code from a read-only address known to contain working boot code, or reverting to a previous version of boot code.
[0037] Referring further to Figure 1, time t=2 could be the system's availability deadline. As illustrated, if the boot operation proceeds through the normal execution path 102-1, the system will be operational by the availability deadline.
[0038] At time point t=3, the system can perform a code verification operation (e.g., content verification) 102-3. This operation allows the NVM device to verify the boot code store. In this way, code verification is deferred until all boot code has been executed. In some embodiments, such code verification may occur at the application layer of the boot process. In some embodiments, the system processor may have multiple cores. At the application layer point (e.g., from time point t=3 onward), the processor can have more cores enabled than during the initial boot process (e.g., before time point t=3). As a result, the deferred content verification operation 102-3 can complete faster than if it were incorporated into the boot process. Time point t=4 represents the application deadline. As illustrated, in a fast boot process, the system is positioned at the application layer point well before the application deadline.
[0039] In this way, a system that uses an external NVM device to store boot code can meet a fast availability deadline while maintaining recoverability.
[0040] Figure 2 is a block diagram of a system according to one embodiment. System 200 may include a microcontroller unit (MCU) 204, an NVM device 206, and a remote authority 208. While System 200 utilizes the MCU 204, alternative embodiments may include any suitable processor device or circuit, including but not limited to hardwired and / or programmable custom logic circuits. The MCU 204 may include a central processing unit (CPU) 210, ROM 212, SRAM 214, and one-time programmable memory (OTP) 216. The CPU 210 may include processor circuitry for executing instructions, including boot code stored in the ROM 212 and NVM 206. The ROM 212 may store initial boot code (e.g., boot loader 1) to be executed by the CPU 210 in response to predetermined conditions such as power on / reset (POR). The SRAM 214 functions as high-speed access storage for the CPU 210. In some embodiments, the SRAM is volatile memory and loses stored data when power is not supplied. In some embodiments, the CPU 210 can transfer boot code (e.g., boot loader 2) from the NVM 206 to the SRAM 214 for execution. The OTP 216 can provide additional non-volatile storage for data values.
[0041] In some embodiments, the ROM 212, SRAM 214, and OTP 216 may be part of the same MCU device 204. This may include the same integrated circuit package and / or circuitry formed on the same die.
[0042] The NVM device 206 can provide non-volatile storage for data used by the MCU 204, including boot code (e.g., boot loader 2). The NVM device 206 may include an address mapping circuit 228 and may have an NV boot state 218. According to such an NV state, the NVM device 206 can provide boot code or recovery code for the MCU 204 during boot operation. The NVM device 206 can be connected to the MCU 204 by a memory bus 220. The memory bus 220 can take any suitable form, including a serial bus or a parallel bus. In some embodiments, the memory bus 220 includes SPI, CAN, and I 2 It could be a serial bus compatible with standards, including but not limited to C.
[0043] The remote authority 208 can be a trusted source of control messages for system 200. The remote authority 208 can issue instructions to defer watchdog circuits in the MCU 208 and / or NVM device 206. The remote authority 208 may be a device present throughout the entire system, including the MCU 204 and NVM device 206, or it may be a device not in close proximity to the MCU 204 / NVM device 206, such as a server communicating over one or more networks, including a wireless network. The remote authority 208 can communicate with the MCU 204 via communication channel 222. Communication channel 222 can take any suitable form, including wired, wireless, or any combination thereof. In some embodiments, the remote authority 208 can communicate with the MCU 204 according to an authentication protocol. In some embodiments, the remote authority 208 can communicate with the NVM device 206. Communication between the remote authority 208 and the NVM device 206 can be performed via the memory bus 220 through the MCU 204. However, in other embodiments, the remote authority 208 may also have a direct communication channel (not shown) with the NVM device 206.
[0044] In some embodiments, non-volatile circuitry within an external NVM device can be used to exit a fault cycle and implement the results of code verification. In some embodiments, this may involve using non-volatile values to control which image is exposed at the location within the NVM device where the MCU fetches code (e.g., while operating under ROM code). If verification is successful, the NVM device can expose the normal boot code, allowing the system to boot as quickly as possible (e.g., as quickly as the design allows without additional steps). If verification fails, the NVM device can expose a recovery image at the same logical location, allowing the system to boot directly into recovery. Thus, no prior boot code (such as ROM code) is required to distinguish between a normal boot and a recovery boot.
[0045] In some embodiments, the execution of the boot process beyond the initial trusted code (e.g., ROM code) can be controlled by multiple watchdog circuits. One watchdog circuit may reside in the controller device (e.g., an MCU), while the other may be a non-volatile watchdog circuit residing in an external NVM device. The non-volatile watchdog circuit can operate in the same way as a conventional watchdog circuit, but may persist an expiration date (e.g., fault) when the power is off (e.g., after a power-on reset). The non-volatile fault indicator can control the image (i.e., boot code or recovery code) exposed to the controller during the boot operation. In a normal boot, it is assumed that both watchdogs will be deferred by the remote authority within a configurable timeout. If this condition is not met, explicit communication is not required for the system to boot recovery.
[0046] In this way, a watchdog circuit can be used to perform health checks at the boot level without compromising system performance. Authenticating the NVM device provides a partially immediate guarantee that the boot code is valid. A complete, but delayed, guarantee that the boot code is valid can be provided through deferred integrity checks (code verification). Despite the opportunity to execute unverified code, the two device systems (e.g., the controller and the NVM device) can retain control to transition the system to a known state. And, unlike other conventional solutions as shown in Figures 19A-C, the known state can extend beyond the initial boot code (e.g., ROM code) and may include recovery logic.
[0047] In some embodiments, verification can be performed at the application level of the boot process. This can enable a thorough system check that includes not only the integrity of the boot media but also runtime parameters. Finally, shifting boot code verification to the application level avoids premature booting and operating system integration, resulting in a practical system-level solution.
[0048] Figure 3A is a block diagram of system 300A according to another embodiment. System 300A may include an MCU 304A and a NOR (flash) device 306A. While the embodiments disclosed herein describe a system with a NOR device, alternative embodiments may include any other suitable non-volatile memory device. The MCU 304A may include items as shown in Figure 2. Furthermore, the MCU 304A may include a controller watchdog circuit 324A. The controller watchdog circuit 324A can run for a predetermined period. If this period expires without delay, the controller watchdog circuit 324A puts the MCU 304A into a predetermined state (e.g., POR). The controller watchdog circuit 324A can be delayed by instructions from an external source to the MCU 304A.
[0049] The NOR device 306A may include one or more non-volatile memory cell arrays located in different physical locations (or sections). Figure 3A shows a first location 326-0 that can store normal boot code (e.g., boot loader 2) and a second location 326-1 that can store recovery code 326-1.
[0050] The NOR device 306A may further include an NV watchdog circuit 328-0A and an address mapping circuit 328-1. The NV watchdog circuit 328-0A can provide an NV status indicator 332. The NV status indicator 332 may change depending on whether the NV watchdog circuit 328-0A indicates a fault condition or a normal condition. In some embodiments, the NV watchdog 328-0A may initially output an NV status indicator 332 of one value (i.e., no fault). When the watchdog period of the NV watchdog circuit 328-0A expires, the NV watchdog 328-0A switches the NV status indicator 332 to another value (fault condition) and does not reset this value unless a predetermined action (e.g., an authenticated message) occurs. It is understood that the NV status indicator 332 is non-volatile and therefore persists throughout the POR cycle.
[0051] The address mapping circuit 328-1 can selectively map memory access to the NOR device 306A to either a first position 326-0 or a second position 326-1, based on the NV status indicator 332. Therefore, in a fault-free state (where the NV watchdog 328-0A has not expired), the address mapping circuit 328-1 can return the normal boot code for 326-0. However, in a fault state (where the NV watchdog 328-0A has previously expired), the address mapping circuit 328-1 can return the recovery code for 326-1. In some embodiments, the operation of the address mapping circuit 328-1 is completely unknown to the MCU 304A. That is, in response to the same address from the MCU 304A, the NOR device 306A can return either a boot code or a recovery code depending on the fault state. Although the address mapping circuit 328-1 is represented by a multiplexer symbol, this should not be interpreted as a limitation. MUX is merely one functional representation of address mapping circuit 328-1. Embodiments may include any suitable address mapping circuit or system.
[0052] Figure 3B shows system 300B according to another embodiment. Figure 3B may include items similar to those in Figure 3A, but differs in that the MCU 304B and NOR device 306B can form part of the embedded system 334. Furthermore, system 300B may include a remote authority 308 that communicates with the embedded system 334 via a communication channel 322. The MCU 304B may include a certified controller watchdog circuit 324B, and the NOR device 306B may include a certified NV watchdog circuit 328-0B. In some embodiments, the certified NV watchdog circuit 328-0B and / or the certified controller watchdog circuit 324B can communicate with the remote authority 308 according to a certification process, and the watchdog period can be deferred by communication from the remote authority 308.
[0053] Figure 3B also differs from Figure 3A in that the address mapping circuit 328-1 can be an address decoding circuit, and the authenticated NV watchdog circuit provides a non-volatile bit value 328-2. Such a bit value may be included in the decoding operation for mapping access between a first position 326-0 and a second position 326-1 in response to the same input address value. In some embodiments, the NV bit value 328-2 may be one or more major bits (MSBs) of the address value applied to the decoder circuit.
[0054] During operation, system 300B can provide a resilient boot. Within MCU 304B, if the controller watchdog circuit 324B expires, MCU 304B can be restarted (e.g., via POR). The controller watchdog circuit 324B can function to transition MCU 304B to a known state, which may include executing boot code in ROM 312 if subsequent code (in NOR 306B) is found to be corrupted. In normal boot operation, the watchdog period of the controller watchdog circuit 324B can be periodically extended by signals or messages from the remote authority 308.
[0055] Within the NOR device 306B, when the NV watchdog circuit 328-0B expires, the state of NV bit 328-2 can be changed. NV bit 328-2 controls which image is exposed for fetching by the MCU304B while the ROM boot code is running. For the MCU304B to boot successfully, the NV watchdog circuit 328-0B must also be periodically deferred. Otherwise, the NV bit may change, potentially causing the NOR device 306B to expose different images at the same logical address.
[0056] As described herein, the NOR device 306B can present "normal boot" and "recovery boot" at the same logical address. This ensures that the MCU 304B, which executes ROM code (immutable), always fetches from the same logical address location on the NOR device 306B. In other words, the MCU 304B cannot know why a reset event occurred and therefore cannot know whether normal boot code or recovery boot code is needed.
[0057] The embodiment may include an MCU with a watchdog circuit for exiting fault conditions, but alternative embodiments may use a different mechanism instead of a watchdog circuit. Figure 3C shows one such embodiment.
[0058] Figure 3C shows system 300C according to another embodiment. Figure 3C may include items similar to those in Figure 3A. Figure 3C differs from Figure 3A in that the MCU 304C includes a reset circuit 324C that can reset the MCU 304C (e.g., a forced POR) in response to an external reset event. The external reset event can take any suitable form and may be periodic (but not necessarily periodic). This is just one example among many, but system 300C can be incorporated into a larger system (e.g., a car) that is periodically reset (e.g., a car engine being turned off and on).
[0059] Figure 4 is a block diagram of an NVM device 406 according to one embodiment. The NVM device 406 may be a NOR flash device including multiple storage areas, including a first area 426-0 and a second area 426-1, an authenticated watchdog 428-0, an address decoder 436, and an internal address path 440. The first area 426-0 is accessible via a physical address range starting with 0...x and can store a normal boot image. The second area 426-1 is accessible via a physical address range starting with 1...x and can store a recovery boot image. The authenticated watchdog circuit 424 may be an NV watchdog circuit or an equivalent as described herein. The address decoder 436 can decode address values received via the internal address path 440 to enable access to the non-volatile storage area including areas 426-0 / 1. The internal address path 440 can provide an address value to the address decoder 436, which may include the upper bit (in this case, the MSB bit 31) and the lower bits (in this case, bits 30:0). The value of the MSB bit 31 can be determined by the state of the authenticated watchdog circuit 428-0. In particular, bit 31 can be "0" in a fault-free state and "1" in a fault state. The lower bits 30:0 can correspond to the input address 438 received by the memory bus or the like.
[0060] In some embodiments, the NV bit 31 can be modified in two ways. When the NV watchdog period expires, the bit can be set to "1". Upon receiving authenticated input, the bit can be set to "1" (e.g., code verification failed) or reset to "0" (e.g., code verification successful). In some embodiments, such as those shown in Figure 3B, authenticated input may be received from the remote authority in packet form. Instructions from the remote authority 308 may be received by the NOR device 306B via the MCU 304B or via a direct path (not shown), as described herein.
[0061] Figure 5 is a block diagram of an NVM device 506 according to another embodiment. The NVM device 506 may include an NVM processor 544, an NVM array 542, an address mapping circuit 536, a serial interface (I / F) 546, an authentication circuit 548, and an NV watchdog circuit 528-0. The NVM processor 544 may include processor circuitry for performing the functions of the NVM device 506, which is shown as sectors 526-0 to 526-N. The NVM array 542 may include one or more arrays of NVM cells located in different physical locations. In some embodiments, one or more sectors may be dedicated to boot code, while one or more other sectors may be dedicated to recovery code. In some embodiments, the physical addresses of the boot code and recovery code may vary by one or more MSBs of the corresponding addresses, or their equivalents, as described herein.
[0062] The address mapping circuit 536 can selectively map received addresses (i.e., logical addresses) to various physical addresses of the NVM array 542 based on the NV status indicator 532. In some embodiments, the address mapping circuit 536 may include a decoder, while other embodiments may include any other suitable address mapping circuit 536, such as a block mapping circuit, which assigns a portion of the array (e.g., a sector) to various address ranges. The serial interface 546 can send and receive data via the serial memory bus 520. In some embodiments, the serial interface 546 can connect to a controller device such as an MCU of a larger system. The serial interface 546 can provide values to the address mapping circuit 536 and can provide values to the authentication circuit 548.
[0063] The authentication circuit 548 may include a circuit for performing authentication procedures to send and receive authenticated communications with another device. In some embodiments, the authentication circuit 548 may receive deferred communications, which may be forwarded to the NV watchdog circuit 528-0 to defer the watchdog period. Furthermore, the authentication circuit 548 may authenticate communications that may set or reset the NV status indicator 532. In some embodiments, the authentication circuit 548 may include an NVM processor 544 that executes an authentication code.
[0064] The NV watchdog 528-0 may operate as described in other embodiments or equivalents of this specification. When the watchdog period expires, the NV status indicator 532 can be set to one value. In response to a predetermined input (e.g., an authenticated message), the NV status indicator 532 can be set to another value. The NV watchdog 528-0 operates independently of the code stored by the NVM array. In some embodiments, the NV watchdog 528-0 may operate independently of the NVM processor 544.
[0065] Figure 6 is a block diagram of system 600 according to another embodiment. System 600 may be an embedded device intended for a larger system. The embedded device may include an MCU 604, a NOR device 606, a NAND device 650, and a DRAM 652. The MCU 604 and the NOR device 606 may take the form of any of those disclosed herein or their equivalents. The NAND device 650 may be a standalone device or a system including NAND storage. The DRAM 652 may be a standalone device or a system including DRAM storage. The DRAM 652 can provide volatile memory for system 600 that is larger in size and / or lower in power than the SRAM 614. The MCU 604 may include a CPU 610, a ROM 612, a SRAM 614, and an OTP 616, which may take the form of those described herein or their equivalents.
[0066] System 600 may have an address space 654 accessible by CPU 610. Address space 654 may contain addresses and memories corresponding to the external MCU 604 (i.e., on-chip memory) and the external MCU 604 (i.e., on-chip memory). The address space corresponding to ROM 612 can store the initial boot code (boot loader 1) 656-B1. The address space corresponding to NOR device 606 can store values depending on the state of the NV state indicator within the NOR device (which may be in a fault-free or faulty state). Thus, in response to the state, the NOR address space can provide a second boot code (boot loader 2) 656-B2 or recovery code 656-R. The address space of NOR device 606 can also store the operating system (OS) kernel 656-O for execution by CPU 610. NAND device 650 can store application code 656-A. In some embodiments, the application code may include a code verification routine for verifying the second boot code (boot loader 2) 656-B2 (and possibly other code).
[0067] Figures 7A to 7D are a series of diagrams illustrating the operation of system 700 according to an embodiment. System 700 may include an MCU 704, a NOR device 706, and a DRAM device 752. MCU 704 may include a CPU 710, a ROM 712, an SRAM 714, a controller watchdog circuit 724, and a DRAM controller 758. NOR device 706 may include an NVM array 742, an address mapping circuit 736, and an NV watchdog circuit 728-0. DRAM 752 can be accessed by MCU 704 via DRAM controller 758.
[0068] Figure 7A shows the start of the boot operation. Upon power-on or reset, the CPU 710 of the MCU 704 can execute initial boot code from ROM 712. Although the CPU 710 may have multiple cores, only one active core 760 can execute instructions.
[0069] Figures 7B-0 and 7B-1 illustrate how the boot operation may branch depending on the state of the NOR device 706. Figure 7B-0 shows the operation when the NOR device 706 is in a "fault-free" state. When executing boot code from ROM 712, the CPU 710 can generate an address value ADDx in the accessed NOR device 706. Due to the operation of the address mapping circuit 736, access by the MCU 704 in the address range ADDx can fetch boot code 756-B2 from section 726-0 of the NOR device 706 to the SRAM 714. The CPU 710 can then execute boot code from the SRAM 714. In another embodiment, the CPU 710 can execute boot code directly from the NOR device 706.
[0070] Figure 7B-1 illustrates the operation when the NOR device 706 is in a “failure” state. The CPU 710 can generate the same address value ADDx to access the NOR device 706. However, the operation of the address mapping circuit 736 is modified so that the MCU 704 can fetch recovery code 756-R from section 726-1 of the NOR device 706 to the SRAM 714. The CPU 710 can then execute the recovery code from the SRAM 714. In another embodiment, the CPU 710 can execute the recovery code directly from the NOR device 706.
[0071] Figure 7C shows a further boot operation according to one embodiment. When executing boot code from SRAM 714, CPU 710 can generate address value ADDy and copy OS code 756-O from NOR device 706 to DRAM 752. Next, CPU 710 can execute OS code from DRAM 752.
[0072] Figure 7D shows a deferred code verification operation according to one embodiment. When executing application code from DRAM 752, the CPU 710 can perform code verification operation 762 on the boot code store by the NOR device 706. In some embodiments, such boot code can still reside in SRAM 714, in which case code from SRAM 714 can be verified. However, in other embodiments, code verification operation 762 can also access code stored in the NOR device 706. In the illustrated embodiment, code verification operation 762 can utilize all cores 760 of the CPU 710.
[0073] Figures 8A to 8C illustrate resilient boot operation according to an embodiment. Actions are identified by the location of the code being executed. A corresponding system 800 having an MCU 804, a NOR device 806, a NAND device 850, and a DRAM device 852 is also shown.
[0074] Figure 8A shows the boot behavior that may occur when a physical change to the code image is detected.
[0075] The operation may start from the first POR864-0.
[0076] Next, the MCU can execute ROM code 866-0. This involves initializing the serial bus controller and fetching additional boot code from the NOR device to the onboard SRAM. Then, control can be passed to the boot code copied to the SRAM.
[0077] The MCU can execute SRAM code 868-0. This involves initializing the DRAM controller and fetching code from the NOR device to DRAM. Then, control can be passed to the code copied to DRAM.
[0078] The MCU may generate a health check failure 870. In some embodiments, this may include a code verification operation that detects an unauthorized modification to the code image. As a result, a state change may occur in the NOR device. This may be due to an authenticated message indicating the watchdog's expiration and / or failure condition. The MCU may be reset.
[0079] The operation can be continued by the second POR864-1.
[0080] The MCU can execute ROM code 866-1. However, although the ROM code remains the same, due to the state of the NOR device, the recovery code is copied to SRAM instead of the boot code. As a result, when control is passed to SRAM, the recovery code is executed at 872. This behavior allows the modified code to be restored to a known good version (such as the original image). The MCU can then be reset again.
[0081] The operation can be terminated at the third POR864-2. The MCU becomes bootable from ROM866-2. Next, it executes the code copied (restored image) from NOR to SRAM866-2. A health check at application level 874 indicates that the system is healthy (working correctly).
[0082] Figure 8B illustrates the possible boot behavior that may occur when a physical change to the code image occurs during runtime.
[0083] The operation proceeds as shown in Figure 8A, with the execution of the first POR864-0, ROM code 866-0, the execution of the code copied from the NOR device, and the transfer of control to the code copied to DRAM868-0.
[0084] The MCU may initially function correctly. Initially, the code image may be determined to be valid. However, later, during runtime, an unauthorized modification of the code image is detected. As a result, the MCU can be reset with 870-0'. However, due to the timing of the detected fault, the NOR device is not notified of the health check failure (876). Consequently, the non-volatile state of the NOR device remains unchanged.
[0085] The operation can continue with the second POR864-1. Since the code image has been changed, this can be detected as shown in Figure 8A. The MCU can then execute ROM code 866-1, followed by SRAM code 868-1 (which may be invalid). The MCU can detect the health check failure 870-1' and reset. Furthermore, the non-volatile state of the NOR device can be changed.
[0086] The operation can continue with the third POR864-2. After the MCU executes ROM code 866-0, the state of the NOR device has changed, so it can execute a recovery code to reset 872.
[0087] The operation can be terminated by the fourth POR864-3 and the normal boot operation (866-3, 868-3, 874).
[0088] Figure 8C illustrates the boot behavior that may occur when a physical change to the code image occurs during runtime. However, the MCU can notify the NOR device of the error.
[0089] The operation proceeds as shown in Figure 8B, involving the execution of the first POR 864-0, ROM code 866-0, and detection of runtime changes in code image 870-0'. However, due to errors and operating conditions (such as a watchdog state), the MCU may notify the NOR device of a failure (such as an authenticated message). As a result, the NOR device changes its state and can provide a recovery image in the next POR.
[0090] The operation can continue as in Figure 8A, with a recovery operation 872 following the second POR 864-1 and a good health check following the third POR 864-2.
[0091] The embodiments may include any suitable system that stores boot code on an external device, but high-performance, compact systems such as embedded systems can particularly benefit from embodiments of the present invention.
[0092] Figure 9A shows a system 900A according to one embodiment. System 900A may include a system-in-package (SiP) package 976, which has an MCU die 904A and a separate NVM die 906A that communicate via the memory bus 920A of the SiP package. The MCU die 904A may include an MCU according to the embodiments herein or its equivalent. The NVM die 906A may include an NVM device (e.g., NOR flash) according to the embodiments herein or its equivalent.
[0093] Embedded systems can include processor circuitry, associated memory, and I / O circuitry, and are typically formed in a compact structure. Within larger systems, embedded systems can be dedicated to specific functions or sets of functions. In many embedded systems, a high-performance flashless MCU (such as an application processor) can be the preferred processor. As described herein, high-performance flashless MCUs are typically manufactured on advanced processing nodes where incorporating flash is technically difficult and expensive. Therefore, external flash remains the best solution for storing boot code.
[0094] In many applications, embedded systems are expected to communicate with a remote authority that performs periodic health checks. As described herein, the remote authority can be located outside the embedded device. Two possible examples are that the remote authority can be a remote server requiring network access, or a highly secure chip within a larger system in which the embedded device is used.
[0095] Figure 9B is a block diagram of system 900B according to another embodiment. System 900B may include an embedded system 934 and a resilience authority 908. Embedded system 934 may include an NVM device 906B, an MCU 904B, and a trusted platform module (TPM) 978. The MCU 904B and NVM device 906B may take the form of any of those shown in the embodiments herein or equivalents thereof. The TPM 978 may include security circuitry for performing security-related functions of embedded system 934, including, but not limited to, storing cryptographic keys and performing authentication operations.
[0096] The resilience authority 908 may be a remote authority capable of performing fault tolerance functions as described herein, including sending watchdog defer instructions to the NVM device 906B and / or MCU 904B. As described herein, defer instructions may be sent via authenticated communications.
[0097] The embodiments may include any suitable NVM array structure and NVM cell type, but some embodiments may include a 1-transistor (1T) NOR array. Figure 10 is a schematic diagram of a 1T NOR array 1080 that may be included in the embodiments. The array 1080 may include a number of memory cells (illustrated as 1080-0) arranged in rows and columns, where memory cells in the same row are connected to the same word line (illustrated as 1080-2), and memory cells in the same column are connected to the same bit line 1080-3. In some embodiments, the memory cell (1080-0) may be formed by a single transistor structure having a charge storage structure 1080-1 between a control gate and a channel. The charge storage structure 1080-1 can store one or more data bits as charge (or lack thereof).
[0098] Embodiments may include memory devices and systems that operate in conjunction with a host device, but embodiments may also include standalone non-volatile memory devices that can selectively switch address mappings between different locations in response to a watchdog timer or the like, provided that the address mapping switch is non-volatile. Such a standalone memory device may include multiple integrated circuits formed in the same package, but in some embodiments, the memory device may, advantageously, be a single compact integrated circuit. Figure 11 shows a packaged single-chip NVM device 1182. However, it is understood that the memory device may include any other suitable package type, which may include direct coupling of the embodiment's memory device chip onto a circuit board substrate.
[0099] The embodiments may include any suitable system having a processor that stores boot code on an external NVM device that may benefit from or require boot resilience. However, the embodiments may be particularly advantageous in high-reliability systems such as automotive systems. Figure 12 shows an automotive system 1284 according to one embodiment. The automotive system 1284 may include various systems, two of which are shown as 1200A and 1200B, and these may be embedded systems. System 1200A may include a controller device 1204A, an NVM device 1206A, and a DRAM 1252. The controller device 1204A may be a system-on-a-chip (SoC) and may include a processor circuit (e.g., MCU, CPU) or its equivalent as described herein. In some embodiments, system 1200A may be an advanced driver-assistance system (ADAS). System 1200B may include an MCU 1204B and an NVM device 1206B, which may take the form of those described herein or their equivalents.
[0100] Thus, automotive systems equipped with high-performance processing devices (advanced node MCUs) can include external non-volatile storage for boot code while simultaneously possessing a fast and resilient boot function.
[0101] Referring to Figure 13, an automobile 1386 according to one embodiment is shown. The automobile 1386 may have a number of embedded systems (two systems are shown as 1334-0 and 1334-1) that operate with boot code stored in a separate NVM device, such an NVM device providing a resilient boot function and its equivalent as described herein. The embedded systems (1334-0, 1334-1) may include an electronic control unit (ECU) and / or an ADAS. However, in other embodiments, such embedded systems may include a dashboard display / control subsystem and / or an infotainment subsystem, and these are only two of the many possible examples. Each embedded system (1334-0, 1334-1) may include a processor device (e.g., an MCU) and one or more NVM devices that can use a resilient boot function and its equivalent as described herein.
[0102] In the embodiments described above, various systems, devices, and corresponding methods have been shown. Additional methods will be explained with reference to the flowchart.
[0103] Figure 14 is a flowchart of Method 1490 according to one embodiment. In some embodiments, Method 1490 may be performed by an NVM device. Method 1490 may include setting the NV status indicator to a “fault-free” value. The NV status indicator can maintain the state of the NVM device in a non-volatile manner.
[0104] Boot code may be stored in a first section of the NVM device, and recovery code may be stored in a second section of the NVM device (1490-1). In some embodiments, such boot code may be for the latter part of the boot operation, while boot code for the first part of the boot operation is provided by a separate memory device (e.g., onboard ROM). Recovery code may include code that corrects an invalid boot operation. In some embodiments, recovery code may instruct a processing device (e.g., an MCU) to execute boot code that is known to be good. Such recovery operation includes, but is not limited to, any suitable technique, including rewriting the first section of the NVM device having known good boot code, including previous versions, or a known secure version, or retrieving code from a remote source via a secure (e.g., authenticated) communication session. As described herein, the first section and the second section may be different physical locations on the NVM device.
[0105] In a power-on or reset event (1490-2), a predetermined address mapping can be performed according to the NV status indicator (1490-3). If the NV indicator indicates no fault (fault in 1490-3), a predetermined address range can be mapped to a first section (1490-4). If the NV indicator indicates a fault (fault in 1490-3), a predetermined address range can be mapped to a second section (1490-5). In some embodiments, the predetermined address range may correspond to the logical boot code address of the controller device. Such address remapping may take the form of any embodiment disclosed herein or an equivalent thereof.
[0106] Method 1490 can initiate a watchdog period for the NVM device (1490-6). Such a watchdog period can be extended by a remote authority as described herein. When the watchdog period expires (Y in 1490-7), the NV indicator can be set to a fault value (1490-9). Furthermore, if the NVM device receives an authenticated message indicating a fault condition, the NV indicator can be set to a fault value (1490-9). If the NVM device receives an authenticated message indicating that the code is valid (Y in 1490-10), the NV indicator can be set to a no-fault value (1490-11). In some embodiments, such authenticated messages can be received from a controller device or the like.
[0107] Figure 15 is a flowchart of method 1590 according to another embodiment. In some embodiments, method 1590 may be performed by a controller device that accesses an external NVM device in boot and related operations. Following a power-on or reset operation (1590-0), method 1590 may include the execution of onboard ROM boot code (1590-1). Such initial boot code may enable the basic functions of the controller device. Authentication operations may request authentication of the external NVM device (1590-2). Such operations may include any appropriate method, including cryptographic exchange between the controller device and the NVM device. If the NVM device cannot be authenticated (N in 1590-2), the NVM device may be determined to be invalid (1590-3). In some embodiments, in response to an invalid NVM device, the controller device may issue an error indicator or record an error value in internal non-volatile memory.
[0108] If the NVM device is authenticated (Y in 1590-2), method 1590 may initiate a controller watchdog period (1590-4). Such a watchdog period may be deferred by a remote authority as described herein and its equivalents. Code residing in the boot address range of the NVM device may be executed (1590-5). Such actions may include copying the code to another memory (e.g., onboard SRAM) or executing the code directly from the NVM device (i.e., executing in place (XIP)). As can be understood from embodiments herein, the controller device may not be aware of which code is being executed.
[0109] If the executed NVM code is recovery code (recovery code in 1590-6), method 1590 can perform a recovery operation (1590-7). The recovery operation may include any of the ones described herein or their equivalents. If the executed NVM code is boot code (boot code in 1590-6), method 1590 can determine whether the watchdog period has expired (1590-7). Although the watchdog expiration determination step is shown at a specific location in the flowchart of Figure 15, it is understood that such an operation may be independent of other steps that occur in the background of other operations. Therefore, the location of watchdog step 1590-7 should not be interpreted as restrictive.
[0110] If the watchdog period has not expired (N in 1590-7) and all NVM boot code is running (Y in 1590-8), method 1590 can perform boot code verification operations (1590-9). Such actions include, but are not limited to, loading the operating system, switching control of the operating system, and running the code verification application. The code to be verified may include, but is not limited to, the boot code stored in the NVM device. If the boot code fails to verify (N in 1590-9), an authenticated message can be sent to the NVM device to indicate this failure (1590-10).
[0111] If the boot code passes verification (Y in 1590-9), an authenticated message can be sent to the NVM device to indicate this success (1590-11). Method 1590 can then proceed with normal operation (1590-12). Such actions may include a controller device running application code residing on other storage devices. Such operations can continue even if there is no POR or similar event (N in 1590-13).
[0112] If the NVM device is determined to be invalid (1590-3), a recovery operation occurs (1590-7), the watchdog period expires (Y in 1590-7), or an authenticated message indicating a code verification failure is generated (1590-10), method 1590 performs POR operation 1590-0.
[0113] The embodiment can advantageously provide a fast and resilient boot operation to a system that uses external memory to store boot code.
[0114] The embodiments can be included in applications requiring such resilience, such as L4 and / or L5 autonomous vehicles.
[0115] Throughout this specification, any reference to “one embodiment” or “an embodiment” should be understood as meaning that certain features, structures, or characteristics described in relation to the embodiment are included in at least one embodiment of the present invention. Therefore, it should be emphasized or understood that more than one reference to “one embodiment” or “an alternative embodiment” in various parts of this specification does not necessarily refer to the same embodiment. Furthermore, certain features, structures, or characteristics can be combined to be appropriate in one or more embodiments of the present invention.
[0116] Similarly, in the above description of exemplary embodiments of the Invention, it should be understood that various features of the Invention can be grouped together in a single embodiment, figure, or description for the purpose of streamlining the disclosure to aid in understanding one or more aspects of the Invention. However, the method of this disclosure should not be interpreted as reflecting an intention that the claims require more features than expressly described in each claim. Rather, aspects of the Invention consist of fewer features than all the features of the single disclosed embodiment described above. Accordingly, the claims following the detailed description are expressly incorporated into that detailed description, and each claim stands on its own as a separate embodiment of the Invention.
Claims
1. A storage device, wherein the storage device is At least one non-volatile (NV) memory array, A non-volatile fault indicator unit that can be set to at least a fault state or an unfaulted state, Memory watchdog circuit and Address mapping circuit, Includes, The at least one non-volatile (NV) memory array is: A first section having a first physical address range, A second section having a second physical address range, Includes, The memory watchdog circuit is configured to set the fault indicator to a fault state in response to the expiration of a predetermined watchdog period, and the watchdog period is reset in response to a delay instruction. The address mapping circuit described above is In response to the fault indicator unit indicating a fault-free state, the input address is mapped to the first physical address range. In response to the fault indicator unit indicating a fault condition, the input address is mapped to the second physical address range. It is configured in such a way, The memory watchdog circuit is configured to set the fault indicator to a fault state in response to at least a first type of authenticated message, and to set the fault indicator to a fault-free state in response to at least a second type of authenticated message. Storage device.
2. The first section is configured to store the boot code for the system's processor, The second section is configured to store the recovery code for the processor, the recovery code includes a procedure for dealing with a failure to boot the processor. The storage device according to claim 1.
3. The storage device further includes an authentication circuit configured to authenticate messages received by the storage device and generate the deferral instruction from a predetermined authenticated message. The storage device according to claim 1.
4. The storage device further includes a decoder circuit configured to access the NV memory array in response to a decoder address input. The address mapping circuit is further configured to set the value of at least one upper bit of the decoder address input based on the state of the fault indicator unit. The aforementioned input address corresponds to the lower bits of the decoder address input, The storage device according to claim 1.
5. The at least one NV memory array includes a NOR flash array. The storage device according to claim 1.
6. The steps include storing the boot code of the system's processor, which is located outside the non-volatile memory device (NV memory device), in a first physical address range of the NV memory device, The steps include storing the recovery code of the processor in a second physical address range of the NV memory device, A step of starting a memory watchdog circuit in the NV memory device, which is configured to set a fault indicator to a fault state in response to the expiration of the watchdog period, wherein the watchdog period is reset in response to a defer instruction, The operation of the address mapping circuit of the NV memory device, In response to the fault indicator unit indicating that it is in a fault-free state, the step of mapping the input address value to the first physical address range instead of the second physical address range, In response to the fault indicator unit indicating a fault state, the steps include mapping the input address value to the second physical address range instead of the first physical address range, Includes, The fault indicator unit is non-volatile, The memory watchdog circuit is configured to set the fault indicator to a fault state in response to at least a first type of authenticated message, and to set the fault indicator to a fault-free state in response to at least a second type of authenticated message. method.
7. The step of resetting the watchdog period in response to the aforementioned postponement instruction is: The steps include receiving a message from an external source of the NV memory device, The steps include authenticating the aforementioned message, The steps include generating the deferral instruction in response to the authenticated message being a deferral message, including, The method according to claim 6.
8. The method further includes the step of generating the deferral message from a remote authority, the remote authority being selected from a group consisting of a remote server configured to communicate with the NV memory device over a network and a secure device connected to the NV memory device via a wired bus. The method according to claim 7.
9. The method further includes generating the input address value by the operation of the processor and reading the boot code from the NV memory device to the system's volatile memory. The method according to claim 6.
10. The method further includes the step of generating the input address value by the operation of the processor and executing the boot code or the recovery code directly from the NV memory device. The method according to claim 6.
11. The aforementioned method, The steps include storing operating system (OS) code in a third physical address range of the NV memory device, The process involves generating a second input address value through the operation of the processor and reading the OS code from the NV memory device, Further including, The method according to claim 6.
12. The aforementioned method, The operation of the aforementioned processor is used to verify the boot code, The steps include sending a message of a first type to the NV memory device in response to the boot code failing verification, and sending a message of a second type to the NV memory device in response to the boot code passing verification. The operation of the aforementioned NV memory device, The steps include setting the fault indicator unit to a fault state in response to the first type of message, The steps include: setting the fault indicator unit to a fault-free state in response to the second type of message described above; Further including, The method according to claim 6.
13. The processor of the aforementioned system includes a plurality of cores, The step of generating the input address value for reading the boot code from the NV memory device is performed by M cores of the processor. The step of verifying the boot code is performed by N cores of the processor, where N > M, and N and M are natural numbers. The method according to claim 12.
14. The aforementioned method, A step of starting a processor watchdog circuit within the processor, wherein the processor watchdog circuit is configured to generate a processor failure indicator in response to the expiration of the processor watchdog period, and the processor watchdog period is reset in response to a processor defer instruction, The steps include restarting the processor to a predetermined state in response to the processor failure indication, Further including, The method according to claim 6.
15. A system including a non-volatile memory device (NV memory device), wherein the NV memory device is At least one array of NV memory cells, A non-volatile fault indicator unit that can be set to at least a fault state or an unfaulted state, Memory watchdog circuit and Address mapping circuit, A communication circuit configured to receive a delay instruction from an external communication path of the NV memory device, Includes, The at least one array of the NV memory cells is A first section having a first physical address range, A second section having a second physical address range, Includes, The memory watchdog circuit is configured to set the fault indicator to a fault state in response to the expiration of a predetermined watchdog period, and the watchdog period is reset in response to a delay instruction. The address mapping circuit described above is In response to the fault indicator unit indicating a fault-free state, the input address is mapped to the first physical address range. In response to the fault indicator unit indicating a fault condition, the input address is mapped to the second physical address range. It is configured in such a way, The memory watchdog circuit is configured to set the fault indicator to a fault state in response to at least a first type of authenticated message, and to set the fault indicator to a fault-free state in response to at least a second type of authenticated message. system.
16. The NV memory device further includes a decoder circuit configured to access the at least one array in response to a decoder address input. The address mapping circuit is configured to set the value of at least one upper bit of the decoder address input based on at least the fault indicator unit. The aforementioned input address is the lower bit of the decoder address input. The system according to claim 15.
17. The system further includes a controller device coupled to the NV memory device via a memory bus, The memory bus includes at least one controller processor configured to generate and transmit the input addresses via the memory bus and to read data from the NV memory device, The aforementioned NV memory device is The boot code for the controller device is stored in the first section, The second section stores the recovery code for the controller device. It is configured in such a way, The recovery code includes a process for dealing with a boot failure of the controller device. The system according to claim 15.
18. The system further includes the controller device configured to verify the boot code and, in response, generate an authenticated message indicating the result of the code verification for authentication by the NV memory device. The system according to claim 17.
19. The system further includes a remote authority device that is physically separated from the NV memory device and controller device and configured to generate deferred messages. The NV memory device further includes an authentication circuit configured to authenticate the deferral message and generate the deferral instruction in response to the authenticated deferral message. The system according to claim 17.
20. The remote authority device is selected from a group consisting of a remote server configured to communicate with the NV memory device via a network and a secure device connected to the NV memory device via a wired bus. The system according to claim 19.