Method and apparatus for improved automotive electronic control unit reliability and safety during power standby mode

Abstract

The present invention discloses a device and method for improved automotive electronic control unit reliability and safety during power standby mode. In one embodiment, a method is disclosed, comprising: periodically recording memory statistics of a dynamic random access memory in a device while the device is in a power-on state; detecting a command to enter a standby state; analyzing the memory statistics to determine whether a health check should be performed; powering down the device when it is determined that a health check should be performed; and placing the device in a standby mode when it is determined that a health check should not be performed.

Description

[0001] Copyright Notice

[0002] This application contains material that is subject to copyright protection. The copyright owner objects to the facsimile reproduction by anyone of the patent disclosure as it appears in the Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever. Technical Field

[0003] The disclosed embodiments relate to in-vehicle computing systems, and in particular, to devices and methods for improving the operation of dynamic random access memory (DRAM) in an electronic control unit (ECU) of a vehicle. Background Art

[0004] Modern cars contain many ECUs. These ECUs may be used for infotainment systems or may be used as critical systems, such as in autonomous vehicles. In order to reduce startup time, one or more of these ECUs are never completely shut down when the vehicle is powered off. Instead, such ECUs are placed in a "standby" mode (also called a "self-refresh" mode). When in standby mode, the state of the ECU is placed in DRAM, and other components are selectively shut down. Power is maintained to the DRAM and the DRAM is periodically refreshed during this period. When power is applied from standby mode, the components that were powered off restart, and the state in DRAM is used as the current state, allowing the system to "start up" in the same state as when "power was off".

[0005] While standby mode allows for fast turn-on times (because the configured state is already in DRAM and configured), it results in error propagation due to "freezing" the state in DRAM. Specifically, during operation, DRAM data may contain errors (hard or soft) caused by running software or by inherent physical side effects of the underlying DRAM cells. Some of these errors may be corrected by error correction code (ECC) processing installed within the DRAM device, but even the presence of many corrected errors indicates a potential problem with the device. Additionally, the state preservation nature of standby mode exacerbates memory leakage for long-running software.

[0006] The disclosed embodiments improve these and other technical problems by providing methods and devices for checking the health of a DRAM device before entering a standby mode. Summary of the invention

[0007] Some embodiments of the present invention provide a method comprising: periodically recording memory statistics of a dynamic random access memory (DRAM) in the device while the device is in a powered-on state; detecting a command to enter a standby state; analyzing the memory statistics to determine whether a health check should be performed; powering off the device when it is determined that a health check should be performed; and placing the device in standby mode when it is determined that a health check should not be performed.

[0008] Some embodiments of the present invention provide a non-transitory computer-readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining the following steps: when the device is in a powered-on state, periodically recording memory statistics of a dynamic random access memory (DRAM) in the device; detecting a command to enter a standby state; analyzing the memory statistics to determine whether a health check should be performed; powering off the device when it is determined that a health check should be performed; and placing the device in a standby mode when it is determined that a health check should not be performed.

[0009] Some embodiments of the present invention provide a device comprising: a processor; and a storage medium for tangibly storing thereon program logic for execution by the processor, the stored program logic defining the following steps: when the device is in a powered-on state, periodically recording memory statistics of a dynamic random access memory (DRAM) in the device; detecting a command to enter a standby state; analyzing the memory statistics to determine whether a health check should be performed; powering off the device when it is determined that a health check should be performed; and placing the device in a standby mode when it is determined that a health check should not be performed. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The foregoing and other objects, features and advantages of the present invention will become apparent from the following description of the embodiments illustrated in the accompanying drawings, in which reference characters refer to the same parts throughout the various figures. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

[0011] Figure 1 is a flow chart illustrating a method for monitoring errors in a DRAM device according to some embodiments of the present invention.

[0012] Figure 2 is a flow chart illustrating a method for monitoring memory leakage in a DRAM device according to some embodiments of the present invention.

[0013] Figure 3 is a flow chart illustrating a method for performing a health check of a DRAM device before entering a standby mode according to some embodiments of the present invention.

[0014] Figure 4is a block diagram illustrating a transportation network according to some embodiments of the present invention.

[0015] Figure 5 is a block diagram illustrating an ECU according to some embodiments of the present invention. DETAILED DESCRIPTION

[0016] The disclosed embodiments describe systems, devices, methods, and computer-readable media for improving the reliability of a standby mode used by an ECU. During operation, an embodiment monitors the number of corrected (or uncorrected) errors and the number of potential memory leaks. In response to a standby command, an embodiment determines whether the number of errors is below a threshold and whether there is no memory leak. If true, the embodiment enters standby; but if false, the embodiment performs a complete power down and restarts to standby. In this way, when in a potentially corrupted state, the DRAM state is periodically refreshed in the event of a complete power down, thereby ensuring correct operation of the system during restart.

[0017] An embodiment of a method is disclosed, comprising: periodically recording memory statistics (i.e., the number of ECC corrected errors, uncorrected errors, or memory leaks) of a dynamic random access memory in the device while the device is in a powered-on state; detecting a command to enter a standby state; analyzing the memory statistics to determine whether a health check should be performed; powering off the device when it is determined that a health check should be performed; and placing the device in a standby mode when it is determined that a health check should not be performed.

[0018] Figure 1 is a flow chart illustrating a method for monitoring errors in a DRAM device according to some embodiments of the present invention.

[0019] In block 102, the DRAM device is operated normally. During normal operation, data is read from and written to the DRAM by the operating system and other hardware. During a read operation, all data is error checked using an ECC decoder to confirm that no errors have occurred. During a write operation, the DRAM encodes user data using an ECC encoder to generate one or more parity bits, which are stored in the DRAM along with the user data.

[0020] In block 104, the method (100) checks for errors in the DRAM, and in block 106, the method (100) corrects the errors with the ECC circuit.

[0021] In some embodiments, the method (100) performs block 104 as part of a read operation. During a read operation, user data and corresponding parity data are retrieved from the DRAM cells. In some embodiments, the DRAM uses syndrome decoding to detect any errors in the returned user data / parity data and corrects the errors if possible. Once corrected, the DRAM returns the user data in response to the read request. Specific details regarding the operation of ECC in DRAM operation are not presented in detail herein, and any arrangement of ECC in a DRAM (or other storage device) may be used.

[0022] In block 108, the method (100) increments an error count in response to detecting an error in the DRAM memory.

[0023] During operation, a DRAM device may set a bit flag indicating the presence of an error detected during operation. In some devices, this flag includes an error status bit stored in a specific register of the DRAM's controller. In some embodiments, the DRAM device may also log the error to an internal error log. In either case, the presence of an error may be detected by the operating system by reading the contents of the register and / or the error log.

[0024] In the illustrated embodiment, the method (100) maintains a running log of errors encountered by the DRAM. This log of errors may be stored in a permanent storage device (e.g., a flash storage device). In some embodiments, the log itself may be stored in the DRAM. In the former, the log is reset when the operating system performs a system restart. In the latter, the log is automatically reset when the DRAM is powered off, but if the DRAM is suspended in standby mode, the log remains. In some embodiments, the log may be recorded in the DRAM within a given power cycle of the DRAM and simultaneously stored long-term in a non-volatile storage device. In this way, a historical error count of the DRAM may be maintained while maintaining a current session error count.

[0025] In some embodiments, the method (100) stores a single integer representing the number of errors. In block 108, each time an error is detected (e.g., via a DRAM register and / or log file), this integer is incremented. In other embodiments, additional data may be stored. For example, the method (100) may store details about the command that caused the error (e.g., read / write address, data to be written, timestamp, etc.). This data may be extracted from the DRAM log file. In these extended embodiments, the record may then be synthesized by summing the number of entries (or by maintaining a separate single integer record).

[0026] In block 110, after incrementing the error count, the method (100) determines whether a standby mode should be entered.

[0027] In the illustrated embodiment, the standby mode may be entered by an operating system requesting the DRAM to enter the standby mode. Generally, the standby mode in a vehicle is entered when a user of the vehicle turns off the ignition. If the method (100) determines that the standby mode has not been triggered, the method (100) continues to operate the DRAM normally (block 102) and repeats the error handling routine (blocks 104, 106, 108) until the standby mode is entered (block 110).

[0028] In block 112, once a determination is made that the device is entering standby mode, the method (100) performs a health check on the DRAM. Figure 3 Additional details regarding performing the health check in block 112 are described in more detail in FIG.

[0029] Figure 2 is a flow chart illustrating a method for monitoring memory leakage in a DRAM device according to some embodiments of the present invention.

[0030] In block 202, the DRAM device is operated normally. During normal operation, data is read from and written to the DRAM by the operating system and other hardware. During read operations, all data is error checked using an ECC decoder to confirm that no errors have occurred. During write operations, the DRAM encodes user data using an ECC encoder to generate one or more parity bits, which are stored in the DRAM along with the user data. Although illustrated as an initial block, in some embodiments, block 202 is optional in the method (200).

[0031] In block 204, the method (200) determines whether a memory report has been received.

[0032] In the illustrated embodiment, the memory report relates to a list of active processes in DRAM and the amount of memory used by those processes. Generally speaking, an operating system maintains a list of currently executing processes and various statistics about those processes. Examples of such statistics include physical memory used by a process, virtual memory used by a process, swap size used by a process, code size, page fault counts, and various other statistics.

[0033] In one embodiment, when the DRAM is operating normally (i.e., when the device housing the DRAM is powered on), the method (200) periodically performs block 204. For example, the method (200) may sample memory usage via reporting every 30 seconds or every 10 minutes. The specific interval is not intended to be limiting.

[0034] In block 206, the method (200) compares the reported memory usage to historical memory usage for the same process.

[0035] In the illustrated embodiment, each process in the report has a command or program name that identifies the process. Processes also have unique process identifiers, however, these identifiers change based on the time the process was started. Therefore, for the purposes described herein, the command or program name (referred to as the "name" of the process) is used as the basis for comparison. In some embodiments, there may be multiple processes with the same name. In these embodiments, the method (200) may aggregate the memory statistics of these processes into a single process.

[0036] An exemplary memory report may appear as follows:

[0037] PID Order VIRT RES SHR 1 The Watcher 402560 30008 16752 2 monitor 630132 27972 21556 3 Networker 459968 23320 18676

[0038] Table 1

[0039] In Table 1, "VIRT" refers to the amount of virtual memory used by "command" with process identifier "PID". "RES" refers to the memory reserved for the same process (i.e., the process's code and any data used by the process); and "SHR" refers to the amount of shared memory used by the process. Various other fields may be present in the report.

[0040] As discussed, these reports may be received periodically and, in some embodiments, cached by the method (200) for comparison. For example, the five most recent reports may be cached in a database or similar structure for comparison.

[0041] In block 206, method (200) compares the instantaneous report with one or more previous reports to determine whether the amount of memory used by a given process name is increasing. Various thresholds may be used to determine the number of reports that must detect an increase before identifying a memory leak. For example, before predicting a memory leak, method (200) may require that three previous reports must have consecutively decreasing memory values ​​for a given process. Thus, in Table 1, if "Watcher" has a current RES value of 30008 and four consecutive previous values ​​of 30000, 29000, 28000, and 27000, then method (200) determines that a memory leak is likely to exist. Conversely, if the four consecutive previous values ​​are 30000, 31000, 29000, 30500, then method (200) may infer that the process is operating within a normal memory usage range.

[0042] In some embodiments, the method (200) analyzes only the reserved memory used by the process. That is, the memory is dedicated to the process code and the data used. In other embodiments, the method (200) uses other memory metrics, such as virtual memory used or shared memory used. In yet another embodiment, the method (200) may aggregate one or more of these memory measures and use the total memory as the comparison value.

[0043] In another embodiment, the method (200) may analyze the changes between memory fluctuations over time when classifying a process as having a memory leak. For example, by analyzing previous reports, the method (200) may calculate a standard deviation from average memory usage. This standard deviation may be revised over time based on new reports. In this embodiment, the method (200) may compare the deviation indicated by the current report of memory usage to the standard deviation, and if the current memory usage deviates by more than the standard deviation, then the method (200) marks the process as having a memory leak.

[0044] In block 208, the method (200) uses the determination (206) to determine whether a leak has occurred. As described above, the method (200) makes this determination by comparing the current memory usage of the process to the previous memory usage of the process.

[0045] In block 210, after determining in blocks 206 and 208 that a memory leak may have occurred, the method (200) records the memory leak.

[0046] In one embodiment, the method (200) may increment a record of memory leaks detected in blocks 206 and 208. This record of errors may be stored in a permanent storage device (e.g., a flash storage device). In some embodiments, the record itself may be stored in DRAM. In the former, the record is reset when the operating system performs a system restart. In the latter, the record is automatically reset when the DRAM is powered off, but if the DRAM is suspended in standby mode, the record remains. In some embodiments, the record may be recorded in the DRAM within a given power cycle of the DRAM and simultaneously stored long-term in a non-volatile storage device. In this way, the historical memory leak count of the DRAM may be maintained while the current memory leak count is maintained.

[0047] In some embodiments, the method (200) stores a single integer representing the number of memory leaks. In block 210, each time a memory leak is detected (blocks 206 and 208), this integer is incremented. In other embodiments, additional data may be stored. For example, the method (200) may store details about the program that caused the leak, its memory utilization, etc. In these extended embodiments, the record may then be synthesized by summing the number of entries (or by maintaining a separate single integer record).

[0048] Alternatively or in conjunction with the foregoing, in addition to incrementing the leak count, the method (200) may store a probability that a leak has occurred. For example, if memory usage has increased by one byte over the past four cycles, the method (200) may assign a lower probability that a memory leak exists to the leak. Alternatively, if the memory increase is more significant, the probability may be increased.

[0049] At block 212, after recording a memory leak (210) or determining that no leak exists (208), the method (200) determines whether a standby mode should be entered.

[0050] In the illustrated embodiment, the standby mode may be entered by an operating system requesting the DRAM to enter the standby mode. Generally, the standby mode in a vehicle is entered when a user of the vehicle turns off the ignition. If the method (200) determines that the standby mode has not been triggered, the method (200) continues to operate the DRAM normally (block 202) and repeats the leak handling routine (blocks 204, 206, 208, 210) until the standby mode is entered (block 212).

[0051] In block 214, after determining that the device is in standby mode, the method (200) performs a health check on the DRAM. Figure 3 Additional details regarding performing the health check in block 214 are described in more detail in FIG.

[0052] Although the methods (100, 200) are described separately, the methods (100, 200) may be executed in parallel by an operating system of the ECU. Thus, in some embodiments, two records of errors and memory leaks are maintained by the system executing the methods (100, 200).

[0053] Figure 3 is a flow chart illustrating a method for performing a health check of a DRAM device before entering a standby mode according to some embodiments of the present invention.

[0054] As previously discussed, the described method (300) is performed in response to a request to cause a device (including a DRAM) to enter a standby mode. In one embodiment, the method (300) and the methods (100, 200) are performed by an operating system of an ECU. Thus, when the operating system of the ECU receives a standby command, the operating system performs the method (300) before entering the standby mode. In this way, the operating system of the ECU is modified to perform the methods (100, 200, 300).

[0055] In block 302, the method (300) retrieves an error count and a leak count.

[0056] As described above, the error counts and leakage counts may include integer values ​​stored on a non-volatile storage device or stored in DRAM. Alternatively, the error data and leakage data may be aggregated by the method (300) to determine the final error counts and leakage counts. Specific details regarding the storage or aggregation of this data are described in Figure 1 and 2 The above description is described in the description of and will not be repeated in this article.

[0057] In block 304, the method (300) determines whether the error count exceeds a preconfigured error threshold.

[0058] In the illustrated embodiment, the number of errors is an integer value. In the illustrated embodiment, the preconfigured error threshold comprises a fixed integer value of allowable errors. Thus, if the preconfigured error threshold is 4 and the error count is 5, then the method (300) continues to block 310. Likewise, if the error count is 3, then the method (300) continues to block 306.

[0059] In other embodiments, the preconfigured error threshold may include a dynamic value. In this case, the threshold may be adjusted based on a variety of factors. In one example, the preconfigured error threshold may change based on the operating time of the DRAM in each power cycle. That is, as the DRAM is powered on or as the DRAM is in standby, the preconfigured error threshold increases linearly (or otherwise). As another example, the preconfigured error threshold may increase based on the throughput of the DRAM. In this case, more frequent reading or writing to the DRAM increases the chance of error, and therefore the preconfigured error threshold is adjusted upward accordingly. As another example, the preconfigured error threshold may increase based on the age of the DRAM. In this example, older DRAMs may be more susceptible to errors, and therefore more errors may be corrected than newer DRAMs. The age of the DRAM may be calculated based on the first startup of the DRAM identified by the operating system or may be hard-coded into the settings of the DRAM controller. As another example, the preconfigured error threshold may be preconfigured in the settings of the DRAM controller by the manufacturer. In this example, the DRAM manufacturer sets the expected number of errors in a given cycle, and the operating system uses this value to calculate the preconfigured error threshold for a given cycle. In a dynamic example, a separate routine is executed to manage the value of the preconfigured error threshold. Thus, as an example, if the manufacturer specifies that the DRAM should only correct one error per year, the preconfigured error threshold is set to 1 in the first year. After the first year expires, the preconfigured error threshold may be set to 2.

[0060] In block 306 , the method ( 300 ) determines whether the leak count is greater than zero.

[0061] In one embodiment, the decision in block 306 is a hard decision: if the method (200) determines that a leak is likely to occur, then the decision in block 306 will result in a restart (block 310).

[0062] In block 310 , if the error count exceeds a preconfigured error threshold or the leakage count is greater than zero, the method ( 300 ) restarts the ECU (and DRAM).

[0063] Alternatively, if the leak count is associated with a probability (as described in the description of block 210), then the method (300) determines whether the number of leaks having a probability greater than a predetermined leak likelihood threshold is greater than zero. In some embodiments, the method (300) may further analyze the number of memory leaks associated with the identified memory leak. In some embodiments, the method (300) will only count those processes leaking memory that exceed a preconfigured maximum leak threshold. In some cases, this preconfigured maximum leak threshold includes an instantaneous value (i.e., currently leaking memory), while in other cases it may include the number of leaks within the past four (4) time periods.

[0064] Although illustrated as a sequential operation, the order of blocks 304 and 306 may be reversed or may be performed in parallel.

[0065] In block 308, if the error count is below (or equal to) a preconfigured error threshold and the leak count is zero, the method (300) enters standby mode. Additionally, the method (300) enters standby mode after a restart (block 310).

[0066] As illustrated, if the error count is below the trigger threshold and there is no identified memory leak, the method (300) continues to accept the standby request and place the system in standby mode.

[0067] However, if one or both of the conditions tested in blocks 304 and 306 are true, the method (300) restarts the device. In the illustrated embodiment, restarting the device includes completely powering off all components of the device including the DRAM. Because the SDRAM is powered off, all storage contents on the DRAM device are lost and the DRAM restarts in an initialized state.

[0068] In addition, if Figure 3 , after a reboot, the method (300) immediately enters standby mode. In this case, the method (300) deviates from the traditional power on process by requiring the device to enter standby mode after power is applied. In one embodiment, the device enters standby mode after reaching a fully powered on state. In this case, after reaching that state, the operating system will be fully loaded and suspended. Similarly, the DRAM will be initialized as if rebooted and suspended in that state to wait for wakeup from standby. In this way, the entire contents of the DRAM (including error-prone cells and memory leaking programs) are completely erased from the DRAM.

[0069] In some embodiments, as part of block 310, the method (300) may take a snapshot of running processes before shutting down. Notably, the method (300) does not take a snapshot of the state of these processes (i.e., as a hibernation state would do), but rather records the programs (and, if possible, the locations of these programs). Upon restart, the method (300) starts the programs and, upon detecting that the programs have been started, immediately enters standby mode.

[0070] Figure 4 is a block diagram illustrating a transportation network according to some embodiments of the present invention.

[0071] exist Figure 4 In, the vehicle (400) may include any type of vehicle (e.g., a car, a boat, etc.). In general, the vehicle may include any superstructure that accommodates various discrete computing systems, and the vehicle is provided as an example. The vehicle (400) includes one or more ECUs (402a to 402n). Examples of ECUs include a door control unit (DCU), an engine control unit, an electric power steering control unit (PSCU), a human-machine interface (HMI), a powertrain control module (PCM), a seat control unit, a speed control unit (SCU), a telecontrol unit (TCU), a transmission control unit (TCU), a brake control module (BCM; ABS or ESC), or a battery management system (BMS) device. Although primarily described in the context of an ECU device, any type of embedded computing system may be used in the embodiments disclosed herein, and embodiments of reference ECU devices are provided as examples. Exemplary configurations of ECUs are described in the following. Figure 5 , and the discussion will not be repeated herein.

[0072] The ECUs (402a to 402n) are each connected to a bus (404). In some embodiments, the bus (404) includes a CAN bus, a FlexRay MOST bus, or any other type of bidirectional communication bus.

[0073] The processing side of the system includes one or more processors (406), short-term memory (408), an RF system (412), a graphics processing unit (GPU) (414), long-term storage (410), and one or more interfaces (418).

[0074] The one or more processors (406) may include a central processing unit, an FPGA, or any range of processing devices required to support the operation of an autonomous vehicle. The memory (408) includes DRAM or other suitable volatile RAM for temporarily storing data required by the processor (406). The RF system (412) may include a cellular transceiver and / or a satellite transceiver. The long-term storage device (410) may include one or more high-capacity solid-state drives (SSDs). In general, the long-term storage device (410) can be used to store (for example) high-definition maps, routing data, and any other data that requires permanent or semi-permanent storage. The GPU (414) may include another high-throughput GPU device for processing data received from other vehicle subsystems. Finally, the interface (416) may include various display units (such as built-in screens) located within the vehicle. In the illustrated embodiment, the memory (408) and / or the storage device (410) include pre-boot software configured to perform the previously described method.

[0075] Figure 5 is a block diagram illustrating an ECU according to some embodiments of the present invention.

[0076] In the illustrated embodiment, the ECU (500) is communicatively coupled to a bus (508) via an interface (506). As discussed above, the bus (508) may include a CAN, FlexRay, MOST bus, or a similar type of bus. Correspondingly, the interface (506) may include a similar interface for accessing the specific type of bus being used.

[0077] The ECU (500) further includes a microcontroller (502), an R / F subsystem (510), an application specific component (ASC) (512), and a memory system (504). In the illustrated embodiment, the microcontroller (502) may include a processor or a smaller microcontroller configured to control the operation of the ECU (500). In some embodiments, the microcontroller (502) accesses program instructions stored in the memory system (504) and, in accordance with those instructions, drives the ASC (512). Examples of the ASC (512) include actuators for door controls, display units for infotainment ECUs, transmission controls for TCUs, and various other controls. The type of ASC used by the ECU (500) is not limiting, and any type of ASC may be used by the ECU (500).

[0078] The ECU (500) additionally includes an R / F system (510). In the illustrated embodiment, the R / F system (510) may include one or more radios or transceivers for communicating with a wireless network. The R / F system (510) may include a Bluetooth, Wi-Fi, or cellular radio or satellite transceiver. In some embodiments, the R / F system (510) includes a combination of radios or transceivers. In some embodiments, the ECU (500) may not include the R / F system (510), and may instead utilize a full vehicle R / F system, as previously described.

[0079] The microcontroller (502) manages the memory system (504). In the illustrated embodiment, the memory system (504) includes DRAM (504a), electrically erasable programmable read-only memory (EEPROM) (504b), flash memory (504c), and ECC logic (504d).

[0080] In the illustrated embodiment, the flash memory (504c) comprises the main non-volatile and long-term storage device of the ECU (500). The flash memory (504c) may comprise single-level NAND flash, multi-level cell NAND flash, or any other type of flash architecture. Alternatively or in conjunction with the foregoing, the flash memory (504c) may be replaced or supplemented by a hard disk (magnetic) storage device. In general, the flash memory (504c) stores all data used by the ECU (500) including the operating system. The methods (100, 200, 300) may be executed by software included in the operating system or otherwise stored on the flash memory (504c). The memory system (504) additionally comprises an EEPROM (504b) that stores firmware and other frequently modified data (e.g., boot settings, etc.).

[0081] The memory system (504) includes DRAM (504a). DRAM (504a) may include any type of DRAM (504a) that provides volatile storage for ECU (500), and the present invention is not limited to a particular arrangement of DRAM used by DRAM (504a). DRAM (504a) may be coupled to ECC (504d), or ECC (504d) may be embedded within DRAM (504a). ECC (504d) is responsible for performing error correction on any data marked as corrupted by DRAM (504a). As described above, software in an operating system, such as in flash (504c), accesses DRAM (504a) and / or ECC (504d) to monitor when ECC (504d) performs error correction. The operating system also periodically receives reports from DRAM (504a) on memory usage by active processes. These statistics are stored in flash (504c) for later use, as previously described. Additionally, the operating system receives an initial command to enter standby mode and executes the previously described method in response to this command.

[0082] The ECU (500) also includes a power supply (514). In some embodiments, the power supply (514) may include a power converter that converts a baseband power supply (not depicted) into the voltage and current required by all components of the ECU (500). In some embodiments, the power supply (514) may include multiple discrete power sources (e.g., external power, battery power, etc.) and may be managed by a power management integrated circuit (PMIC). In the illustrated embodiment, the power supply (514) supplies power to each of the individually illustrated components. In addition, the power supply (514) may be configured to selectively disable and enable power to each component. During standby mode, for example, the power supply (514) maintains power to the DRAM (504a) while disabling (or reducing) power to all other components. The power supply (514) may be programmatically controlled by an operating system stored in flash (504c). Specifically, as described above, the operating system is configured to instruct the power supply (514) to enter a low power mode in response to determining that a standby state should be entered. The operating system may additionally instruct the power supply (514) to enter a shutdown state.

[0083] The present invention is more fully described hereinafter with reference to the accompanying drawings which form a part of the present invention, and which illustrate specific example embodiments by way of illustration. However, subject matter may be embodied in a variety of different forms, and therefore, it is intended that the subject matter covered or claimed is not limited to any example embodiment set forth herein; the example embodiments are provided only as being illustrative. Likewise, a reasonably broad scope of the subject matter claimed or covered is desired. In addition to these things, for example, the subject matter may be embodied as a method, device, component, or system. Thus, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (except for the software itself). The following detailed description is therefore not intended to be understood in a limiting sense.

[0084] Throughout the specification and claims, terms may have subtle meanings that are suggested or implied in context beyond the explicitly stated meaning. Likewise, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment" as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter encompasses, in whole or in part, a combination of example embodiments.

[0085] In general, terms can be understood at least in part from the context of use. For example, terms such as "and", "or" or "and / or" as used above can include multiple meanings, which can depend at least in part on the context in which such terms are used. Typically, "or" if used in an association list, such as A, B or C, is intended to mean A, B and C, which are used here in an inclusive sense, and is also intended to mean A, B or C, which are used here in a dedicated sense. In addition, the term "one or more" as used herein can be used to describe any feature, structure or characteristic in a singular sense, or can be used to describe a combination of features, structures or characteristics in a plural sense, depending at least in part on the context. Similarly, for example, "a / an" or "the" can also be understood to express singular use or plural use, which depends at least in part on the context. In addition, the term "based on" can be understood to not necessarily wish to express a set of dedicated factors, and can instead allow the presence of additional factors that are not necessarily explicitly described, which depends at least in part on the context.

[0086] The block diagram and the operation description of reference method and device have described the present invention.It should be understood that the combination of each frame in the block diagram or the operation description and the frame in the block diagram or the operation description can be implemented with analog or digital hardware and computer program instructions.These computer program instructions can be provided to a general-purpose processor, a special-purpose computer, an ASIC or other programmable data processing equipment so that the instruction (it is executed via the processor of a computer or other programmable data processing equipment) is implemented in the function / action specified in the block diagram or the operation frame or several operation frames.In some alternative embodiments, the function / action noted in the frame may not occur in the order noted in the operation description.For example, two frames of continuous display can actually be performed substantially simultaneously, or the frame can sometimes be performed in reverse order, depending on the functionality / action involved.

[0087] For the purposes of the present invention, a computer-readable medium (or computer-readable storage medium) stores computer data, which may include computer program code (or computer-executable instructions) in a machine-readable form that can be executed by a computer. By way of example and not limitation, a computer-readable medium may include a computer-readable storage medium for tangible or fixed storage of data or a communication medium for the transient interpretation of a code-containing signal. As used herein, a computer-readable storage medium refers to a physical or tangible storage device (as opposed to a signal), and includes (without limitation) volatile and non-volatile, removable and non-removable media implemented in any method or technology for tangible storage of information (such as computer-readable instructions, data structures, program modules or other data). Computer-readable storage media include (but are not limited to) RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, DVD or other optical storage devices, cassettes, magnetic tapes, disk storage devices or other magnetic storage devices, or any other physical or material media that can be used to tangibly store the desired information or data or instructions and can be accessed by a computer or processor.

Claims

1. A method for operating a dynamic random access memory DRAM, comprising: periodically recording memory statistics of the DRAM in the device while the device is in a powered-on state; Detect the command to enter the standby state; analyzing the memory statistics to determine whether a health check should be performed; powering down the device when it is determined that the health check should be performed; and The device is placed in a standby mode when it is determined that the health check should not be performed.

2. The method of claim 1, said periodically recording memory statistics of a dynamic random access memory comprises incrementing a count of errors corrected by said DRAM. 3 . The method of claim 1 , wherein periodically recording memory statistics of a dynamic random access memory comprises incrementing a memory leak count occurring in the DRAM.

4. The method of claim 3, wherein incrementing a memory leak count occurring in the DRAM comprises: receiving a report on memory usage of one or more currently active processes; and If the memory usage of an active process has increased compared to a previously recorded memory usage of the active process, then a memory leak is identified. 5 . The method of claim 3 , the analyzing the memory statistics to determine whether the health check should be performed comprises determining whether the memory leak count is greater than zero. 6 . The method of claim 2 , the analyzing the memory statistics to determine whether the health check should be performed comprises determining whether the error count is greater than a predetermined threshold.

7. The method according to claim 1, further comprising: powering up the device after powering down the device; and The device is placed in a standby mode after powering up the device.

8. A non-transitory computer readable storage medium for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the following steps: When the device is in a powered-on state, periodically recording memory statistics of a dynamic random access memory DRAM in the device; Detect the command to enter the standby state; analyzing the memory statistics to determine whether a health check should be performed; powering down the device when it is determined that the health check should be performed; and The device is placed in a standby mode when it is determined that the health check should not be performed.

9. The non-transitory computer-readable storage medium of claim 8, the periodically recording memory statistics of a dynamic random access memory comprises incrementing a count of errors corrected by the DRAM.

10. The non-transitory computer-readable storage medium of claim 8, the periodically recording memory statistics of a dynamic random access memory comprises incrementing a memory leak count occurring in the DRAM.

11. The non-transitory computer-readable storage medium of claim 10, wherein the incrementing a memory leak count occurring in the DRAM comprises: receiving a report on memory usage of one or more currently active processes; and If the memory usage of an active process has increased compared to previously recorded memory usage of the active process, then a memory leak is identified.

12. The non-transitory computer-readable storage medium of claim 10, the analyzing the memory statistics to determine whether the health check should be performed comprises determining whether the memory leak count is greater than zero.

13. The non-transitory computer-readable storage medium of claim 9, the analyzing the memory statistics to determine whether the health check should be performed comprises determining whether the error count is greater than a predetermined threshold.

14. The non-transitory computer readable storage medium of claim 8, the computer program instructions further defining the following steps: powering up the device after powering down the device; and The device is placed in a standby mode after powering up the device.

15. A device for operating a dynamic random access memory DRAM, comprising: processor; and A storage medium for tangibly storing thereon program logic for execution by the processor, the stored program logic defining the following steps: periodically recording memory statistics of the DRAM in the device while the device is in a powered-on state; Detect the command to enter the standby state; analyzing the memory statistics to determine whether a health check should be performed; powering down the device when it is determined that the health check should be performed; and The device is placed in a standby mode when it is determined that the health check should not be performed.

16. The apparatus of claim 15, said periodically recording dynamic random access memory memory statistics comprising incrementing a count of errors corrected by said DRAM.

17. The apparatus of claim 15, wherein the periodically recording memory statistics of a dynamic random access memory comprises incrementing a memory leak count occurring in the DRAM.

18. The apparatus of claim 17, wherein the incrementing of a memory leak count occurring in the DRAM comprises: receiving a report on memory usage of one or more currently active processes; and If the memory usage of an active process has increased compared to previously recorded memory usage of the active process, then a memory leak is identified.

19. The apparatus of claim 17, the analyzing the memory statistics to determine whether the health check should be performed comprises determining whether the memory leak count is greater than zero.

20. The apparatus of claim 16, the analyzing the memory statistics to determine whether the health check should be performed comprises determining whether the error count is greater than a predetermined threshold.

21. The apparatus of claim 15, wherein the stored program logic further defines the following steps: powering up the device after powering down the device; and The device is placed in a standby mode after powering up the device.

Images