WO2015147829A1

WO2015147829A1 - System and method of run-time continuous memory check for embedded systems

Info

Publication number: WO2015147829A1
Application number: PCT/US2014/032008
Authority: WO
Inventors: Kun Ji; Hartmut Ludwig
Original assignee: Siemens Aktiengesellschaft; Siemens Corporation
Priority date: 2014-03-27
Filing date: 2014-03-27
Publication date: 2015-10-01

Abstract

A method (100) of cyclically performing progressive RAM tests during normal operation of an embedded system (10).

Description

SYSTEM AND METHOD OF RUN-TIME CONTINUOUS MEMORY CHECK FOR EMBEDDED SYSTEMS

FIELD OF INVENTION

The present invention relates to embedded systems. More particularly, the present invention relates to memory testing for embedded systems.

BACKGROUND OF THE INVENTION

Embedded systems are widely used in consumer, industrial and military applications. Generally, an embedded system is a computer system with a dedicated function within a larger mechanical or electrical system, for example, an embedded train control system.

In a normal operation, existing embedded systems typically perform at the beginning of system startup a memory check, for

example, a progressive read-access memory (RAM) test, of the system's memory. Embedded systems have limited processing and input/output capabilities so a memory check is an important reliability safeguard.

This is especially true for safety-critical embedded systems which require a more careful reliability review. Disadvantageously, this could adversely affect the start up performance since checking memory usually requires significant time to finish checking the whole memory area, especially when the size of the RAM is large. It is therefore a bottleneck for the startup time of the entire embedded system.

Checking memory after an embedded system starts up and during run-time with normal operation would be desirable. However, this usually cannot be done since there is no existing method to handle several key problems. First, there is a question of how to check memory area occupied by the checking algorithm/program or function itself. Next, there is a question of how to access write-protected memory areas (e.g., text/code segments of other memory modules). Finally, there needs to be a solution for how to cyclically check memory without affecting the system's normal operation.

SUMMARY OF THE INVENTION

The above problems are obviated by the present invention which provides a method of testing the memory of an embedded system, comprising performing a check of a portion of the memory as a

background task during the normal run operation of the embedded system and repeating the performing step for a different portion of the memory until the entire memory is checked. The performing a check of a portion of the memory as a background task may comprise performing a check of a respective portion of the memory during system idle time. The portions of the memory being checked may be a preconfigured size that does not have a negative impact on the normal run operation. Also, the portions of the memory being checked may be configurable. In such case, a size of a respective portion of the memory being checked may be configured based on system idle time.

The method may further comprise optimizing a size of a respective portion of the memory being checked that does not have a negative impact on the normal run operation. The method may further comprise removing write-proteefion on a portion of the memory being checked for the duration of the respective performing step. Also, the method may further comprise carrying out a check of a first respective portion of the memory utilized by the embedded system for the performing and repeating steps by a second respective portion of the memory utilized by the embedded system for the performing and repeating steps. The method may further comprise reporting the results of checking a respective portion of the memory to a safety handling function of the embedded system.

The present invention also provides a method of continuous memory checking for embedded systems, comprising triggering a memory test algorithm to evaluate the system memory of the system; cyclically executing the memory test algorithm during run-time of the system to evaluate a section of the system memory each cycle; and reporting results of memory test algorithm evaluations. The triggering step may be performed at the startup of the system or, alternatively, during the run-time of the system. In the later case, the triggering step may not be included in a startup bootline sequence. Also, the triggering step may be performed at the startup of the system and the executing step may be performed during the run-time of the system.

The memory test algorithm may comprise a progressive memory test. The progressive memory test may comprise testing data lines, address lines, and a memory chip of the system. The cyclically

executing step may comprise configuring the size of a respective section of the system memory being evaluated each cycle. The cyclically executing step may be performed during system idle time in the run-time of the system. In such case, the cyclically executing step may comprise determining an optimal size of a respective section of the system memory being evaluated in a respective cycle so there is no negative impact on the normal performance of the system during the run-time of the system.

Also, the cyclically executing step may comprise removing write- protection on a respective section of the system memory being

evaluated for the duration of executing the memory test algorithm to evaluate said respective section. The cyclically executing step may comprise executing the memory test algorithm in ping-pong fashion between two sections of the memory utilized by the memory test algorithm so as to evaluate the memory utilized by the memory test algorithm. The reporting step may comprise interacting with a safety handling function of the system to manage the results of memory test algorithm evaluations.

The present invention also provides a method of testing the memory of a computer-based system, comprising performing a check of the memory as a background task during the normal run operation of the system, the work load of memory checking being distributed over time of the normal run operation.

The present invention also provides a computer-based system, comprising a system memory that is adapted to store various algorithms and software; and a processor that is adapted to execute the stored algorithms and software and associated tasks and to perform a test of the system memory as a background task during normal run operation of the system, the work load of memory testing being distributed over time of the normal run operation.

DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention, reference is made to the following description of an exemplary embodiment thereof, and to the accompanying drawings, wherein:

Figure 1 is a block diagram of an exemplary embedded system (simplified);

Figure 2 is a flowchart of a method performed in accordance with an embodiment of the present invention;

Figure 3 shows illustrations of operations of checking a data bus in a memory test cycle; Figure 4 shows illustrations of operations of checking an address bus in a memory test cycle;

Figure 5 shows illustrations of operations of checking a physical memory chip in a memory test cycle;

Figure 6 is a schematic representation of a sequence diagram of checking the physical memory chip for an embedded system using VxWorks as the operating system (OS);

Figure 7 is a flowchart of an optimization process of the method of Figure 2 to obtain an optimal memory test cycle;

Figure 8 is an illustration of memory areas used by the method of Figure 2; and

Figure 9 is an illustration of memory areas checked by the method of Figure 2.

DETAILED DESCRIPTION

Figure 1 is a block diagram of an exemplary embedded system 10 (simplified). The system 10 comprises a processor 12 (and associated peripherals) that provides limited processing power and memory

capacity. The associated peripherals may include system memory, a power supply, communication ports, etc. The processor 12 is adapted to store and run various algorithms and software. These include, among others, a scaled down version of an operating system (i.e., a real time operating system); application software for carrying out a particular dedicated function and associated tasks; and memory checking-related algorithms. The processor 12 may comprise a microprocessor, a microcontroller, an FPGA, etc. The embedded system 10 is typically built to operate completely or partially independent of human

intervention and, in such case, the inputs to the processor 12 are typically the outputs of various types of sensors 16a, 16b, 16c within the larger mechanical or electrical system (not shown), for example, acce I ero meters, temperature sensors, timing sensors, etc. Appropriate input interfaces 14 deliver the sensor output signals to the processor 12. The processor 12 then executes the programmed application software and appropriate output interfaces 18 deliver processor 12 output signals to operating mechanisms 20a, 20b within the larger mechanical or electrical system, for example, actuators, indicators, etc.

The various components of the embedded system 10 may be conventional and well understood components. The embedded system 10, and the processor 12 in particular, is also adapted to implement and to operate methods performed in accordance with embodiments of the present invention. Figure 2 is a flowchart of a cycle of the basic

operations of such a method 100.

As indicated above, performance tests show that an embedded system's startup time is significantly affected by the startup memory check. To improve system start up performance, a memory check can be postponed to the later stage when the embedded system is up and running. However, performing a memory check, such as a RAM test, during run-time of the system introduces new problems, such as how to avoid affecting a system's normal operations and how to check special memory areas, especially the memory areas where the checking program or function itself occupies and executes.

In brief, the present invention provides a continuous memory check that distributes the memory checking load over time. Instead of checking the complete memory area and executing a respective checking algorithm at the one time during system startup, the present invention runs the memory check as a background cyclic task during normal operation of the embedded system and checks a small piece of memory at a time.

As described in more detail below, the method 100 of the present invention has several significant aspects. First, the method 100

postpones a memory check from the system startup phase to the system running phase (for example, by removing a memory check from the system's startup bootline sequence) and, thus, enables a significant reduction in the system startup time. Also, the method 100 provides a background memory test cycle size that is configurable so as to

accommodate different applications. Also, the method 100 provides smart testing of memory areas of text segments and the task stack of the checking algorithm/function itself. Further, the method 100 integrates memory test failure handling into system safety handling since a memory check is also necessary for embedded systems as a safety measure.

Referring to Figure 2, the method 100 starts a test cycle in performing a memory check (Step 102). The method 100 may, for example, conduct over normal operation time a progressive RAM test or execute any other RAM test algorithm. Regardless, the method 100 scales down the respective RAM test algorithm to test a small piece of memory in one cycle. Figure 2 shows, in particular, the method 100 executing a simple algorithm of a RAM test that writes several bytes to a selected memory area, reads the bytes out, and then compares the written data with the read-out data. This test algorithm includes testing the data bus/line, the address bus/line and the memory chip of the processor. Specifically, the method 100 checks the data bus/line (Step 104) and, if the data bus/line passes the check, the method 100 checks the address bus/line (Step 106). If the address bus/line passes the check, the method 100 checks the memory chip (Step 108). If the memory chip passes the check, the method 100 concludes the test cycle for the selected memory area (Step 1 10) and the method 100 can start a test cycle for another selected memory area. If a check of any of the data bus/line, address bus/line or memory chip fails, the method 100 reports the failure and stops the testing (Step 1 12), The method 100 continues executing the test algorithm over normal operation time until the entire memory is tested or until memory checking is completed as desired.

As indicated above, the method 100 may execute any type of RAM test algorithm, such as Checkerboard, March, Walk path, GALPAT, Abraham, etc. The method 100 may use a Walking 1 ^!s value test to check the correct wiring of the data bus/line and to check, on the required address bits, for aliasing errors and "stuck-high", "sfuck-low", and ^!istuck-together^!! pins. A Walking 1 's value test or algorithm is a simple test that writes a "1" value into each memory cell (each bit location), reads it back, and then compares the written data with the read-out data.

Figure 3 illustrates operations of checking a data bus/line in a test cycle using a Walking 1 ^ss value test. Figure 3 shows that, at each running cycle, the method 100 locks the CPU (processor) and cache to prevent other tasks of the system accessing the memory or RAM to be tested 150 (Step160), and then copies and stores the original value from the selected memory area (cells) 155 that is being checked (Step 185). A Walking Ts test is carried out for the selected memory area to check the data bus/line (Step170). The original data is copied back to the checked memory area 155 (Step175) and the CPU, and all interrupts and cache, are enabled (Step180) after the check is done. Figure 4 illustrates operations of checking an address bus/iine In a test cycle using a Walking 1 's value test. Figure 4 shows that, at each running cycle, the method 100 locks the CPU (processor) and cache to prevent other tasks of the system accessing the memory or RAM to be tested 200 (Step 210), and then copies and stores the original value from the selected memory area (cells) 205 that is being checked (Step 215). A Walking 1 's test is carried out for the selected memory area to check the address bus/line (Step 220). The original data is copied back to the checked memory area 205 (Step 225) and the CPU, and all interrupts and cache, are enabled (Step 230) after the check is done.

The method 100 may use an increment test or algorithm for the physical memory area which, generally, sets every memory bit once to a "1 " value and once to a "0" value, reads each respective bit value, and compares the written data with the read-out data. Figure 5 illustrates operations of checking a physical memory area in a test cycle using an increment test. Figure 5 shows that, at each running cycle, the method 100 locks the CPU (processor) and cache to prevent other tasks of the system accessing the memory or RAM to be tested 250 (Step 260), and then copies and stores the original value from the selected memory area (cells) 255 that is being checked (Step 265). An increment test is carried out for the selected memory area to check the physical memory (Step 270). Two rounds of write and read operations are performed to ensure that every bit of the memory has been double checked by writing and reading both "1"s and "0"s. The original data is copied back to the checked memory area 255 (Step 275) and the CPU, and all interrupts and cache, are enabled (Step 280) after the check is done. Figure 6 shows a sequence diagram of checking the physical memory chip using the method 100 and the testing algorithm of Figure 5 in the application of an embedded system using VxWorks as the operating system (OS),

As noted above, the method 100 runs the memory check as a background cyclic task during normal operation of the embedded system and checks a small piece of memory at a time. Importantly, the method 100 provides that the background RAM test cycle size is configurable, i.e., the number of memory bytes being checked in one cycle is

configurable. In executing a background task, the method 100 will utilize system idle time to do a RAM test so there is no performance impact on the system normal operations. Depending on the system load, CPU utilization, and the complexity of the test algorithms, a RAM test cycle size can be a different, bigger RAM test cycle size. This means

checking more bytes in one cycle, a longer time of CPU and interrupt being locked, and a shorter time needed to finish checking the whole RAM.

Figure 7 is a flowchart of an optimization process 300 of the method 100 to obtain an optimal test cycle size based on a

preconfigured test cycle time which has no negative impact on the system normal performance. In brief, the process 300 starts the

optimization task (Step 305) which comprises starting a timer that defines a preconfigured test cycle time (Step 310). As the timer operates without timing out (Step 315), the process 300 obtains the test cycle size from the last test cycle utilized (Step 320) and starts the memory check (e.g. a RAM test) (Step 325). The process 300 checks if the memory check task is completed after the time-out of the timer (Step 330). If the memory check task is completed, then the last test cycle size is optimized and the optimization task is exited (Step 335). If the memory check task is not completed, then the last test cycle size is not found to be optimized. Consequently, the cycle size is reduced by a predetermined amount (Step 340), and the process 300 is re-started (Step 305). The process 300 continues until a respective last test cycle size is optimized and the optimization task is exited.

As noted above, the method 100 also provides smart testing of memory areas of text segments and the task stack of the checking algorithm/function itself. Since software implementing the method 100 (including the respective memory test algorithms) also occupies memory, for example, to execute respective RAM test functions, the method 100 addresses how to check memory areas occupied by the checking algorithm/function itself and how to access write-protected memory area (e.g. text/code segments of other memory modules).

Figure 8 is an illustration of memory areas 400 used by the method of Figure 2 which may include a text segment 405, a data segment 410, a BSS segment (uninitialized data segment) 415 and a task stack/block 420 of the checking algorithm/function.

The method 100 uses a ping-pong checking method 500 to check the RAM areas occupied by the method 100 software to avoid self- checking conflicts. This is illustrated in Figure 9 which shows two memory modules 400a, 400b occupied by the method 100 software being used to work together and check each other. Briefly, to locate the task stack used by the method 100 software, the method 100 software can be initialized with a specified stack address instead of one randomly assigned by the operating system (OS). In a case the embedded system uses VxWorks as the operating system (OS), the method 100 software may be initialized using tasklnit (not taskSpawn) to be able to use a user specified RAM address as the stack address. The address information of the text segment, the data segment and the BSS segment can be retrieved by moduleldListGet and modulelnfoGet,

To check write-pro tected areas such as text/code segments, the memory manager unit (MMU) of the embedded system needs to be modified in run-time to temporarily remove the write-protection on the RAM area being checked. In a case the embedded system uses

VxWorks as the operating system (OS), the application program

interfaces (APIs) used to modify the MMU state are vmStateGet and vmStateSet

As noted above, the method 100 also integrates RAM test failure handling into system safety handling since a memory check is also necessary for embedded systems as a safety measure. The method 100 provides an interface to the system safety handling features to handle the scenario of a memory test failure. The method 100 may be

accomplish this, for example, by reporting the RAM address where the memory test failed back to the onboard safety handling unit of the embedded system so as to trigger an appropriate system fail safe procedure.

The method 100 adapts RAM test algorithms to be executed cyclically in many small chunks of time during system normal operation for embedded systems. Without doing respective RAM tests during system startup, the problem of startup time bottleneck due to initial RAM check is solved. Further, the method 100 performs memory checking during system run-time as a background task. As a consequence, memory checking does not affect the normal operation of the system. Also, the work load of memory checking is distributed over time and can be integrated into embedded systems' safety features to report memory test results. The method 100 can be extended to be used in any applications where initial memory check at system startup is undesired.

Other modifications are possible within the scope of the invention. The method 100 may postpone a memory check from the system startup phase to the system running phase using various techniques, for example, triggering or starting a memory check at the system startup phase but delaying its test cycle until the system running phase. Also, the method 100 continues executing a respective test algorithm over normal operation time until the entire memory is tested or until memory checking is completed as desired, which may include checking only a designated portion of the memory or checking memory only up to a specified time point. Also, the method 100 may report all or selected memory test results, not just memory test failures, to the onboard safety handling unit of the embedded system.

The embedded system 10 has been described in a simplified fashion and may be constructed in various well-known manners and using various well-known components. Also, although the steps of the method 100 have been described in a specific sequence, the order of the steps may be re-ordered in part or in whole and the steps may be modified, supplemented, or omitted as appropriate. Also, the embedded system 10 and the processor 12 may use various well known algorithms and software applications to implement the processing steps and substeps.

Claims

1. A method of testing the memory of an embedded system, comprising performing a check of a portion of the memory as a background task during the normal run operation of the embedded system and repeating the performing step for a different portion of the memory until the entire memory is checked.

2. The method of claim 1 , wherein performing a check of a portion of the memory as a background task comprises performing a check of a respective portion of the memory during system idle time.

3. The method of claim 1 , wherein the portions of the memory being checked are a preconfsgured size that does not have a negative impact on the normal run operation.

4. The method of claim 1 , wherein the portions of the memory being checked are configurable.

5. The method of claim 4, wherein a size of a respective portion of the memory being checked is configured based on system idle time.

6. The method of claim 1 , further comprising optimizing a size of a respective portion of the memory being checked that does not have a negative impact on the normal run operation.

7. The method of claim 1 , further comprising removing write- protection on a portion of the memory being checked for the duration of the respective performing step.

8. The method of claim 1 , further comprising carrying out a check of a first respective portion of the memory utilized by the embedded system for the performing and repeating steps by a second respective portion of the memory utilized by the embedded system for the performing and repeating steps.

9. The method of claim 1 , further comprising reporting the results of checking a respective portion of the memory to a safety handling function of the embedded system,

10. A method of continuous memory checking for embedded systems, comprising: a. triggering a memory test algorithm to evaluate the system memory of the system; b. cyclically executing the memory test algorithm during runtime of the system to evaluate a section of the system memory each cycle; and c. reporting results of memory test algorithm evaluations.

11. The method of claim 10, wherein the triggering step is

performed at the startup of the system.

12. The method of claim 10, wherein the triggering step is

performed during the run-time of the system.

13. The method of claim 10, wherein the triggering step is

performed at the startup of the system and the executing step is performed during the run-time of the system.

14. The method of claim 12, wherein the triggering step is not included in a startup bootline sequence,

15. The method of claim 10, wherein the memory test algorithm comprises a progressive memory test.

16. The method of claim 15, wherein the progressive memory test comprises testing data lines, address lines, and a memory chip of the system.

17. The method of claim 10, wherein the cyclically executing step is performed during system idle time in the run-time of the system.

18. The method of claim 10, wherein the cyclically executing step comprises configuring the size of a respective section of the system memory being evaluated each cycle.

19. The method of claim 17, wherein the cyclically executing step comprises determining an optimal size of a respective section of the system memory being evaluated in a respective cycle so there is no negative impact on the normal performance of the system during the run-time of the system.

20. The method of claim 10, wherein the cyclically executing step comprises removing write-protection on a respective section of the system memory being evaluated for the duration of executing the memory test algorithm to evaluate said respective section.

21. The method of claim 10, wherein the cyclically executing step comprises executing the memory test algorithm in ping-pong fashion between two sections of the memory utilized by the memory test algorithm so as to evaluate the memory utilized by the memory test algorithm,

22. The method of claim 10, wherein the reporting step

comprises interacting with a safety handling function of the system to manage the results of memory test algorithm evaluations.

23. A method of testing the memory of a computer-based

system, comprising performing a check of the memory as a background task during the normal run operation of the system, the work load of memory checking being distributed over time of the normal run operation.

24. A computer-based system, comprising:

a. a system memory thai is adapted to store various algorithms and software; and

b. a processor that is adapted to execute the stored

algorithms and software and associated tasks and to perform a test of the system memory as a background task during normal run operation of the system, the work load of memory testing being distributed over time of the normal run operation.