A method and system for recording logs of a bare kernel program of a relay protection device
By using shared memory communication and asynchronous log processing in a multi-core AMP architecture, the problem of excessively long logging time in bare-core programs is solved, achieving fast and secure log storage and meeting the high-efficiency log management requirements of relay protection devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-02-18
- Publication Date
- 2026-04-14
AI Technical Summary
In bare-core programs, logging consumes too much CPU time, which cannot meet the fast log storage requirements in abnormal situations in protection interrupt routines. Furthermore, bare-core programs do not support file systems, leading to problems such as untimely or volatile log storage.
The chip adopts a multi-core AMP architecture. The bare core and the system core communicate through shared memory. Non-interrupt programs use the printf interface to encode and output ASCII, while interrupt programs use the logmsg interface to put logs into a queue. Timed processing tasks encode and output the logs, and the system core writes the logs to the power-loss safe file system in text form.
It enables efficient logging under different execution latency requirements, reduces the execution time of interrupt programs, ensures that logs are not lost in the protection device, and meets the requirements of speed and security.
Smart Images

Figure CN114546680B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded storage technology, and more specifically to a method and system for recording bare-core program logs in a relay protection device. Background Technology
[0002] In relay protection devices, to ensure rapid operation, the protection program is typically run on a bare-metal kernel. Log storage usually requires transcoding the log content into ASCII and storing it as text within the file system. However, transcoding the log content into ASCII within the bare-metal program consumes a significant amount of CPU time, failing to meet the requirement of log storage in the event of an exception during the protection interrupt routine; furthermore, the bare-metal kernel itself does not support a file system.
[0003] Existing embedded system logs are typically stored in RAM or a file system. RAM storage is susceptible to loss due to power failure, while file systems suffer from the problem of logs not being saved or being saved too late when transmission is interrupted. For example, patent application CN201510690375.X uses caching to ensure continuous log storage, and then saves the logs to non-volatile memory via a communication interface and software. With an operating system, patent application CN201810479161.1 uses reserved memory to quickly save logs, avoiding log loss due to power outages. Patent application CN202011183299.0 sets levels for the log output module to enable log output to multiple destination output devices (including servers, serial ports, and USB), achieving real-time log output based on on-site needs, avoiding excessive caching while ensuring high-priority log processing speed. All of the above patents consider either log storage speed or non-volatility; both cannot be simultaneously achieved. In multi-core processors, embedded systems are typically composed of a system core and a bare core. In patent application CN200710181024.1, the system core is responsible for creating a shared queue and retrieving exception messages from the queue through polling. The bare core completes the acquisition, processing, and storage of exception signals. However, if this method is used in an interrupt routine, the execution speed of the interrupt routine will be affected due to the long log transcoding and storage time.
[0004] The existing log management technologies disclosed above primarily aim to balance storage speed and storage capacity. Power outage recovery is also a crucial consideration. When a processor only has bare cores, caching is insufficient to handle sudden anomalies. However, with an operating system, task management can periodically store logs in non-volatile memory, preventing log loss and irrecoverability after a power outage and restart. In multi-core processors, bare cores handle information processing and storage, while system cores handle shared memory creation and information retrieval. However, unlike anomaly information, log storage requires significant capacity and involves priority considerations. Therefore, the task allocation between the two cores described in patent application CN202011183299.0 is not suitable for log management. Summary of the Invention
[0005] The purpose of this invention is to provide a method for recording the bare core program log of a relay protection device, so as to solve the problem of recording the bare core program log of a relay protection device.
[0006] To achieve the above objectives, the present invention adopts the following technical solution:
[0007] A method for recording bare-core program logs in a relay protection device, wherein the relay protection device uses a multi-core AMP (Asymmetric Multi-Processing) architecture chip, in which the CPU core is divided into a bare core and a system core, and the bare core and the system core share memory. The bare-core program log recording steps include:
[0008] a. For non-interruptible program logging, the bare-core printf interface is used to convert the log content to ASCII, then put it into shared memory and print it out via serial port;
[0009] For interrupt routine logging, the log content is stored in a queue using the bare core's logmsg interface. A timed information processing task converts the log content in the queue to ASCII, then puts it into shared memory and prints it out via serial port.
[0010] b. The system kernel's log processing thread reads the log information in shared memory and writes the logs to the power-loss safe file system in text format.
[0011] In a preferred embodiment, the information processing task triggered by a timer performs ASCII encoding of the log content in the queue in the following manner:
[0012] After the timer triggers the information processing task, the log queue is processed. If the log queue is not empty, the log content in the queue is converted to ASCII, the converted content is placed in shared memory and printed out via serial port; if the log queue is empty, it waits for the next timer to trigger the information processing task.
[0013] As a preferred implementation, the information processing task performs ASCII encoding on the log content in the queue in a first-in-first-out manner.
[0014] As a preferred implementation, the system kernel uses a log processing thread to process log information in shared memory.
[0015] As a preferred implementation, the time synchronization method for bare-core program log recording is as follows:
[0016] After receiving the external IRIG-B signal, the FPGA chip triggers an external interrupt by pulling up the bare core GPIO pin to achieve time synchronization.
[0017] In a preferred embodiment, the method further includes synchronizing the log text written to the power-loss safe file system to non-volatile memory storage.
[0018] In a preferred embodiment, the log recording includes a runtime log and an exception log.
[0019] In a preferred embodiment, the operation log includes time, location, and detailed operation information; the exception log includes time, CPU register information, stack content, exception address, and exception type.
[0020] Another objective of this invention is to provide a bare-core program log recording system for a relay protection device, comprising a bare core, a system core, and shared memory, wherein an operating system is installed in the system core; the bare core and the system core communicate through the shared memory.
[0021] The bare kernel includes a printf interface and a logmsg interface. The printf interface is used to handle the logging of non-interrupt programs, convert the log content to ASCII, put it into shared memory, and print it out via serial port. The logmsg interface handles the logging of interrupt programs, puts the log content into a queue for storage, and a timed information processing task converts the log content in the queue to ASCII, puts it into shared memory, and prints it out via serial port.
[0022] The system core includes a log processing thread and a power-loss safe file system. The log processing thread reads log information from shared memory and writes the logs to the power-loss safe file system in text format.
[0023] As a preferred implementation, the information processing task performs ASCII encoding on the log content in the queue in a first-in-first-out manner.
[0024] This invention employs different recording methods for different logging processes based on the latency requirements of log recording. For non-interruptible programs in the bare kernel where the latency requirement for log recording is not high, the log content only needs to be transcoded into ASCII and placed in shared memory. The system kernel then writes the log content from shared memory into the power-loss safe file system TpsFs in text format, thus solving the problem of the bare kernel not supporting file systems. To support the requirement of minimizing the latency of log recording in protection interrupt programs, the process of "transcoding the log content into ASCII and placing it into shared memory" is executed in steps. First, the protection interrupt program only places the log content into a queue for storage. Then, the protection interrupt program can continue to execute its tasks. Afterward, a dedicated information processing task transcodes the data in the queue into ASCII and places it into shared memory in a FIFO (First-In, First-Out) manner. Since ASCII transcoding is not required in the protection interrupt program, the execution time of log recording is greatly reduced. The method and system of this invention can fully meet the requirements of relay protection devices to complete log recording under different execution latency requirements, improving the efficiency of log recording. Attached Figure Description
[0025] To more clearly illustrate the technical solution of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0026] Figure 1 This is a flowchart of bare-core program logging provided in a certain embodiment of the present invention.
[0027] Figure 2 This is a flowchart of the printf interface execution provided in a certain embodiment of the present invention.
[0028] Figure 3 This is a flowchart of the logmsg interface and information processing task execution provided in a certain embodiment of the present invention.
[0029] Figure 4 This is a flowchart of the information processing task execution provided in a certain embodiment of the present invention.
[0030] Figure 5 This is a flowchart of the t_log thread execution provided in a certain embodiment of the present invention.
[0031] Figure 6 This is a flowchart of bare kernel time synchronization provided in a certain embodiment of the present invention.
[0032] Figure 7 This is a diagram of a bare kernel log storage system provided in one embodiment of the present invention. Detailed Implementation
[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0034] It should be understood that the step numbers used in the text are for ease of description only and are not intended to limit the order in which the steps are performed.
[0035] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0036] The terms “comprising” and “including” indicate the presence of the described feature, whole, step, operation, element and / or component, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or collections thereof.
[0037] The term “and / or” refers to any combination of one or more of the associated listed items, as well as all possible combinations, and includes these combinations.
[0038] In this embodiment, the chip implementing the method uses a domestically produced quad-core Fuxi chip, namely CK-810-0, CK-810-1, and 2×CK-860. Among them, CK-810-0 and CK-810-1 run bare-core programs, and the 2×CK-860 dual-core runs the SylixOS operating system. The cores can communicate with each other through shared memory.
[0039] In one embodiment, the printf interface is called when logging is required in a non-interruptible program: void printf(const char* format,...); the execution flow of the printf interface is as follows. Figure 2 As shown, the printf interface converts the log content to ASCII encoding, then places it in shared memory and prints it via the serial port.
[0040] When logging is required in an interrupt routine, call the logmsg interface: void logmsg(const char* format, int a1, int a2, int a3, int a4, int a5, int a6);
[0041] LOGMSG log message queue data structure:
[0042]
[0043]
[0044] The execution flow of the logmsg interface is as follows: Figure 3 As shown, the logmsg interface stores log content into a queue.
[0045] In one embodiment, the information processing task is triggered periodically. Log information is retrieved from the log queue in a FIFO manner, printed serially, and then placed into shared memory. The execution flow of the information processing task is as follows: Figure 4 As shown. After the timer triggers the information processing task, the log queue is processed. If the log queue is not empty, the log content in the queue is converted to ASCII, the converted content is placed in shared memory and printed out via serial port; if the log queue is empty, it waits for the next timer to trigger the information processing task.
[0046] In one embodiment, the system kernel's t_log thread writes the log content in shared memory to the power-loss-safe file system Tpsfs in text format. The execution flow is as follows: Figure 5 As shown, the t_log thread starts running, and if there is unsaved log content in the shared content, it writes the log content as text to the power-loss safe file system.
[0047] In one embodiment, the time synchronization method in the bare-core log recording is implemented using an FPGA chip. The FPGA chip receives an external IRIG-B signal to achieve time synchronization. Simultaneously, the FPGA chip provides a precise synchronization interrupt signal to the bare core, achieving bare-core time synchronization. The time synchronization process is as follows: Figure 6 As shown. After receiving the IRIG-B signal, the FPGA triggers an external interrupt by pulling up the bare core GPIO pin, and the bare core completes time synchronization according to the second pulse signal provided by the FPGA.
[0048] In one embodiment, the bare kernel log storage system architecture is as follows: Figure 7As shown, it includes a bare kernel, a system kernel, and shared memory. The operating system is installed in the system kernel. The bare kernel and the system kernel communicate through shared memory. The bare kernel includes a printf interface and a logmsg interface. The printf interface is used to handle the logging of non-interruptible programs, converting the log content into ASCII, placing it in shared memory, and then printing it out via serial port. The logmsg interface handles the logging of interrupted programs, storing the log content in a queue. A timed information processing task converts the log content in the queue into ASCII, places it in shared memory, and then prints it out via serial port. The system kernel includes a log processing thread and a power-down-safe file system. The log processing thread reads the log information in shared memory, writes the log to the power-down-safe file system as text, and then synchronizes it to non-volatile memory.
[0049] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.
Claims
1. A method for recording the bare core program log of a relay protection device, characterized in that, The relay protection device uses a multi-core AMP architecture chip, in which the CPU core is divided into a bare core and a system core, which share memory. The bare core program log recording steps include: a. For non-interruptible program logging, the bare-core printf interface is used to convert the log content to ASCII, then put it into shared memory and print it out via serial port; For interrupt routine logging, the log content is stored in a queue using the bare core's logmsg interface. A timed information processing task converts the log content in the queue to ASCII, then puts it into shared memory and prints it out via serial port. b. The system kernel's log processing thread reads the log information in shared memory and writes the logs to the power-loss safe file system in text format.
2. The method according to claim 1, characterized in that, The method by which the timed information processing task performs ASCII encoding on the log content in the queue is as follows: After the timer triggers the information processing task, the log queue is processed. If the log queue is not empty, the log content in the queue is converted to ASCII, the converted content is put into shared memory and printed out via serial port. If the log queue is empty, wait for the next timer to trigger the information processing task.
3. The method according to claim 1 or 2, characterized in that, The information processing task will convert the log content in the queue to ASCII encoding in a first-in-first-out manner.
4. The method according to claim 1, characterized in that, The system kernel uses a log processing thread to process log information in shared memory.
5. The method according to claim 1, characterized in that, The time synchronization method for bare-core program logs is as follows: After receiving the external IRIG-B signal, the FPGA chip triggers an external interrupt by pulling up the bare core GPIO pin to achieve time synchronization.
6. The method according to claim 1, characterized in that, It also includes synchronizing log text written to the power-loss-safe file system to non-volatile memory storage.
7. The method according to claim 1, characterized in that, The log records include runtime logs and exception logs.
8. The method according to claim 7, characterized in that, The runtime log includes time, location, and detailed runtime information; the exception log includes time, CPU register information, stack trace, exception address, and exception type.
9. A bare-core program log recording system for a relay protection device, characterized in that, It includes a bare kernel, a system kernel, and shared memory, wherein the operating system is installed in the system kernel; the bare kernel and the system kernel communicate through shared memory; The bare kernel includes a printf interface and a logmsg interface. The printf interface is used to handle the logging of non-interrupt programs, convert the log content to ASCII, put it into shared memory, and print it out via serial port. The logmsg interface handles the logging of interrupt programs, puts the log content into a queue for storage, and a timed information processing task converts the log content in the queue to ASCII, puts it into shared memory, and prints it out via serial port. The system core includes a log processing thread and a power-loss safe file system. The log processing thread reads log information from shared memory and writes the logs to the power-loss safe file system in text format.
10. The log recording system according to claim 9, characterized in that, The information processing task will convert the log content in the queue to ASCII encoding in a first-in-first-out manner.
Citation Information
Patent Citations
An embedded system log collection device, recording system and method
CN105183628B
Log storage method and system of embedded system
CN108664655A
Embedded log management system and method
CN112306834A
Method and system for capturing and storing bare nucleus exception in multi-core processor
CN101174242A
Power-down protection method and device of android system
CN103186436A