A method and system for startup status perception and fault diagnosis in embedded systems

Abstract

This invention discloses a startup state perception and fault diagnosis method and system for embedded systems, applicable to embedded architectures including a first processor and a second processor. The method includes: a startup state perception step—the second processor maintains a two-stage state machine; in the first stage, it sends a power-on heartbeat frame in a first cycle and waits for confirmation; upon receiving confirmation, it switches to the second stage and sends a life heartbeat frame in a second cycle; a fault diagnosis step—when the second processor starts, it reads and saves the reset cause register value, parses and determines the reset type, and encodes it in the power-on heartbeat frame for transmission. This invention accurately locates startup faults to three intervals through firmware-level two-stage semantic differentiation; it achieves non-intrusive remote reset cause tracing by encoding the reset register content into the heartbeat payload; and it improves reliability under high load through a heartbeat priority guarantee mechanism. This invention enables remote fault diagnosis without a JTAG debugger, significantly reducing maintenance costs, and is suitable for dual-processor devices such as industrial IoT gateways.

Description

Technical Field

[0001] This invention relates to the field of embedded system firmware design technology, and more specifically, to a method and system for accurately sensing the startup state of the second processor and tracing the cause of faults in a heterogeneous multiprocessor architecture that includes a first processor and a second processor. Background Technology

[0002] Industrial Internet of Things (IoT) gateways, smart controllers, and other products widely employ a dual-processor architecture of "main CPU + auxiliary MCU." The MCU is responsible for real-time data acquisition and control, while the main CPU handles complex business logic such as the protocol stack and cloud communication. In practical engineering applications, the main CPU faces the following technical challenges in sensing the startup status of the MCU: First, the MCU's initialization state is opaque. It takes hundreds of milliseconds to several seconds for the MCU to go from power-on to all peripherals being ready. During this time, any failure in the initialization process (such as I²C or SPI communication) can cause the MCU to enter an abnormal, frozen state. However, the main CPU cannot distinguish between these two fundamentally different states: "MCU initialization not yet complete" and "MCU initialization failed."

[0003] Secondly, the cause of the MCU reset is untraceable. MCUs are typically configured with an independent watchdog timer (IWDG), which triggers a reset when the firmware enters an infinite loop or a task is suspended. In traditional solutions, the main CPU cannot know whether the MCU's last restart was due to normal power-on, watchdog timeout, or software reset, making it difficult to reproduce and locate the fault in the field.

[0004] Finally, existing heartbeat protocols have obvious limitations. Existing industrial heartbeat protocols (such as Modbus heartbeat polling) are all single-stage designs, only able to express "online / offline" states, and unable to distinguish the internal startup phase of the device. Existing patents (such as US20190140908A1 and US20200162434A1) focus on network layer or application layer heartbeats, without addressing MCU firmware-level startup status reporting mechanisms, let alone technical solutions for encoding the contents of the hardware reset register into the heartbeat payload. Summary of the Invention

[0005] The present invention aims to solve the problems existing in the prior art and provides a two-stage start heartbeat protocol and a fault diagnosis method based on reset reason coding.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A two-phase startup heartbeat protocol and fault diagnosis method for an embedded system, the embedded system including a first processor and a second processor, characterized by comprising the following steps: Initiating State Awareness Steps: The second processor firmware maintains a state machine including a first-stage flag and a second-stage flag. In the first stage, after completing basic initialization, the second processor sends a power-on heartbeat frame containing the first-stage flag to the first processor at a first cycle and waits for an acknowledgment frame from the first processor. In response to receiving the acknowledgment frame, the second processor switches the state machine to the second stage and sends a life heartbeat frame containing the second-stage flag to the first processor at a second cycle longer than the first cycle.

[0007] Fault diagnosis steps: Upon startup, the second processor reads and saves the original value of the reset cause register before clearing any reset flags. Then, it parses the saved original value of the reset cause register to determine the reset type for this startup. Finally, it includes the determined reset type code in the power-on heartbeat frame and sends it to the first processor.

[0008] Furthermore, the power-on heartbeat frame and the vital heartbeat frame adopt a unified frame format, are identified by the same command type field, and are distinguished from the first stage and the second stage by the values ​​of the confirmation field and the payload data field; wherein, the power-on heartbeat frame is a request-response type frame, and the vital heartbeat frame is a one-way notification type frame.

[0009] Furthermore, the parsing steps of the reset reason register include: scanning bit by bit from the most significant bit to the least significant bit of the register, determining the reset type corresponding to the first detected set flag as the reset type of this startup; if all flag bits are not set, it is determined to be a normal power-on reset.

[0010] Furthermore, the first processor diagnoses the fault type of the second processor by monitoring the reception of the power-on heartbeat frame and the life heartbeat frame: if the power-on heartbeat frame is not received, it is determined to be an initialization fault before the first stage; if the power-on heartbeat frame is received but the life heartbeat frame is not received within the expected time, it is determined to be a peripheral initialization fault between the first stage and the second stage; if the life heartbeat frame is not received continuously, it is determined to be a business logic fault caused by a watchdog reset based on the reset type code most recently reported by the second processor.

[0011] Furthermore, the second processor maintains a dedicated heartbeat transmission queue that is physically isolated from the regular data queue, for transmitting the power-on heartbeat frame and the vital heartbeat frame; in data transmission scheduling, the dequeue priority of the dedicated heartbeat transmission queue is higher than that of the regular data queue.

[0012] Furthermore, the reset types include, but are not limited to: low-power reset, window watchdog reset, independent watchdog reset, software reset, power-down / undervoltage reset, pin / power-on reset, option byte load reset, and normal power-on reset.

[0013] Furthermore, in the first stage, after receiving the power-on heartbeat frame, the first processor replies with the confirmation frame to the second processor, and the confirmation frame is used to trigger the second processor to switch from the first stage to the second stage.

[0014] Furthermore, the first processor is a host central processing unit that runs an operating system; the second processor is an auxiliary microcontroller that runs a real-time operating system to drive real-time peripherals.

[0015] Furthermore, the payload of the life heartbeat frame further includes runtime health indicators of the second processor, including the remaining amount of the real-time operating system task stack and the remaining amount of heap memory.

[0016] The present invention also provides an embedded system, including a first processor and a second processor. The second processor includes a memory and at least one processor. The memory stores a computer program. When the computer program is executed by the at least one processor, the second processor performs the steps of any of the above methods. The first processor is used to receive and parse heartbeat frames sent by the second processor to realize the perception of the startup state of the second processor and fault diagnosis.

[0017] Compared with the prior art, the present invention has the following beneficial effects: Firmware-level two-stage semantic differentiation: The MCU startup state is accurately divided into three fault intervals: "stuck before Phase 1", "stuck between Phase 1 and Phase 2", and "stuck after Phase 2", which significantly improves the accuracy of fault location.

[0018] Non-intrusive reset cause tracing: By encoding the contents of the reset register into the heartbeat payload, remote reset cause tracing can be achieved without a JTAG debugger, reducing operation and maintenance costs.

[0019] Heartbeat priority guarantee: The dedicated heartbeat queue is physically isolated from the regular data queue and has the highest sending priority, ensuring heartbeat reliability under high load.

[0020] Intelligent fault diagnosis and self-healing: The host CPU can automatically determine the fault and trigger a remote restart by monitoring the missing heartbeat phase mode, thus enabling the device to self-heal.

[0021] Strong backward compatibility: The two-stage frame reuses the same command field, requiring minimal changes to the existing protocol parsing logic, which facilitates firmware upgrades and deployments. Attached Figure Description

[0022] Figure 1 This is a system architecture block diagram of an embodiment of the present invention.

[0023] Figure 2 This is a state transition diagram of the two-stage heartbeat protocol according to an embodiment of the present invention.

[0024] Figure 3 This is a flowchart illustrating the reset cause analysis in an embodiment of the present invention. Detailed Implementation

[0025] 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. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0026] System Architecture like Figure 1 As shown, in this embodiment, the embedded system consists of a host CPU running the Linux operating system (as the first processor) and an MCU (model STM32G0B0) running the FreeRTOS real-time operating system (as the second processor), interconnected via a USART1 serial bus. The MCU side includes a two-stage heartbeat state machine, a dedicated heartbeat transmission queue, a reset reason parsing module, and a peripheral driver layer; the host CPU side includes a heartbeat monitoring module, a protocol parsing layer, and an application layer.

[0027] The embedded system employs the startup status perception based on a two-stage heartbeat protocol and the fault diagnosis method based on reset reason coding described in this invention.

[0028] I. Startup State Awareness Based on Two-Phase Heartbeat Protocol like Figure 2 As shown, the specific steps in this embodiment are as follows: Step 1: The MCU firmware maintains the following three static state variables: g_heartbeat_period: The current heartbeat sending period, with an initial value of 1 second; g_timeout_flag: Heartbeat timeout trigger flag, boolean; check_ack_poweron_heartbeat: Stage flag, false indicates the first stage (powered heartbeat), true indicates the second stage (vital heartbeat), the initial value is false.

[0029] Step 2 (First Stage – Power-On Heartbeat): After the MCU completes basic peripheral initialization and the FreeRTOS scheduler starts, the main loop periodically calls the heartbeat task. When check_ack_poweron_heartbeat is false, a function is called every second to generate a power-on heartbeat frame and enqueue it into a dedicated heartbeat queue. The frame parameters are: CMD=0xFE, ACK=0x02 (request-response type), payload data[0]=0x01. The sending task prioritizes dequeuing the heartbeat frame in the scheduler and sends it to the host CPU via USART1.

[0030] Step 3 (Stage Switching): After receiving the power-on heartbeat frame, the host CPU recognizes the semantics of ACK=0x02 and replies with an acknowledgment frame (CMD=0xFE, ACK=0x03, data[0]=0x01). After the MCU's receiving task parses the acknowledgment frame, it calls the state switching function: sets check_ack_poweron_heartbeat to true, updates the heartbeat cycle to 3 seconds, and resets the timing start point.

[0031] Step 4 (Second Stage – Heartbeat): When check_ack_poweron_heartbeat is true, a function is called every 3 seconds to generate and send a heartbeat frame. The frame parameters are: CMD=0xFE, ACK=0x01 (one-way notification type), payload data[0]=0x02. The host CPU only records the timestamp and does not need to respond, continuously confirming the MCU's survival.

[0032] The key differences between the two-stage frames are shown in the table below:

[0033] Step 5 (Frame Format): As shown Figure 3 As shown, all heartbeat frames follow a uniform frame format: [Magic(2B): 0xE7,0x00] [PayloadLen(2B)][Version(1B): 0x01] [ACK(1B)][CMD(1B): 0xFE] [DataLen(2B)][Data(NB)] [CRC32(4B)] The CRC32 covers the data from the Version field to the end of the Data field. Heartbeat frames are transmitted through a separate dedicated heartbeat queue (capacity 8 frames, maximum 32 bytes per frame), and are dequeued from the regular data queue during transmission scheduling.

[0034] II. Fault Diagnosis Based on Reset Cause Coding like Figure 3 As shown, the specific steps in this embodiment are as follows: Step 1 (Register Read): Before performing any HAL initialization, the MCU's main() function reads the RCC control and status register (RCC->CSR) using direct register access and saves it to a global variable. g_rcc_csr = READ_REG(RCC->CSR); LL_RCC_ClearResetFlags(); This operation must be completed before clearing the reset flags in order to capture the original flag bits left over from the last reset.

[0035] Step 2 (Reset Reason Analysis): The analysis function scans the stored register value bit by bit from the most significant bit (bit 31) to the least significant bit, and immediately returns the corresponding reset type after finding the first set flag. The identified reset types are shown in the table below:

[0036] Step 3 (Payload Encoding): The payload of the powered-on heartbeat frame is expanded to 2 bytes: data[0] = 0x01 (first stage identifier) data[1] = boot_reason->id (reset reason enumeration value, 0x00~0x09) The host CPU directly reads the reset type from data[1], records it to the local log or reports it to the cloud, and can trace the cause of each abnormal restart of the MCU without the need for the engineer to connect the JTAG debugger on site.

[0037] Fault diagnosis logic The host CPU's heartbeat monitoring module continuously monitors the reception of heartbeat frames: If no power-on heartbeat frame is received within the predetermined time, the MCU is determined to be in a serious fault before the first stage (such as clock or UART initialization failure), and a remote reset command is triggered. If a power-on heartbeat frame is successfully received (Phase 1 appears), but no subsequent life heartbeat frame is received within the timeout threshold (Phase 2 is absent), it is determined that the MCU has experienced a peripheral initialization failure between Phase 1 and Phase 2. If vital heartbeat frames are continuously lost during normal operation, the independent watchdog timer is determined to be reset due to a business logic deadlock, based on the most recently reported reset type code (such as IWDGRS_TF).

[0038] Extension of preferred embodiments In other preferred embodiments: 1. For MCUs with more abundant resources, the complete 32-bit RCC->CSR register value (instead of just the enumeration value) can be appended as 4 bytes to the end of the power-on heartbeat frame payload, preserving all the original flag information and supporting scenarios where multiple reset flags can be detected simultaneously.

[0039] 2. The payload of the second-stage life heartbeat can be expanded to include runtime health indicators such as the remaining amount of FreeRTOS task stack and the remaining amount of heap memory, so as to realize preventive monitoring.

[0040] 3. The method of the present invention can also be used in embedded devices connected via CAN bus or RS-485 Modbus. The two-stage heartbeat semantics can be mapped to the function code and data field of the corresponding protocol, and has good protocol portability.

[0041] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. A two-phase startup heartbeat protocol and fault diagnosis method for an embedded system, the embedded system comprising a first processor and a second processor, characterized in that, Includes the following steps: Steps to initiate state awareness: The second processor firmware maintenance includes a state machine with first-stage flags and second-stage flags; Phase 1: After the second processor completes basic initialization, it sends a power-on heartbeat frame containing the Phase 1 identifier to the first processor in a first cycle, and waits for an acknowledgment frame from the first processor. In response to receiving the confirmation frame, the second processor switches the state machine to the second stage and sends a vital heartbeat frame containing the second stage identifier to the first processor at a second period longer than the first period. Fault diagnosis steps: Upon startup, the second processor reads and saves the original value of the reset cause register before clearing any reset flags; Parse the original value of the saved reset reason register to determine the reset type of this startup; The determined reset type is encoded and sent to the first processor in the power-on heartbeat frame.

2. The method according to claim 1, characterized in that, The power-on heartbeat frame and the vital heartbeat frame adopt a unified frame format, are identified by the same command type field, and are distinguished from the first stage and the second stage by the values ​​of the confirmation field and the payload data field; wherein, the power-on heartbeat frame is a request-response type frame, and the vital heartbeat frame is a one-way notification type frame.

3. The method according to claim 1, characterized in that, The parsing steps of the reset reason register further include: scanning bit by bit from the most significant bit to the least significant bit of the register, determining the reset type corresponding to the first detected set flag as the reset type of this startup; if all flag bits are not set, it is determined to be a normal power-on reset.

4. The method according to claim 1, characterized in that, The first processor diagnoses the fault type of the second processor by monitoring the reception of the power-on heartbeat frame and the vital heartbeat frame. If the power-on heartbeat frame is not received, it is determined to be an initialization failure before the first stage; If the power-on heartbeat frame is received but the life heartbeat frame is not received within the expected time, it is determined to be a peripheral initialization failure between the first stage and the second stage. If the life heartbeat frame is not received continuously, the business logic failure is determined to be caused by a watchdog reset based on the reset type code most recently reported by the second processor.

5. The method according to claim 1, characterized in that, The second processor maintains a dedicated heartbeat transmission queue that is physically isolated from the regular data queue, used to transmit the power-on heartbeat frame and the vital heartbeat frame; in data transmission scheduling, the dequeue priority of the dedicated heartbeat transmission queue is higher than that of the regular data queue.

6. The method according to claim 1, characterized in that, The reset types include, but are not limited to: low-power reset, window watchdog reset, independent watchdog reset, software reset, power-down / undervoltage reset, pin / power-on reset, option byte load reset, and normal power-on reset.

7. The method according to claim 1, characterized in that, In the first stage, after receiving the power-on heartbeat frame, the first processor replies with the acknowledgment frame to the second processor. The acknowledgment frame is used to trigger the second processor to switch from the first stage to the second stage.

8. The method according to claim 1, characterized in that, The first processor is a host central processing unit that runs an operating system; the second processor is an auxiliary microcontroller that runs a real-time operating system and is used to drive real-time peripherals.

9. The method according to claim 1, characterized in that, The payload of the life heartbeat frame further includes runtime health metrics of the second processor, including the remaining amount of the real-time operating system task stack and the remaining amount of heap memory.

10. An embedded system, characterized in that, The method includes a first processor and a second processor. The second processor includes a memory and at least one processor. The memory stores a computer program. When the computer program is executed by the at least one processor, it causes the second processor to perform the steps of the method according to any one of claims 1 to 9. The first processor is used to receive and parse heartbeat frames sent by the second processor to realize the perception of the startup state of the second processor and fault diagnosis.

Images