CN113672428A

CN113672428A - SPARC platform-oriented embedded software exception autonomous processing method and device

Info

Publication number: CN113672428A
Application number: CN202111224391.1A
Authority: CN
Inventors: 麻恩泽
Original assignee: Beijing Forestry University
Current assignee: Beijing Forestry University
Priority date: 2021-10-21
Filing date: 2021-10-21
Publication date: 2021-11-19
Anticipated expiration: 2041-10-21
Also published as: CN113672428B

Abstract

The invention relates to an embedded software exception autonomous processing method and device for a SPARC platform, wherein the method comprises the following steps: determining a current partition in which the target software runs; judging whether the current partition is a partition in which a bottom layer public function operates; determining an alternative state conversion linked list; and judging whether the running partition corresponding to the alternative state conversion linked list comprises the current partition or not according to the running state partition table, wherein the jump condition indicated by the jump condition field corresponding to the alternative state conversion linked list can be met. The embedded software exception autonomous processing method and device for the SPARC platform, provided by the embodiment of the invention, realize autonomous processing of exceptions, and have small time delay; the occurrence of the condition of system service interruption is avoided; meanwhile, runtime information such as register groups, stack contents and the like is saved, and analysis and positioning of subsequent abnormal problems are facilitated.

Description

SPARC platform-oriented embedded software exception autonomous processing method and device

Technical Field

The invention relates to the field of embedded software, in particular to an embedded software exception autonomous processing method and device for an SPARC platform.

Background

SPARC is the mainstream processor architecture at present, and embedded software oriented to the SPARC platform may have an exception in the running process, which results in system reset or even continuous reset. Once this condition is not handled properly or timely, critical systems with high safety requirements for aerospace, automotive electronics, etc. may result in system failure or severe loss.

At present, the exception handling means for continuous reset of the embedded software for the SPARC platform mainly comprises manual operation for powering on again or switching to a backup device for running again. This approach has the following disadvantages: (1) when the equipment implanted into the SPARC platform is unmanned running equipment, an effective remote power-on and power-off means is needed to complete exception handling by manual assistance, and the independence is lacked; (2) the time delay for completing the power on/off operation of the system is large, and the continuity of the system operation is influenced by the untimely processing of the exception; (3) after the system is powered up again, some environment information during operation can be lost, which is not beneficial to the subsequent positioning and repairing of the abnormity; (4) the operation of the system to power back-off often causes interruption of system service, which is not allowed for some critical systems. Therefore, it is necessary to design an embedded software exception autonomous processing method and apparatus for SPARC platform based on the characteristics of SPARC platform, so as to solve the above problems.

Disclosure of Invention

In view of this, an object of the embodiments of the present invention is to provide a method and a device for autonomously processing an exception of embedded software for a SPARC platform, including:

in a first aspect, an embodiment of the present invention provides an embedded software exception autonomous processing method for a SPARC platform, where the method includes:

step S100, a Trap processing function corresponding to target software is hung to a Trap processing entry address in the SPARC platform; then determining the execution address of the target software according to the function entry address corresponding to the target state determined by the Trap processing function;

wherein the Trap handling function is a leaf function, and is configured to perform the following steps to determine the target state:

step S110, reading an i7 register value of a register window in the SPARC platform, and determining the current partition of the target software according to the i7 register value and an address partition table;

step S120, judging whether the current partition is the partition where the bottom layer public function operates, if so, setting a target state as a system minimum mode operation state, otherwise, executing step S130;

step S130, searching a state conversion linked list set corresponding to the current state of the target software in a state conversion relation table corresponding to the target software; if the state transition linked list set is empty, setting a target state as a system minimum mode operation state; otherwise, selecting the state conversion linked list with the highest priority in the state conversion linked list set as an alternative state conversion linked list according to the priority field of the state conversion linked list set;

step S140, judging whether the operation subareas corresponding to the alternative state conversion linked list comprise the current subarea or not according to the operation state subarea table; if the target state is not included and the jump condition indicated by the jump condition field corresponding to the alternative state transition linked list can be met, determining the target state according to the alternative state transition linked list; otherwise, the alternative state transition linked list is excluded from the state transition linked list set, and step S130 is executed again.

Optionally, before step S100, the method further comprises:

dividing the RAM/SRAM used for the target software to run by the SPARC platform into a plurality of partitions, and constructing a running state partition table corresponding to the target software according to partition conditions occupied by the target software in different running states; and occupying one or more partitions when the target software is in different running states.

Optionally, the running state partition table includes corresponding state numbers, number of occupied partitions, and number of occupied partitions when the target software is in different running states.

Optionally, the underlying common functions of the SPARC platform run in one of the plurality of partitions.

Optionally, the system minimum mode operating state is one of the different operating states.

Optionally, before step S100, the method further comprises:

determining a state conversion relation table corresponding to the target software according to the service requirement of the target software operation; the state conversion relation table comprises a plurality of state conversion linked list sets corresponding to the running states of the target software; the state transition linked list set comprises a plurality of state transition linked lists used for indicating the target software jumping information.

Optionally, the target software jump information includes a jump condition field, a jump status field, and/or a priority field.

Optionally, a value of a jump condition field of one of the state transition linked lists for indicating the jump information of the target software is a number that satisfies a jump condition, a value of the jump state field is a minimum mode operation state of the system, and a priority indicated by a priority field is a minimum.

Optionally, before executing step S110, the Trap processing function further includes:

and storing the register group and the stack content of the target software in a preset address space when the target software has abnormal operation, and recording the current state of the target software.

In a second aspect, an embodiment of the present invention provides an embedded software exception autonomous processing apparatus for a SPARC platform, where the apparatus includes:

the function calling module is used for hooking a Trap processing function corresponding to the target software to a Trap processing entry address in the SPARC platform; then determining the execution address of the target software according to the function entry address corresponding to the target state determined by the Trap processing function;

the Trap processing function is a leaf function and comprises the following functional modules for determining the target state:

the current partition determining module is used for reading the i7 register value of the register window in the SPARC platform and determining the current partition of the target software operation according to the i7 register value and the address partition table;

the special partition judging module is used for judging whether the current partition is the partition where the bottom layer public function operates, and if so, setting the target state as the minimum mode operation state of the system;

the alternative state determining module is used for searching a state conversion linked list set corresponding to the current state of the target software in a state conversion relation table corresponding to the target software; if the state transition linked list set is empty, setting a target state as a system minimum mode operation state; otherwise, selecting the state conversion linked list with the highest priority in the state conversion linked list set as an alternative state conversion linked list according to the priority field of the state conversion linked list set;

the target state determining module is used for judging whether the operation subareas corresponding to the alternative state conversion linked list comprise the current subarea or not according to the operation state subarea table; if the target state is not included and the jump condition indicated by the jump condition field corresponding to the alternative state transition linked list can be met, determining the target state according to the alternative state transition linked list; otherwise, the alternative state conversion linked list is excluded from the state conversion linked list set, and the alternative state conversion linked list is determined again from the state conversion linked list set.

The SPARC platform-oriented embedded software exception autonomous processing method and device provided by the embodiment of the invention are different from the mode of exception processing needing manual assistance in the prior art, realize exception autonomous processing through a Trap processing mode and the specific function of a designed Trap processing function, and have small time delay; secondly, by judging the address space where the abnormality occurs, the situation that the system is continuously reset due to the abnormality of the target software and the service of the system is interrupted is avoided as much as possible; finally, by using the characteristics of a register window mechanism of the SPARC platform and using a Trap processing function as a leaf function, runtime information such as register groups, stack contents and the like is saved, and the analysis and the positioning of subsequent abnormal problems are facilitated.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required to be used 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 application, and it is obvious for those skilled in the art to obtain other drawings without creative work. The foregoing and other objects, features and advantages of the application will be apparent from the accompanying drawings. Like reference numerals refer to like parts throughout the drawings. The drawings are not intended to be to scale as practical, emphasis instead being placed upon illustrating the subject matter of the present application.

Fig. 1 shows a flow diagram of an embedded software exception autonomous processing method for a SPARC platform according to an embodiment of the present invention.

Fig. 2 is a schematic flow diagram illustrating an embedded software exception autonomous processing method for a SPARC platform according to an embodiment of the present invention.

Fig. 3 shows a schematic structural diagram of an embedded software exception autonomous processing apparatus facing the SPARC platform according to an embodiment of the present invention.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is illustrative only and is not intended to limit the scope of the present disclosure. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The words "a", "an" and "the" and the like as used herein are also intended to include the meanings of "a plurality" and "the" unless the context clearly dictates otherwise. Furthermore, the terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.

At present, the exception handling means for continuous reset of the embedded software for the SPARC platform mainly comprises manual operation for powering on again or switching to a backup device for running again. This approach has the following disadvantages: (1) when the equipment implanted into the SPARC platform is unmanned running equipment, an effective remote power-on and power-off means is needed to complete exception handling by manual assistance, and the independence is lacked; (2) the time delay for completing the power on/off operation of the system is large, and the continuity of the system operation is influenced by the untimely processing of the exception; (3) after the system is powered up again, some environment information during operation can be lost, which is not beneficial to the subsequent positioning and repairing of the abnormity; (4) the operation of the system to power back-off often causes interruption of system service, which is not allowed for some critical systems.

In view of this, an object of the embodiments of the present disclosure is to provide a method and a device for autonomously handling an exception of embedded software for a SPARC platform, and details of the disclosure of the embodiments of the present disclosure are described below with reference to the accompanying drawings.

Fig. 1 shows a schematic flow diagram of an embedded software exception autonomous processing method for a SPARC platform according to an embodiment of the present invention, which is specifically described below.

Step S110, hanging a Trap processing function to a Trap processing entry address in the SPARC platform; and then determining the execution address of the target software according to the function entry address corresponding to the target state determined by the Trap processing function.

The embodiment of the invention provides an SPARC platform-oriented embedded software exception autonomous processing method, and aims to provide an autonomous processing method without manual intervention when the embedded software running on the SPARC platform is abnormal in running. SPARC (Scalable Processor Architecture) is one of RISC microprocessor architectures popular in the world, and is often applied to devices and systems with high requirements for safety in the fields of aerospace, automotive electronics, and the like due to its high reliability.

The target software in the step is embedded software running on the SPARC platform, and the target software has running abnormity in the running process, such as floating point operation abnormity, null pointer abnormity and the like.

And under the condition that the SPARC platform detects that the target software has an abnormal operation through a mechanism of a processor, hanging the Trap processing function to a Trap processing entry address in the SPARC platform. The SPARC platform also supports Interrupt (Interrupt) or Trap (Trap) mechanisms to respond to exception events, and accordingly also provides Trap transaction entry addresses. The specific mode of responding to the abnormal event can be realized by designing a corresponding Trap processing function and hanging the Trap processing function body in an interrupt vector table, and the corresponding abnormal type can be specified during hanging.

For example, in order to detect floating point operation exception of target software, an entry hooking of Trap processing function can be performed in an interrupt vector table of the SPARC platform.

TRP_SET(_TRPIntHandler, 0x08)

Wherein TRP _ SET is used for carrying out the entry hooking of a Trap processing function in an interrupt vector table of the SPARC platform, 0x08 is a floating point Trap serial number of the SPARC platform, and the TRP IntHandler realizes function jumping by writing in the following assembly language.

_TRPIntHandler：

call ExceptionDeal

nop

After the hooking operation of the Trap processing function, a specific function of the Trap processing function needs to be executed. The Trap processing function in the embodiment of the invention finally needs to jump to the target state of the running target software. It can be understood that after the target software autonomously jumps from the current state to the target state through the function of the Trap processing function, the abnormal operation condition occurring in the current state can be avoided.

In particular, the target software may be run in a plurality of different states in embodiments of the invention. For example, the target software is control software of the unmanned aerial vehicle, the unmanned aerial vehicle may be in a plurality of different states, such as a cruise state, an ascent state, a descent state, and the like, and different functions of the control software may need to be called to control the unmanned aerial vehicle in the different states. When the unmanned aerial vehicle controlled by the target software encounters a situation of abnormal operation in a cruise state, a target state to which the unmanned aerial vehicle needs to jump is calculated through a Trap processing function, then an execution address of the target software is determined according to a function entry address corresponding to the target state determined by the Trap processing function, and then the Trap processing flow is exited, so that the abnormal autonomous processing flow of the target software is completed.

Therefore, the key step of the embodiment of the invention is to determine the target state to be jumped to by using the Trap processing function, and the method is specifically implemented as follows.

Step S110, reading the i7 register value of the register window in the SPARC platform, and determining the current partition of the target software according to the i7 register value and the address partition table.

SPARC is characterized in that a register window is formed, any process can only see registers in the current window, and the process can forcibly start a new window by using a command. Each window may contain multiple registers with partial overlap of registers between windows for passing parameters.

In the embodiment of the invention, the Trap processing function is clearly defined as the type of the leaf function. In SPARC, the leaf function is characterized in that the Trap handling function is called without switching the register window, and is directly hooked to the corresponding Trap handling entry address. The advantage of not switching the register window is that the information of each register value in the original register window is preserved.

On one hand, the register group and the stack content of the target software in abnormal operation can be stored in a preset address space, and the current state of the target software is recorded, so that the loss of environment information in operation is avoided, and the subsequent positioning and repairing of the abnormal operation are facilitated. Specifically, it can be realized in a Trap processing function by a pseudo code like the following.

save %g0~%g7,%i0~%i7,%o0~%o7,%l0~%l7,%f0~%f15

Wherein g 0-g 7, i 0-i 7, o 0-o 7, l 0-l 7 and f 0-f 15 are 32+16 registers in the register window under the current state, and each register has different fixing functions in the SPARC, which is not listed here.

On the other hand, the saved register value, for example, the i7 register value of SPARC, is used to store the address of the target software running in the current state, and then the current partition of the target software running can be determined according to the i7 register value and the address partition table.

asm("set _restoreaddr,%l5")

asm("set %i7, [ %l5 ]")

tmpPart = Partition{_restoreaddr}

The operating address information indicated by the i7 register value in the code can be saved in the variable _ restore, then the value of the return address register i7 of the register window in the software exception state is read through the following code, the partition where the i7 register value is located is judged according to the content of the start address and the end address in the operating address area table, and the partition number is stored in the variable tmpPart.

In the embodiment of the invention, the RAM/SRAM used for the target software to run needs to be designed in a partitioning mode before the Trap processing function is designed. The reason is that when the target software has an abnormal operation condition, the corresponding fault usually exists in the system address operated by the target software, so that when an embedded software abnormal autonomous processing method is designed, it is required to ensure that the address operated in a jump-to state when the target software is abnormal does not have a fault repeatedly, and the occurrence of system service interruption caused by continuous system reset occurs. Therefore, the RAM/SRAM operated by the target software can be subjected to partition design, and the condition that the partitions operated by the target software do not include the partitions with faults after jumping is fundamentally ensured.

Specifically, the embodiment of the present invention needs to perform partition design on the RAM/SRAM area where the running address of the software is located in the process of compiling links according to the hardware configuration of the system, and each partition is provided with a unique number, such as partition 1, partition 2 … …, partition N (N > 2), where one partition k (k e [1, N ]) is used as the partition where the underlying common function runs, and a function of the basic algorithm, such as vector addition, vector multiplication, etc., runs in the partition k.

Accordingly, the embodiment of the invention designs the address partition table according to the partition condition, and the address partition table is used for determining the partition where the target software runs. Specific examples are as follows.

typedef struct TAG_PARTITION_TAB

{

Assigned int PartID;/. zone number;/

Assigned int StartAddr;/. The start address;. The

unknown int EndAddr;/. The end address;/. The end address;)

} SPartitionTab;

SPartitionTab mPartitionTab[7] =

{

{1, 0x1000000, 0x1020000},/' partition 1 · or

{2, 0x1030000, 0x1050000},/{ partition 2 ×

{3, 0x1060000, 0x1080000},/{ partition 3} live/or

{4, 0x1090000, 0x10B0000},/{ partition 4 × }

{5, 0x10C0000, 0x10E0000},/{ partition 5 ×

{6, 0x10F0000, 0x1110000},/{ partition 6} live/or

{7, 0x1120000, 0x1140000},/{ partition 7 × } live in

};

Wherein, TAG _ PARTITION _ TAB shows a specific data structure of each PARTITION, including a PARTITION number PartID, a start address StartAddr, and an end address EndAddr of the PARTITION. mPartitionTab shows a specific partition implementation, in this example the system is partitioned into 7 partitions. For example, partition 1 has number 1, starting address 0x1000000, and ending address 0x 1020000. That is, when the address at which the target software is operated in the current state includes an address between 0x1000000 and 0x1020000, it indicates that the target software is operated in the partition 1. Other partitions can be understood in a similar manner and are not described in detail herein.

Therefore, when the operation address of the target software indicated by the i7 register value when the abnormality occurs currently and the address partition table designed in advance are obtained, the current partition of the target software operation can be determined accordingly. It will be appreciated that the current partition is also a potentially failing partition due to the scenario in which the current partition is in the event of an exception.

The register window and the leaf function are both characteristics of SPARC, the Trap processing function is defined as the leaf function, the switching of the register window in the Trap process can be avoided, and each register in the SPARC register window stores specific runtime information, so that the information of the register in the SPARC platform is not lost when an abnormal situation occurs.

Step S120, judging whether the current partition is the partition where the bottom layer public function operates, if so, setting the target state as the minimum mode operation state of the system, otherwise, executing step S130.

After the current partition in which the target software runs is obtained in step S110, it is first determined whether the current partition is a partition in which the underlying common function runs. In the foregoing steps, it is described that in the embodiment of the present invention, when the partition design is performed, one of the partitions is used as the partition where the underlying common function operates. Since the underlying common function is a basic function frequently called by all software running in the system, when the partition becomes a potential fault partition when an exception occurs, it indicates that the system in the SPARC platform may encounter a large fault, and at this time, the target state should be selected to be directly set to the minimum mode running state of the system. The minimum mode operation state of the system in the embodiment of the invention refers to that most services of the system are suspended, and the system is only kept in a basic operation state. In the embodiment of the invention, when different states of each target software are designed, one state meeting the description above is selected as the minimum mode operation state of the system.

For example, for a control system of an unmanned aerial vehicle, a minimum mode operation state of the system may be a STANDBY state, in which the unmanned aerial vehicle is stably hovering at a certain approximate position, only one control power output is guaranteed in control, all business operations are suspended, and a hovering attitude is maintained.

In this step, when the partition in which the bottom layer common function operates is a potential fault partition, most of the system services may be affected by the partition, and in order to ensure the continuity of the system services, the target state is set to be the minimum mode operation state of the system and is used as the output of the Trap processing function.

Step S130, searching a state conversion linked list set corresponding to the current state of the target software in a state conversion relation table corresponding to the target software; if the state transition linked list set is empty, setting a target state as a system minimum mode operation state; and if not, selecting the state conversion linked list with the highest priority in the state conversion linked list set as the alternative state conversion linked list according to the priority field of the state conversion linked list set.

When the determination condition in step S120 is not satisfied, the Trap processing function starts executing the function in step S130, and further determines the target state to which the target software needs to jump. In the embodiment of the invention, three judgment conditions, namely a priority condition, a jump condition and a partition conflict condition, need to be considered when further determining the target state. Wherein the priority condition is mainly considered in step S130.

The embodiment of the invention needs to design a state conversion relation table for the target software before determining that the target software is in the jump state when being abnormal. The state transition relation table records a target state which can be jumped to when the target software is in any state and related information required for judging the target state. The state conversion relation table is composed of a plurality of state conversion linked list sets, each state conversion linked list set corresponds to a current state of the target software, and correspondingly records a target state which can be jumped to under the current state and related information required for judging the target state. Each state conversion linked list set comprises a plurality of state conversion linked lists, and each state conversion linked list corresponds to the related information of the target software which jumps to a certain target state under a certain current state.

The concepts of the state transition relationship table, the set of state transition linked lists, and the state transition linked list are illustratively described by the following examples.

typedef struct TAG_STATE_TRANS_ELE

{

An unsigned int TransEnable, status jump condition, 1 is allowed, 0 is not allowed

Assigned int StateTarget, target status number

} SStateTransEle;

The SStateTransEle defined above is a state transition linked list, and the specific structure thereof includes a state jump condition TransEnable and a target state number StaeTarget. When TransEnable is 1, the condition of jumping to the target state StateTarget is satisfied, and jumping can be performed; when the transitienable is 0, the condition for jumping to the target state StateTarget is not satisfied, and the jump cannot be performed. Further, a jump priority variable (not shown in the code) may be further included in the STATE transition linked list TAG _ STATE _ TRANS _ ELE, and is used to indicate the priority level of the jump to the target STATE StateTarget.

typedef struct TAG_STATE_TRANS_LINK_TAB

{

Signaled int StateID, current status number

SStateTransEle StateNum [7],/target state and its jump condition +

} SStateTransLinkTab;

The SStateTransLinkTab defined above is a state transition linked list set, and its specific structure includes the current state number StateID, the target state and its jump condition StateNum [7 ]. It can be seen that one state transition linked list set SStateTransLinkTab includes 7 state transition linked lists, and it can be seen that the state of the target software defined in this example does not exceed 7. The SStateTransLinkTab indicates a target state to which the abnormal situation exists and the current state is stateID, and related information required for judging the target state.

SStatePartTab SStateTransLinkTab[6] =

{

{1, { {1,3}, {1,6}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0},/{ cruise status } or { [ based on the status of the cruise control }

{2, { {1,3}, {1,6}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0},/{ stationary suspension status } live/status

{3, { {1,2}, {1,6}, {0,0}, {0,0}, {0,0}, {0,0}, {0,0},/{ coarse hover state } and/or

{4, { {1,3}, {1,1}, {1,6}, {0,0}, {0,0},/{ rising state } or { (1, 3}, {0,0}, {0,0}, } },/} rising state { (S } or { (S) } or { (S1, 6}, {0,0}, {0,0}, (0, 0}, {0,0}, (0, 0}, {0,0}, {0,0}, (S } or

{5, { {1,3}, {1,1}, {1,6}, {0,0}, {0,0},/{ down state } or { (1, 3}, {0,0}, {0,0}, } },/} down state { (5) } or { (0, 0}, {0,0}, {0,0}, } down state } or (0, or } or a combination thereof

{6, { {1,6}, {0,0}, {0,0}, {0,0}, {0,0},/. STANDBY status } or { [ H ] status } status

};

The SStateTransLinkTab [6] defined above is an example of a state transition relationship table corresponding to the control software of the target software UAV. Therefore, according to the service characteristics of the target software, the software is divided into 6 running states, namely a cruise state, a fine suspension stop state, a coarse suspension stop state, an ascending state, a descending state and a STANDBY state.

Specifically, the cruising state is that the unmanned aerial vehicle flies forward cruising at a stable speed and can take business pictures; the hovering state refers to that the unmanned aerial vehicle is stably hovered at a certain position and can take business pictures, and the hovering state is divided into a fine suspension stable state and a coarse suspension stable state according to control precision and a control strategy; the ascending state means that the unmanned aerial vehicle flies upwards according to a preset strategy and stops the business photographing; the descending state means that the unmanned aerial vehicle flies downwards according to a preset strategy and stops the business photographing; the STANDBY state means that the unmanned aerial vehicle stably hovers at a certain approximate position, only one control power output is ensured in control, all services are suspended, and the hovering attitude is maintained, namely the minimum mode operation state of the system.

By way of further example, "{ 4, { {1,3}, {1,1}, {1,6}, {0,0}, {0,0}, {0,0}, {0,0} } } denotes an example of a set of state transition lists in a state transition relationship table, which represents information about a target state to which the state can jump when the current state is a rising state. Still further, a "4" indicates a state number of the ascending state, where "{ 1,3 }", "{ 1,1 }", "{ 1,6 }", "{ 0,0 }" included in the ascending state are all state transition linked lists, and correspond to information related to jumping to different target states, respectively. For example, "3" in "{ 1,3 }" indicates a coarse hover state, and "1" indicates that the target software can jump from a rising state to a coarse hover state. Similarly, "{ 1,1 }" and "{ 1,6 }" indicate that the target software can jump from the ascent state to the cruise state or the STANDBY state, respectively. In addition, the subsequent state transition linked list is set to be "{ 0,0 }" to indicate that the target software is not allowed to jump from the ascending state to other states, and here, the state transition linked list can also be represented as "{ 0,2 }", "{ 0,5 }" and the like, and the execution logic of the Trap processing function is not changed.

In addition, the foregoing introduces that the state transition linked list may further include a jump priority variable in addition to the target state number and the jump condition, for example, {1,3} may also be denoted as {1,1,3}, where the newly added first "1" indicates that the priority for jumping to the rough suspension state is the highest when the target software is in the up state. As shown in the above example, the priority variables may be omitted in the state transition linked list, and the priority information may be expressed by the order of the state transition linked list, for example, according to the recording order of "{ 1,3 }", "{ 1,1 }", "{ 1,6 }" which indicates that the priority for jumping to the coarse hover state is the highest, the priority for jumping to the cruise state is the second, and the priority for jumping to the STANDBY state is the lowest when the target software is in the up state.

When the state conversion relation table of the target software is designed in advance, the information of which target states the current state can jump to, the jump priority and the like is determined by a system designer according to the logic of system service operation. For example, when the unmanned aerial vehicle is in a rising state, after rising to a certain position, the unmanned aerial vehicle usually performs fixed-point business photographing after hovering, and at this time, the unmanned aerial vehicle generally jumps to enter a rough and steady suspension state; or the aircraft can cruise forward at a stable speed, and business photographing on a certain route can be carried out. In addition, in special situations, the system minimum mode operation state, namely the STANDBY state, can be switched to, and the hovering gesture is maintained. While the rising state generally does not jump directly to the falling state or the fine hover state. Therefore, the jump conditions of the target software in different current states can be designed. In addition, according to the frequency of different states in service operation, the corresponding priorities of different jump states can be determined.

Meanwhile, the value of the jump condition field of one of the state transition linked lists for indicating the jump information of the target software is a number satisfying the jump condition, the value of the jump state field is the minimum mode running state of the system, and the priority indicated by the priority field is the lowest, {1,6} "in the example.

Therefore, in step S130, a state transition linked list set corresponding to the current state of the target software is first searched in the state transition relationship table corresponding to the target software. For example, in the case where an operation abnormality occurs when the control software of the unmanned aerial vehicle is in a raised state, the state transition linked list set "{ 4, { {1,3}, {1,1}, {1,6}, {0,0}, {0,0}, {0,0} } } can be found by looking up the state transition relationship table sstatetranlinktab in the above example.

In particular, if the set of state transition lists is empty, the target state is set to the minimum mode operation state of the system. Illustratively, if the set of state transition chains corresponding to the current state is found to be "{ 0,0}, {0,0}, {0,0}, {0,0} … …", which indicates that the current state has no jump state meeting the condition, the target state may be directly set as the minimum mode operation state of the system, so as to keep continuous operation of system services as much as possible.

If the state transition linked list set is not empty, step S130 selects the state transition linked list with the highest priority in the state transition linked list set as the alternative state transition linked list according to the priority field of the state transition linked list set. In the above example, the priority fields in the set of state transition linked lists "{ 4, { {1,3}, {1,1}, {1,6}, {0,0}, {0,0}, {0,0} } }" are represented by the order in which the state transition linked lists appear, and thus the state transition linked list "{ 1,3 }" with the highest priority is selected as the alternative state transition linked list. The Trap processing function in the embodiment of the present invention is embodied herein as a priority condition of three determination conditions that need to be considered when further determining the target state.

Step S140 represents a partition conflict condition and a jump condition of the three determination conditions that need to be considered when the Trap processing function further determines the target state in the embodiment of the present invention.

After the candidate state transition linked list is determined in step S130, it needs to further determine whether the target state corresponding to the candidate state transition linked list can become the target state output by the Trap processing function according to the partition conflict condition and the jump condition.

And judging whether the operation subareas corresponding to the alternative state conversion linked list have intersection with the current subarea or not according to the operation state subarea table for the subarea conflict condition. In the embodiment of the invention, the judgment condition is realized by a pre-designed running state partition table. The operation state partition table is constructed according to partition conditions occupied by the target software in different operation states after the RAM/SRAM used for the operation of the target software by the SPARC platform is divided into a plurality of partitions; wherein the target software occupies one or more partitions when in different operating states. The running state partition table comprises corresponding state numbers, the number of occupied partitions and the number of occupied partitions when the target software is in different running states.

The meaning of the operation state partition table is described below by a specific example.

typedef struct TAG_STATE_PART_TAB

{

Signaled int StateID, status number

Signaled int StateNum;/. covered partition number;. + -

Configured int PartTab [8], covered partition number list +

} SStatePartTab;

SStatePartTab mStatePartTab[6] =

{

{1,2, {1,7,0,0,0,0,0,0} },/[ cruise status ] based on the status of the clutch

{2,3, {2,3,7,0,0,0,0,0} },/[ constant suspension status } [. ] based on the status of [ {2,3,7,0,0,0,0,0} },/[ constant suspension status ] }

{3, 3, {4,5,7,0,0,0,0,0} },/' coarse hover state {4,5,7,0,0, 0} } } } } based on the status of the suspension

{4, 2, {6,7,0,0,0,0,0,0} },/{ up state }

{5, 2, {6,7,0,0,0,0,0,0} },/{ down state }

{6, 1, {7,0,0,0,0,0, 0} },/[ STANDBY status } @

}

The TAG _ STATE _ PART _ TAB is a data structure for describing the occupation situation of the partition when the target software is in a specific STATE, and comprises a STATE number StateID, the number StateNum of occupied partitions and the number PartTab [ ]ofoccupied partitions. PartTab [8] indicates that the system is divided into 7 partitions when partition design is performed, the last element of the PartTab is 0, and the last element represents an ending or meaningless element.

Specifically, for the control software of which the target software is an unmanned aerial vehicle, the mStatePartTab is an operating state partition table corresponding to the software. The software can be in 6 different states, with the entire system divided into 7 partitions. Taking the cruise state as an example, the state number is 1, the number of occupied partitions is 2, the specifically occupied partitions are partition 1 and partition 7, and specific numerical values corresponding to other states can be understood in a similar manner, which is not described herein again. The running state partition table is constructed according to the partition condition actually occupied by the target software in different running states.

In conjunction with the above description of the operating status partition table, an example of determining the partition conflict condition is as follows: when the unmanned aerial vehicle is in the ascent state, it is assumed that the current zone obtained in step S110 is zone 6; the alternative state transition linked list obtained in step S130 is "{ 1,3 }" with the highest priority, and the coarse suspension state is referred to as the alternative state transition linked list. And searching the running state partition table to obtain running partitions corresponding to the rough suspension state, namely partition 4, partition 5 and partition 7, and then judging whether the running partitions corresponding to the alternative state conversion linked list comprise the current partitions or not, wherein the judgment result shows that the current partitions do not comprise the current partitions, the partition conflict condition is met, and the target state corresponding to the alternative state conversion linked list does not have partition conflict with the abnormal current partitions.

The reason for setting the partition conflict condition is that if the partition operated in the target state corresponding to the candidate state transition linked list still includes a potential faulty partition, if the target state is jumped to, the target software still has a potential abnormal operation, and therefore the target state needs to be eliminated.

After the partition conflict condition is judged, the skip condition in the three judgment conditions needs to be further judged. The judgment mode of the skipping condition is simple. The state transition linked list SStateTransEle was introduced above and includes a state transition condition TransEnable field. Wherein, when TransEnable is 1, the jump condition is satisfied, and the jump can be carried out; when TransEnable is 0, it means that the jump condition is not satisfied and the jump cannot be performed. By reading this field, it can be judged that: and when the jumping situation between the states is designed according to the system service logic, whether the current state can jump to the target state or not is judged.

If the Trap processing function passes three judgment conditions such as priority condition, jump condition and partition conflict condition when determining the target state, the target state can be used as the final output target state of the Trap processing function, and the Trap processing function is executed completely.

In step S140, if any one of the jump condition and the partition conflict condition is not satisfied, it indicates that the target state corresponding to the candidate state transition linked list determined according to the priority condition in step S130 cannot be successfully jumped. At this time, after the alternative state transition linked list needs to be excluded from the state transition linked list set, step S130 is executed again, which means that the state transition linked list with the second highest priority needs to be selected from the state transition linked list set as the alternative state transition linked list, and step S140 is executed again. And circularly executing the process until a target state which meets three judgment conditions and can be finally output as a Trap processing function is determined, and taking a function entry address corresponding to the target state as the output of the Trap processing function.

If the appropriate target state cannot be determined finally through the method, the minimum mode operation state of the system can be directly determined as the target state, the function entry address corresponding to the target state is used as the output of the Trap processing function, and then the Trap processing function is quitted.

In summary, the process of the embedded software exception autonomous processing method for the SPARC platform according to the embodiment of the present invention may be divided into three stages, and as shown in the flow diagram of fig. 2, the method includes a system design stage 210, which is configured to design a system partition for target software, generate an address partition table and an operating state partition table, and design a state transition relationship table for the target software according to a service logic of the target software; a Trap processing stage 220, configured to, when it is detected that the target software has an abnormal operation, attach a Trap processing function to a Trap processing entry address in the SPARC platform; then determining the execution address of the target software according to the function entry address corresponding to the target state determined by the Trap processing function; a Trap processing function executing stage 230, configured to execute specific functions of the Trap processing function, based on the information related to various target software determined in the system design stage, and based on three determination conditions, such as the priority condition, the jump condition, and the partition conflict condition, in the embodiment of the present invention, and finally output a function entry address corresponding to a target state to which the target software needs to jump.

The embedded software exception autonomous processing method for the SPARC platform, provided by the embodiment of the invention, is different from the mode of exception processing needing manual assistance in the prior art, realizes exception autonomous processing through a Trap processing mode and the specific function of a designed Trap processing function, and has small time delay; secondly, by judging the address space where the abnormality occurs, the situation that the system is continuously reset due to the abnormality of the target software and the service of the system is interrupted is avoided as much as possible; finally, by using the characteristics of a register window mechanism of the SPARC platform and using a Trap processing function as a leaf function, runtime information such as register groups, stack contents and the like is saved, and the analysis and the positioning of subsequent abnormal problems are facilitated.

Based on the foregoing embodiment, fig. 3 shows a schematic structural diagram of an embedded software exception autonomous processing apparatus for a SPARC platform according to an embodiment of the present invention, which includes the following contents specifically.

A function calling module 300, configured to hook a Trap processing function to a Trap processing entry address in the SPARC platform; then determining the execution address of the target software according to the function entry address corresponding to the target state determined by the Trap processing function;

a current partition determining module 310, configured to read an i7 register value of a register window in the SPARC platform, and determine a current partition in which the target software operates according to the i7 register value and an address partition table;

the special partition judging module 320 is configured to judge whether the current partition is a partition where a bottom-layer public function operates, and if so, set a target state to a system minimum mode operation state;

an alternative state determining module 330, configured to search a state transition linked list set corresponding to the current state of the target software in a state transition relationship table corresponding to the target software; if the state transition linked list set is empty, setting a target state as a system minimum mode operation state; otherwise, selecting the state conversion linked list with the highest priority in the state conversion linked list set as an alternative state conversion linked list according to the priority field of the state conversion linked list set;

a target state determining module 340, configured to determine whether the operation partition corresponding to the alternative state transition linked list includes the current partition according to the operation state partition table; if the target state is not included and the jump condition indicated by the jump condition field corresponding to the alternative state transition linked list can be met, determining the target state according to the alternative state transition linked list; otherwise, the alternative state conversion linked list is excluded from the state conversion linked list set, and the alternative state conversion linked list is determined again from the state conversion linked list set.

The embedded software exception autonomous processing device for the SPARC platform, provided by the embodiment of the invention, is different from the mode of exception processing needing manual assistance in the prior art, realizes exception autonomous processing through a Trap processing mode and the specific function of a designed Trap processing function, and has small time delay; secondly, by judging the address space where the abnormality occurs, the situation that the system is continuously reset due to the abnormality of the target software and the service of the system is interrupted is avoided as much as possible; finally, by using the characteristics of a register window mechanism of the SPARC platform and using a Trap processing function as a leaf function, runtime information such as register groups, stack contents and the like is saved, and the analysis and the positioning of subsequent abnormal problems are facilitated.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.

Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims

1. An embedded software exception autonomous processing method for a SPARC platform is characterized by comprising the following steps:

2. The embedded software exception autonomous processing method according to claim 1, characterized in that before step S100, the method further comprises:

3. The embedded software exception autonomous processing method according to claim 2, wherein the running state partition table includes corresponding state numbers, numbers of occupied partitions, and numbers of occupied partitions when the target software is in different running states.

4. The embedded software exception autonomic processing method of claim 2 wherein the underlying common functions of the SPARC platform run in one of the plurality of partitions.

5. The embedded software exception autonomic processing method of claim 2 wherein said system minimum mode operating state is one of said different operating states.

6. The embedded software exception autonomous processing method according to claim 1, characterized in that before step S100, the method further comprises:

7. The embedded software exception autonomous processing method according to claim 6, wherein the target software jump information includes a jump condition field, a jump status field and/or a priority field.

8. The embedded software exception autonomous processing method as claimed in claim 7, wherein a value of a jump condition field of one of the plurality of state transition lists for indicating the jump information of the target software is that a jump condition is satisfied, a value of the jump state field is a number of a minimum mode operation state of a system, and a priority indicated by a priority field is lowest.

9. The embedded software exception autonomous processing method according to claim 1, wherein the Trap processing function further comprises, before executing step S110:

10. An embedded software exception autonomous processing device facing a SPARC platform, which is characterized by comprising: