CN117762705A - System for exporting debugging data - Google Patents

Abstract

The embodiment of the application provides a system for exporting debugging data, which can export the debugging data when a screen-fixing type crash scene appears, so that the analysis of the reasons for the screen-fixing type crash is facilitated. The system for exporting debugging data comprises: the embedded device is in fixed screen abnormality, and the external device is in communication connection with the embedded device; the embedded device is used for responding to the reset operation from the reset key and controlling the embedded device to enter a debug data export mode; the external device is used for sending a debug data export request to the embedded device after entering the export mode; the embedded device is further used for receiving and responding to the debugging data export request within a preset duration and sending the debugging data to the external device.

Description

System for exporting debugging data

[ field of technology ]

The embodiment of the application relates to the technical field of embedded equipment, in particular to a system for exporting debugging data.

[ background Art ]

At present, when the embedded device works, a crash may occur, for example, the crash type includes an active trigger type, a dead loop type, an abnormal type and a fixed screen type, and at this time, debug data in the embedded device needs to be exported so that a cause of the crash can be analyzed according to the debug data. For the dead scene of the active triggering type, the dead loop type and the abnormal type, the specific dead type is identified through a software mechanism, and the debug data is exported, but when the dead scene of the screen fixing type appears, the software program fails, so that the debug data cannot be exported by means of the software mechanism.

[ invention ]

The embodiment of the application provides a system for exporting debugging data, which can export the debugging data when a screen-fixing type crash scene appears, so that the analysis of the reasons for the screen-fixing type crash is facilitated.

Embodiments of the present specification provide a system for exporting debug data, the system comprising: the embedded equipment is in fixed screen abnormality, and the external equipment is in communication connection with the embedded equipment; wherein,

the embedded device is used for responding to the reset operation from the reset key and controlling the embedded device to enter the export mode of the debug data;

the external device is used for sending a debug data export request to the embedded device after entering the export mode;

the embedded device is further configured to receive and respond to the debug data export request within a preset duration, and send the debug data to the external device.

In this embodiment of the present invention, the embedded device may consider that the embedded device is configured with a reset key, and when the embedded device has a screen-fixing crash scene, in the case that an internal software program of the embedded device fails, the embedded device may be triggered by using the configured reset key to enter a export mode capable of exporting debug data, so that the debug data is exported to an external device, that is, debug data in the screen-fixing crash scene is exported by using a software and hardware combination mode, so as to analyze the cause of the screen-fixing crash.

Optionally, the embedded device is further configured to store the debug data to an external storage medium in the embedded device when the debug data export request is not received within the preset time period.

In this embodiment of the present application, if the embedded device does not receive a request message of the external device for the debug data for a long time after entering the export mode of the debug data, the external device may be considered as abnormal communication with the external device, and the debug data may be stored in an external storage medium configured by the embedded device itself at this time.

Optionally, the embedded device includes: the power management module is provided with the reset key and the mark register, the processor is provided with the buffer and the memory, wherein the power management module supplies power to the processor through a first path and supplies power to the memory through a second path, the power management module is in communication connection with the processor, and the processor is in communication connection with the memory;

the power management module is used for responding to the reset operation from the reset key, sending a first reset signal to the processor, enabling the buffer not to be powered down, and setting the flag register;

the processor is used for responding to the first reset signal, controlling the kernel to reset and responding to the buffer non-power-down signal, and controlling the buffer non-power-down;

the processor is further configured to obtain a flag register state of the flag register after the kernel is reset; and if the flag register state is determined to represent that the flag register is set, controlling the buffer to synchronize the stored temporary data to the memory, wherein the persistent data in the memory and the temporary data together form the debugging data in the export mode.

In this embodiment, the embedded device may be considered to include a power management module provided with a reset key and a flag register, a processor provided with a buffer, and a memory, where when the reset key in the power management module is pressed, the power management module may send two signals to the processor, the first signal is a first reset signal, used for resetting a kernel of the processor, and the second signal is a buffer without a power-down signal, used for enabling the kernel of the processor to be powered down in a resetting process, so that temporary data in the buffer may not be lost, and because the power management module supplies power to the memory separately, persistent data in the memory may not be lost in the kernel resetting process of the processor; meanwhile, the power management module also carries out setting processing on the self flag register so as to control temporary data in the self buffer memory to be synchronized into the memory according to the set state of the identification register after the processor core is reset, namely the temporary data and the original persistent data in the memory form exportable debugging data together.

Optionally, the first reset signal is at a low level, and the buffer does not power down the signal at a high level.

In this embodiment of the present application, when the first reset signal is at a low level, the processor core is triggered to be reset, and when the buffer does not power down to a high level, the buffer in the triggering processor may still remain unchanged, so as to avoid data loss.

Optionally, the buffer non-power down signal is an L1 reset disable signal.

In the embodiment of the application, the buffer non-power-down signal is the existing L1 reset disable signal in the power management module, namely, when the processor core is reset, the buffer non-power-down characteristic is utilized by the existing L1 reset disable signal, and the temporary data in the buffer can be prevented from being lost without improving the hardware of the power management module, so that the temporary data in the buffer can be exported conveniently.

Optionally, the processor is in communication connection with the external device, and is further configured to receive and respond to the debug data export request within the preset duration, and send an export instruction to the memory;

and the memory is used for responding to the export instruction and sending the debugging data to the external equipment.

In this embodiment of the present application, after temporary data from a buffer and own persistent data are stored in a memory at the same time, if a processor receives a debug data export request of an external device within a preset duration, the processor may control the memory to send debug data (including the temporary data and the persistent data) to the external device, so as to export the debug data to the external device.

Optionally, the processor is further configured to store the debug data to the external storage medium when the debug data export request is not received within the preset time period.

In the embodiment of the application, after temporary data from the buffer and self-persistent data are stored in the memory at the same time, if the processor does not receive a debug data export request of the external device for a long time, the processor can be considered to have communication abnormality between the current processor and the external device, so that the memory can be controlled to store the debug data to the external storage medium, and the purpose of exporting the debug data to the embedded device is achieved.

Optionally, the processor is further configured to send a second reset signal to the power management module when determining that the debug data is exported;

the power management module is further configured to reset the flag register in response to the second reset signal.

In the embodiment of the application, after the debug data is exported, the processor can control the set flag register in the power management module to reset, so that the debug data export mode is still entered when the debug data is not exported in the subsequent process.

Optionally, the power management module is a power management integrated circuit.

In this embodiment of the present application, the power management module is a power management integrated circuit, that is, if any embedded device configured with the power management integrated circuit, the characteristics of the power management integrated circuit may be utilized, and debug data may be derived when a screen-fixing crash scene occurs.

Optionally, the external storage medium is a micro SD memory card, a mobile hard disk, or a U-disk.

In the embodiment of the application, when the debug data cannot be exported to the external device, the debug data can be stored in the micro SD memory card, the mobile hard disk or the USB flash disk, and the like, so that the purpose of exporting the debug data is achieved.

Optionally, the buffer is a static random access memory, and the memory is a dynamic random access memory.

In this embodiment, the buffer for storing temporary data uses a static random access memory, and the memory for storing persistent data is a dynamic random access memory.

[ description of the drawings ]

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present specification, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a crash type classification provided in an embodiment of the present application;

fig. 2 is a schematic diagram of exporting debug data in a dead-loop crash scenario provided in an embodiment of the present application;

FIG. 3 is a schematic diagram of a system for exporting debug data according to an embodiment of the present application;

fig. 4 is a schematic internal structure of an embedded device according to an embodiment of the present application;

fig. 5 is an overall flowchart of exporting debug data according to an embodiment of the present application.

[ detailed description ] of the invention

For a better understanding of the technical solutions of the present specification, the following detailed description of the embodiments of the present application is given with reference to the accompanying drawings.

It should be understood that the described embodiments are only some, but not all, of the embodiments of the present description. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present disclosure.

The terminology used in the embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

Currently, embedded devices are widely used in various fields, for example, industrial control field, smart home field, automobile field, consumer electronics field, communication field, etc. During operation of the embedded device, a problem of dead halt may occur due to various reasons.

Please refer to fig. 1, which is a schematic diagram of a crash type according to an embodiment of the present application. As shown in fig. 1, the crash type is mainly classified into four types.

The first is an active trigger type, i.e. a crash situation actively triggered by a user or a program, for example, when the user performs a specific operation or the program invokes a specific function, the system crashes.

The second is the dead loop class, i.e., the dead-time condition due to the occurrence of a dead loop in the program. Dead loop class crashes are further divided into interrupt dead loops (typically, a computer system uses interrupts to respond to external events or process specific tasks, but if an interrupt handler itself experiences dead loops, the system falls into endless loops, other interrupts or events cannot be processed, and finally system crashes or crashes are caused, the interrupt dead loops may be caused by errors, deadlocks, resource contention or other programming errors in the interrupt handler), critical section dead loops (refer to the situation that a thread cannot exit after entering a critical section for some reason, and the program cannot continue to execute.

The third is an exception class, i.e., a crash caused by an exception condition occurring during program execution. Exception-like crashes are further divided into undefined exceptions (meaning that undefined behavior or results occur when the program is running, typically due to programming errors, uninitialized variables, memory access out-of-bounds, etc.), program behavior may be unpredictable in this case, potentially resulting in program crashes, dead loops, or erroneous results), data-capable exceptions (meaning that data-capable exceptions are triggered when the program attempts to access an invalid memory address or attempts to perform an unaligned memory access, such exceptions are typically due to programming errors, memory corruption, or operating system permission issues), and prefetch-capable exceptions (meaning that a prefetch-capable exception is triggered when the program attempts to execute an instruction if the processor fails to prefetch an instruction or an invalid prefetch operation occurs, typically due to instructions accessing an inexistent memory address, access permission error, etc.)

The fourth is a fixed screen type, that is, the image or interface on the screen suddenly stops updating, and presents a fixed picture, so that the user cannot operate the system through an input device (such as a keyboard, a mouse, a touch screen, etc.). Such a crash condition is typically caused by a serious error or malfunction in system software or hardware.

Currently, for the three previous crash scenarios, the debug data is derived mainly by means of a software mechanism, so that the crash cause can be analyzed according to the debug data. For example, for an active triggering type crash scene, debugging data can be triggered and called by calling a corresponding triggering function through a program; for abnormal crash scenes, the debugging data can be exported by jumping to a trigger function in the interrupt vector table; referring to fig. 2, for a dead-loop-like dead-end scenario, a stage start timer may be initialized and a loading value of a low-priority thread reset timer may be created, and if the timer is not reset before timeout, it is considered that the embedded device does not release system resources in other threads or interrupts, resulting in starvation of the low-priority thread, triggering a FIQ interrupt to derive debug data; if the timer is reset before the timeout, the embedded device is considered to operate normally. However, in a fixed screen crash scenario, the software program of the embedded device fails, and thus cannot rely on the software mechanism to derive debug data.

In view of this, the embodiment of the application provides a system for exporting debug data, in the system, hardware is used to trigger embedded equipment to enter a debug data export mode, and then software is used to export the debug data, that is, the debug data in the screen-fixing crash scene is exported by using a software-hardware combination mode, so as to analyze the cause of the screen-fixing crash.

The following describes the technical scheme provided by the embodiment of the application with reference to the accompanying drawings.

Referring to fig. 3, an architecture diagram of a system for exporting debug data according to an embodiment of the present application is provided. As shown in fig. 3, the system for exporting debug data includes an embedded device 10 in a fixed screen state, and an external device 20 in communication connection with the embedded device 10; wherein,

the embedded device 10 is used for responding to the reset operation from the reset key and controlling the embedded device to enter a debug data export mode;

the external device 20 is configured to send a debug data export request to the embedded device after entering the export mode;

the embedded device 10 is further configured to receive and respond to the debug data export request within a preset time period, and send the debug data to the external device 20.

In this embodiment of the present application, the embedded device 10 may consider that a reset key is configured on itself, and when a screen-fixing crash scene occurs in the embedded device 10, that is, when an internal software program of the embedded device fails, the software program in the embedded device 10 may be triggered to be reset by using the self-configured hardware, that is, the configured reset key, that is, the software program is triggered to restore to normal, and meanwhile, debug data is ensured not to be lost in the process of resetting the software program, so that an export mode capable of exporting debug data is entered. For example, the embedded device 10 is triggered to enter the export mode of the debug data by a long press of a reset key. Illustratively, pressing the reset key of the embedded device 10 for 3s, 4s, 5s, 6s, or 7s or more may be regarded as a long-press operation of the reset key. At this time, if the embedded device 10 that resumes the software program function receives the debug data request from the external device 20, the debug data may be exported to the external device 20, that is, the debug data in the screen-fixing crash scene is exported by using the combination of software and hardware, so as to analyze the cause of the screen-fixing crash.

It should be appreciated that in the above embodiment, debug data may include stack call information (meaning that during program execution, information about function calls and returns is stored in a stack, mainly including the return address of a function: address of the next instruction to be executed after calling the function, parameters of a function: storing parameter values transferred to a function, and local variables of a function: storing values of local variables defined inside a function), system thread state (mainly including running state: indicating whether a thread is currently running, ready state: indicating that a thread is ready to run, waiting for system dispatch execution, blocking state: indicating that a thread is waiting for an event to occur, such as waiting for I/O to complete, etc., suspending state: indicating that a thread has been suspended, suspending execution, thread priority: indicating priority of a thread in a system, determining the order in which a thread is scheduled, thread context: including information of a register state, stack pointer, stack, etc. of a thread for saving and restoring a scene when a thread is switched). Meanwhile, in the above embodiment, the external device 20 may be a personal computer (Personal Computer, PC), and the embedded device 10 and the external device 20 may communicate through a universal serial bus (Universal Serial Bus, USB) interface or a universal asynchronous receiver Transmitter (Universal Asynchronous Receiver/Transmitter, UART) interface, and the communication manner is not limited herein.

In some embodiments, there may be abnormal communication between the embedded device 10 and the external device 20, so that the debug data in the embedded device 10 cannot be normally exported to the external device 20, so in the embodiment of the application, when there is abnormal communication between the embedded device 10 and the external device 20, the debug data may be temporarily saved to the external storage medium, so as to achieve the purpose of exporting the debug data as well.

As a possible implementation manner, the embedded device 10 is further configured to store the debug data into the external storage medium in the embedded device 10 when the debug data export request from the external device 20 is not received within a preset period of time.

In this embodiment of the present application, since the external storage medium in the embedded device 10 is removable, saving the debug data to the external storage medium is equivalent to exporting the debug data.

In the above embodiment, the preset time period may be 10s, 20s or 30s, and the preset time period is not particularly limited here. The external storage medium may be a micro SD memory card (i.e. TF card), a mobile hard disk, or a U disk, and the external storage medium is not particularly limited herein.

The following describes in detail the entry of embedded device 10 into export mode of debug data by a long reset key press.

Fig. 4 is a schematic structural diagram of an embedded device according to an embodiment of the present application. As shown in fig. 3, the embedded device 10 includes: the power management module 101 is provided with a reset key and a flag register, the processor 102 is provided with a buffer, and the memory 103, wherein the power management module 101 supplies power to the processor 102 through a first path and supplies power to the memory 103 through a second path, the power management module 101 is in communication connection with the processor 102, and the processor 102 is in communication connection with the memory 103;

the power management module 101 is configured to send a first reset signal to the processor 102 in response to a reset operation from the reset key, and set the flag register without power down of the buffer;

the processor 102 is configured to control the core to reset in response to the first reset signal, and control the buffer to not power down in response to the buffer not power down signal;

the processor 102 is further configured to obtain a flag register state of the flag register after the kernel is reset; if it is determined that the flag register state flag register is set, the control buffer synchronizes the stored temporary data to the memory 103.

In this embodiment, when the embedded device 10 is in a screen-fixed crash scenario, a user may perform a long-press operation on a reset key in the power management module 101, so as to trigger the power management module 101 to send a first reset signal to the processor 102 and the buffer does not power down, for example, the first reset signal is at a low level, the buffer does not power down to be at a high level, and the level of the two signals is not particularly limited here. At the same time, the power management module 101 sets its flag register (i.e., sets the flag register value from 0 to 1). After the processor 102 receives the first reset signal and the buffer does not fail, on one hand, the kernel can be reset according to the first reset signal, and it should be understood that the problem of software program failure in the fixed screen state can be solved after the kernel is reset; on the other hand, according to the buffer not powering down, the buffer in the processor 102 may not be powered down when the kernel is reset, so that temporary data in the buffer (data in which the fixed screen reason occurs to the embedded device 10 is partially recorded) may not be lost, for example, the buffer may be a static random access memory (Static Random Access Memory, SRAM) mainly including a static RAM and a pseudo static random access memory (Pseudo Static Random Access Memory, PSRAM), and the type of the buffer included in the embedded device 10 is not particularly limited herein. Meanwhile, the power management module 101 supplies power to the memory 103 independently, so that the persistent data (the data of which the other part records the screen fixation reason of the embedded device 10) in the memory 103 cannot be lost in the kernel reset process of the processor 102. For example, the memory 103 may be a dynamic random access memory (Dynamic Random Access Memory, DRAM), mainly including synchronous dynamic random access memory (Synchronous Dynamic Random Access Memory, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate Synchronous Dynamic Random Access Memory, DDR SDRAM), low power consumption double data rate synchronous dynamic random access memory (Low Power Double Data Rate Synchronous Dynamic Random Access Memory, LPDDR SDRAM), and the specific type of memory 103 included in the embedded device 10 is not particularly limited herein.

On this basis, the core in the processor 102 can read the register state of the flag register in the power management module 101 at the time of reset. If processor 102 determines that the register state flag register is currently set (i.e., the flag register is set to a value of 1), indicating that the current user requirement is to export debug data, processor 102 may control the buffer to synchronize temporary data into memory 103, and the original persistent data in memory 103 and the temporary data from the buffer constitute exportable debug data.

It should be understood that, in the above embodiment, the power management module 101 may be a power management integrated circuit, so that in the process of resetting the core in the processor 102, the buffer without power down does not need to be powered down to be the L1 reset disable signal existing in the power management integrated circuit, so that the temporary data in the buffer is prevented from being lost without modifying the hardware of the power management module 101, and the purpose of deriving the temporary data in the buffer is achieved.

In some embodiments, after the kernel of the processor 102 is reset, the software failure problem may be considered to be solved, and at this time, the processor 102 may control the memory 103 to export the debug data to the external device according to the request of the external device 20.

As a possible implementation, the processor 102 may be communicatively connected to the external device 20, and if the processor 102 receives a debug data export request within a preset time period, the processor may send export instructions to the memory 103 in response to the debug data export request. After receiving the export instruction from processor 102, memory 103 may send debug data to external device 20 in response to the export instruction.

In some embodiments, there may be an abnormality in the communication connection between the processor 102 and the external device 20, for example, the connection between the processor 102 and the external device 20 is broken, or the processor 102 and the external device 20 are not connected, at this time, the processor 102 may save the debug data to an external storage medium, so as to achieve the purpose of exporting the debug data as well.

As a possible implementation manner, if the processor 102 does not receive the debug data export request from the external device 20 within a preset period of time, it is considered that there is a communication abnormality between the processor 102 and the external device 20, and the processor 102 is configured to save the debug data to the external storage medium. For example, processor 102 sends an export command to memory 103, where the export command carries the export location of the debug data (i.e. the export location is the external storage medium), and after receiving the export command, memory 103 exports the debug data to the external storage medium in response to the export command.

In some embodiments, after the debug data is exported, the flag register in the power management module 101 may be restored to the original state in order to avoid entering the export mode of the debug data when the debug data is not needed to be exported in a subsequent process.

As a possible implementation, the processor 102 is further configured to send a second reset signal to the power management module 101 after determining that the debug data is exported, i.e. exported to the external device 20 or exported to an external storage medium. After receiving the second reset signal, the power management module may respond to the second reset signal to reset the flag register (i.e., restore the value of the flag register from 1 to 0).

The flow of exporting debug data is described in detail below.

Referring to fig. 5, an overall flowchart of exporting debug data is provided in an embodiment of the present application. As shown in fig. 5, after the processor core is turned on, the PMIC configures the L1 reset disable signal to be high, and the processor reads the value of the flag register in the PMIC, so as to determine whether the temporary data in the buffer in the processor needs to be synchronized to the memory. If the flag register is not set to 1, it indicates that the embedded device has no screen-fixing and dead halt problem, and it is not necessary to synchronize temporary data of the buffer in the processor to the memory, and at the same time, continuously detect whether there is a reset operation based on a reset key from the user.

If a screen-fixed dead halt scene occurs, a user can perform long-time pressing operation on a reset key of the embedded equipment, so that the PMIC is triggered to send a low-level first reset signal and a high-level L1 reset inhibition signal to the processor, and a flag register is set. After the processor receives the first reset signal and the L1 reset inhibition signal, the kernel of the processor will reset based on the first reset signal, and the buffer in the processor will not reset based on the L1 reset inhibition signal, i.e. the buffer will not be powered down. After the processor core is started, the numerical value of the flag register in the PMIC is read again, so as to judge whether the temporary data in the buffer memory in the processor needs to be synchronized to the memory.

If the flag register is set to 1, it indicates that the temporary data of the buffer in the processor needs to be synchronized to the memory. After the synchronous operation is finished, further judging whether the processor receives a debugging data export request of the external equipment, if the processor receives the debugging data export request within a preset time length, responding to the debugging data export request, and sending the debugging data to the external equipment; if the debug data export request is not received within the preset time length, the debug data is stored in an external storage medium. After determining that the debug data is exported, the processor can control the flag register in the PMIC to reset, so that the process of exporting the debug data is still performed when the debug data is not needed to be exported in the subsequent process.

The foregoing description of the preferred embodiments is provided for the purpose of illustration only, and is not intended to limit the scope of the disclosure, since any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the disclosure are intended to be included within the scope of the disclosure.

Claims (11)

1. A system for exporting debug data, the system comprising: the embedded equipment is in fixed screen abnormality, and the external equipment is in communication connection with the embedded equipment; wherein,

the embedded device is used for responding to the reset operation from the reset key and controlling the embedded device to enter the export mode of the debug data;

the external device is used for sending a debug data export request to the embedded device after entering the export mode;

the embedded device is further configured to receive and respond to the debug data export request within a preset duration, and send the debug data to the external device.

2. The system of claim 1, wherein the embedded device is further configured to save the debug data to an external storage medium in the embedded device when the debug data export request is not received within a preset time period.

3. The system of claim 2, wherein the embedded device comprises: the power management module is provided with the reset key and the mark register, the processor is provided with the buffer and the memory, wherein the power management module supplies power to the processor through a first path and supplies power to the memory through a second path, the power management module is in communication connection with the processor, and the processor is in communication connection with the memory;

the power management module is used for responding to the reset operation from the reset key, sending a first reset signal to the processor, enabling the buffer not to be powered down, and setting the flag register;

the processor is used for responding to the reset signal, controlling the kernel to reset and responding to the buffer non-power-down signal, and controlling the buffer non-power-down;

the processor is further configured to obtain a flag register state of the flag register after the kernel is reset; and if the flag register state is determined to represent that the flag register is set, controlling the buffer to synchronize the stored temporary data to the memory, wherein the persistent data in the memory and the temporary data together form the debugging data in the export mode.

4. The system of claim 3, wherein the first reset signal is low and the buffer no-power-down signal is high.

5. The system of claim 3, wherein the buffer not-to-power signal is an L1 reset disable signal.

6. The system of any of claims 3-5, wherein the processor is communicatively coupled to the external device, the processor further configured to receive and respond to the debug data export request for the preset duration, and send export instructions to the memory;

and the memory is used for responding to the export instruction and sending the debugging data to the external equipment.

7. The system of claim 6, wherein the processor is further configured to save the debug data to the external storage medium when the debug data export request is not received within the preset time period.

8. The system of claim 7, wherein the processor is further configured to send a second reset signal to the power management module upon determining that the debug data is exported;

the power management module is further configured to reset the flag register in response to the second reset signal.

9. The system of claim 3 or 8, wherein the power management module is a power management integrated circuit.

10. The system of claim 2 or 7, wherein the external storage medium is a micro SD memory card, a removable hard disk, or a usb disk.

11. The system of claim 3, wherein the buffer is a static random access memory and the memory is a dynamic random access memory.