Software debugging task scheduling method and device, equipment and storage medium

Abstract

The invention discloses a software debugging task scheduling method, device and equipment and a storage medium, and relates to the technical field of software debugging, software developers only need to submit debugging tasks to a task management server, and the task management server is responsible for interaction with a simulation platform. The task management server firstly sorts the received debugging tasks, and then performs firmware generation and programming corresponding to the debugging tasks according to the idle number of firmware partitions in the simulation platform; once the programming of the firmware corresponding to the current task is completed, the task management server can execute the corresponding debugging case, and after one debugging task is completed, the simulation platform is controlled to reset, and the next debugging task is switched; the firmware programming and the execution of the debugging case are mutually independent, so that the firmware programming efficiency is improved, the debugging task can be automatically switched, the steps of manual negotiation and manual switching of the simulation platform are reduced, and the software debugging and development efficiency of the simulation platform is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software debugging, and particularly to a scheduling method, device, equipment and storage medium for software debugging tasks. Background Art

[0002] In the design and verification projects of large-scale SoCs (System on Chip) and complex electronic systems, an SoC simulation platform is usually used for the functional development and verification of the combination of software and hardware. Large-scale SoCs usually require complex software implementation, which often involves collaborative development and debugging by multiple people. However, due to the high cost of the SoC simulation platform, it is usually impossible to equip each developer with an SoC simulation platform, so team members need to share the simulation platform. In this process, it is often necessary to negotiate manually to switch the platform usage rights. This manual allocation method of the simulation platform significantly reduces the efficiency of software debugging and development in projects with collaborative development by multiple people.

[0003] It can be seen that how to solve the efficiency problem of collaborative development by multiple people in a team when the simulation environment is limited is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of the embodiments of the present invention is to provide a scheduling method, device, equipment and storage medium for software debugging tasks, which can solve the efficiency problem of collaborative development by multiple people in a team when the simulation environment is limited.

[0005] To solve the above technical problems, the embodiments of the present invention provide a scheduling method for software debugging tasks, which is applied to a task management server connected to a simulation platform. The method includes:

[0006] Sort the received debugging tasks to be executed to obtain a task queue;

[0007] Determine the number of free firmware partitions in the simulation platform, select the same number of debugging tasks from the task queue in order, convert the code of the selected debugging tasks into firmware, and burn the firmware into the free firmware partitions;

[0008] Take the first debugging task in the current task queue as the current task;

[0009] If the firmware burning corresponding to the current task is completed, interact with the firmware corresponding to the current task to execute the debug cases in the current task;

[0010] After all the debug cases in the current task are executed, delete the current task from the task queue, and control the simulation platform to reset, and then jump back to the step of taking the first debugging task in the current task queue as the current task.

[0011] In some embodiments, the debugging task includes a debugging type field for defining the priority of the debugging task; sorting the received debugging tasks to be executed to obtain a task queue, including:

[0012] If a debugging task to be executed is received, identify the debugging type field of the currently received debugging task;

[0013] Compare the debugging type field of the currently received debugging task with the debugging type fields of the debugging tasks in the current task queue;

[0014] Re-sort all the debugging tasks according to the comparison result of the debugging type fields to obtain an updated task queue.

[0015] In some embodiments, the debugging task includes a result storage path for specifying the storage location of the debugging execution result; after all the debugging test cases in the current task are executed, it further includes:

[0016] Generate a test case execution report for the debugging test case based on the execution information of the debugging test case; the execution information includes the name, execution times, execution time, and passing status of the debugging test case;

[0017] Retrieve the log information of the debugging test case;

[0018] Store the test case execution report and the log information in the storage location specified by the result storage path of the current task.

[0019] In some embodiments, the debugging task includes a code path field for specifying the directory path where the code of the debugging task is located; converting the code of the selected debugging task into firmware includes:

[0020] Obtain the source code of the debugging task from the corresponding directory path according to the code path field of the selected debugging task;

[0021] Compile the source code to generate the firmware corresponding to the debugging task.

[0022] In some embodiments, converting the code of the selected debugging task into firmware includes:

[0023] Parallelly compile the source codes corresponding to the selected idle number of debugging tasks to convert the codes of each selected debugging task into firmware respectively;

[0024] Burning the firmware into the idle firmware partitions includes:

[0025] Parallelly burn the firmware corresponding to the selected idle number of debugging tasks into the corresponding idle firmware partitions.

[0026] In some embodiments, after deleting the current task from the task queue, it further includes:

[0027] Re - determine the firmware partition where the firmware corresponding to the deleted current task is located as a free firmware partition, and re - jump to the step of determining the number of free firmware partitions in the simulation platform.

[0028] In some embodiments, after burning the firmware into the free firmware partition, it further includes:

[0029] Establish a correspondence between the queuing number of the debug task and the partition number of the firmware partition where its corresponding firmware is located; where the queuing number is the sequence number of the debug task in the task queue.

[0030] Before interacting with the firmware corresponding to the current task to execute the debug cases in the current task, it further includes:

[0031] If the firmware burning corresponding to the current task is completed, send a start instruction to the simulation platform to control the simulation platform to load and run the firmware corresponding to the current task.

[0032] Query the partition number of the firmware currently running on the current simulation platform.

[0033] Based on the correspondence, determine whether the partition number of the firmware currently running on the current simulation platform corresponds to the current task.

[0034] If so, jump to the step of interacting with the firmware corresponding to the current task to execute the debug cases in the current task.

[0035] To solve the above - mentioned technical problems, an embodiment of the present invention further provides a scheduling device for software debug tasks, which is applied to a task management server, and the task management server is connected to a simulation platform; the device includes:

[0036] A sorting unit, configured to sort the received debug tasks to be executed to obtain a task queue.

[0037] A firmware burning unit, configured to determine the number of free firmware partitions in the simulation platform, sequentially select the number of free debug tasks from the task queue, convert the code of the selected debug tasks into firmware, and burn the firmware into the free firmware partitions.

[0038] A debug start unit, configured to use the first debug task in the current task queue as the current task.

[0039] A debug execution unit, configured to, if the firmware burning corresponding to the current task is completed, interact with the firmware corresponding to the current task to execute the debug cases in the current task.

[0040] A debugging switching unit, which is used to delete the current task from the task queue after all debugging test cases in the current task are executed, and control the reset of the simulation platform to re-trigger the debugging startup unit.

[0041] To solve the above technical problems, an embodiment of the present invention further provides an electronic device, including:

[0042] A memory, which is used to store computer programs;

[0043] A processor, which is used to execute the computer program to implement the steps of the scheduling method for software debugging tasks as described above.

[0044] To solve the above technical problems, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the scheduling method for software debugging tasks as described above are implemented.

[0045] It can be seen from the above technical solutions that software developers only need to submit debugging tasks to the task management server, and the task management server is responsible for interacting with the simulation platform. The task management server will first sort the received debugging tasks, and then generate and burn the firmware corresponding to the debugging tasks according to the number of free firmware partitions in the simulation platform; the beneficial effect of the present invention is that once the firmware burning corresponding to the current task is completed, the task management server can execute the corresponding debugging test cases, and control the reset of the simulation platform after a debugging task is completed to switch to the next debugging task; the firmware burning and the execution of the debugging test cases are independent of each other, improving the efficiency of firmware burning, and at the same time being able to automatically switch debugging tasks, reducing the steps of manual negotiation and manual switching of the simulation platform, and improving the efficiency of software debugging and development of the simulation platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] To more clearly illustrate the embodiments of the present invention, the following will briefly introduce the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings based on these drawings without creative efforts.

[0047] Figure 1 It is a schematic flowchart of a scheduling method for software debugging tasks provided by an embodiment of the present invention;

[0048] Figure 2 It is a schematic processing flowchart of a scheduling system provided by an embodiment of the present invention;

[0049] Figure 3 It is a schematic data structure diagram of a debugging task provided by an embodiment of the present invention;

[0050] Figure 4 A schematic diagram of a process flow for generating a task queue and burning firmware provided by an embodiment of the present invention;

[0051] Figure 5 A schematic diagram of the execution flow of a debugging task provided by an embodiment of the present invention;

[0052] Figure 6 A schematic diagram of the structure of a scheduling device for software debugging tasks provided by an embodiment of the present invention;

[0053] Figure 7 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0054] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0055] The terms "including" and "having," as used in the present description and accompanying drawings, and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements and may include steps or elements that are not listed.

[0056] In order to enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0057] Next, a method for scheduling software debugging tasks provided by an embodiment of the present invention is described in detail, which is applied to a task management server connected to a simulation platform. Figure 1 As shown, Figure 1 A flowchart of a method for scheduling software debugging tasks provided by an embodiment of the present invention is provided; the method for scheduling software debugging tasks includes:

[0058] S11: Sort the received debugging tasks to be executed to obtain a task queue.

[0059] It is not difficult to understand that, in order to reduce the operation of manually switching the simulation platform, in the present invention, the task management server is used as a medium between the user and the simulation platform. When the user has a debugging task to be executed, the user only needs to submit and send the debugging task to the task management server. The task management server receives the debugging tasks to be executed submitted by all users, and then sorts the debugging tasks to be executed to generate a task queue to be executed by the simulation platform. The specific sorting method of the debugging tasks in the task queue and the like are not particularly limited in this application, and the specific types of the debugging tasks and the like are not particularly limited in this application, as long as they are tasks that the user needs to submit to the simulation platform for simulation debugging.

[0060] S12: Determine the number of free firmware partitions in the simulation platform, sequentially select the number of debugging tasks equal to the number of free partitions from the task queue, convert the code of the selected debugging tasks into firmware, and burn the firmware into the free firmware partitions.

[0061] It can be understood that, in order to improve the working efficiency of the simulation platform, the task management server will determine the number of free firmware partitions in the simulation platform in real time. If there are free firmware partitions in the simulation platform, the task management server will select the number of debugging tasks equal to the number of free partitions from the task queue according to the detected number of free firmware partitions, execute the compilation and burning of the firmware, convert the code of the debugging tasks into firmware, and burn the firmware into the firmware partition Slot of the simulation platform, so that the simulation platform can execute the corresponding debugging use cases through this binary executable software to complete the debugging tasks. At the same time, the compilation and burning of the firmware also need to be implemented according to the number of debugging tasks to be executed in the task queue. When the number of free firmware partitions is greater than the total number of debugging tasks to be executed in the task queue, the task management server can directly pre-complete the firmware burning of all debugging tasks in the current task queue. For example, when the task management server detects that there are 5 free Slots in the simulation platform and there are only four debugging tasks in the current task queue, the task management server can convert the codes of the four debugging tasks into firmware and burn them into the four free Slots respectively. If the task management server detects that there are 4 free Slots in the simulation platform and there are 6 debugging tasks in the current task queue, the task management server needs to sequentially select four debugging tasks from the first debugging task in the task queue according to the order of these debugging tasks in the task queue, perform the firmware generation and burning process for the first four debugging tasks, and continue to continuously detect the number of free firmware partitions in the simulation platform. After a free Slot appears in the simulation platform, continue the firmware generation and burning process for the remaining two debugging tasks. There are multiple options for the identification method of free Slots, which can be periodically checked and identified according to a preset time period, or can be identified in real time. This application does not make any special limitations here.

[0062] It should be noted that the firmware generation and burning process of the debugging task will not affect the debugging tasks in the task queue and their sorting. The task management server only obtains the code from the debugging tasks, compiles the code to generate the firmware, and then burns the firmware into the idle Slots of the simulation platform. Moreover, whether the firmware generation and burning process is triggered only depends on whether there are idle Slots in the simulation platform. Even if the simulation platform is executing a certain debugging task or test case, the task management server can generate and burn the firmware when there are idle Slots, thereby achieving pre-burning of the firmware according to the number of idle Slots. The present application does not make special limitations on the detection method of idle Slots, etc. The task management server can use the communication connection established between itself and the simulation platform to obtain the status information of each Slot in the simulation platform in real time, so as to check the usage of the Slots.

[0063] S13: Take the first debugging task in the current task queue as the current task.

[0064] S14: If the firmware burning corresponding to the current task is completed, interact with the firmware corresponding to the current task to execute the test case in the current task.

[0065] It is not difficult to understand that after the firmware burning corresponding to the debugging task is completed, the task management server can officially start executing the debugging task. The order in which the task management server executes the debugging tasks completely depends on the order of each debugging task in the task queue. That is, after sorting to generate the task queue, the task management server will continuously detect whether the firmware corresponding to the first debugging task in the task queue is burned. As long as the firmware burning corresponding to the first debugging task is completed, the first debugging task can be started. At this time, the simulation platform runs the firmware corresponding to the first debugging task accordingly. During the execution of the firmware, the test case execution process in the task management server will sequentially execute each test case in the debugging task, and send commands, data and other information to the firmware through the communication connection between the task management server and the simulation platform according to the content of the test case, and at the same time receive the status, results and other information returned by the firmware, so as to discover problems in the firmware by checking whether the execution result of the firmware meets the expectations and complete the debugging task.

[0066] S15: After all the test cases in the current task are executed, delete the current task from the task queue, and control the simulation platform to reset, and then jump back to the step of taking the first debugging task in the current task queue as the current task.

[0067] It can be understood that there are multiple test cases in a debugging task. Each test case is sorted according to specific orders or rules based on the debugging requirements. The test case execution process will sequentially execute all the test cases in the debugging task. After all the test cases are executed, it indicates that the debugging task has been completed. At this time, the debugging task can be deleted from the task queue, and the next debugging task can be automatically executed. Therefore, the task management server will directly control the reset of the simulation platform so that it can automatically switch to the firmware corresponding to the next debugging task for operation, and at the same time, the test case execution process automatically switches to the next debugging task to execute the test cases in the next debugging task.

[0068] It should be noted that during the process of the task management server executing the debugging task, if there are idle Slots in the simulation platform or a new debugging task is added to the task queue, the compilation and flashing process in the task management server can synchronously generate and flash the firmware; that is to say, the compilation and flashing process and the test case execution process are decoupled from each other. As long as there are idle Slots and the firmware corresponding to the debugging task has not been flashed, the compilation and flashing process will automatically work to pre-generate and flash the firmware, while the test case execution process will sequentially execute each debugging task according to the order of the task queue.

[0069] Furthermore, the task management controller can directly utilize the communication connection between itself and the simulation platform. After all the test cases in the current task are executed, it directly sends a reset signal to the simulation platform. After receiving the reset signal, the simulation platform automatically triggers a reset event to restore each module and circuit inside the SoC simulation platform to the initial state. At the same time, the task management controller will inform the simulation platform that the current task has been completed, and the simulation platform can delete the firmware corresponding to the current task from the corresponding Slot.

[0070] It is not difficult to understand that based on this task management server, software developers, i.e., users, only need to execute a task submission script, which is a script program used to submit a debugging task to the task management server. In the task submission script, the debugger submits information such as the code path corresponding to the debugging task, the test cases to be executed, and the final storage path of the test case execution results to the task management server. The task management server first sorts the submitted debugging tasks according to the priority, and then, according to the number of idle Slots in the SoC simulation platform, selects the corresponding number of debugging tasks in the order of task priority for parallel compilation of the code to generate the corresponding executable firmware, and then burns the firmware in parallel to the idle Slots in the SoC simulation platform. When the test case execution process needs to execute a debugging task, the simulation platform runs the corresponding firmware. During the running of the firmware, the test case execution process interacts with the firmware, executes the corresponding debugging test cases, and sends the test case execution results, including LOG (Logarithm, log) or Trace (trace log) data, etc., to the corresponding directory in the user environment. LOG, that is, log, refers to various information recorded during the running of the software. The trace log Trace refers to the detailed event sequence or state change information recorded during the running of the software. When the test cases of a task are executed, the test case execution process notifies the SoC simulation platform to reset and switches to the Slot corresponding to the next debugging task with the burned firmware to start loading and starting the firmware corresponding to the next debugging task. Such an operation only resets the SoC used for simulation in the simulation platform and restores it to the initial state, without restarting the entire simulation platform, thus reducing the time consumption of repeated platform restarts. At the same time, since a debugging task is completed, the firmware corresponding to the debugging task can be deleted from the simulation platform, thus generating an idle Slot. Therefore, the test case execution process notifies the compilation and burning process of the currently idle Slot, and the compilation and burning process compiles and burns new debugging tasks to the idle Slot in the order of task priority, thus realizing the parallel operation of firmware burning and debugging task running, and shortening the time consumed for burning the firmware when the simulation platform switches the debugging task firmware each time.

[0071] It should be noted that the specific type and implementation method of the simulation platform are not particularly limited in this application. It is mainly applied to the SoC simulation platform, which is a tool and environment specifically used for designing and verifying system-on-chip (SoC). It provides engineers with the ability to simulate and test chip designs to ensure that their functions, performance, and reliability meet the expected goals before actual production. Specifically, it can be implemented by means of the ZeBu simulation platform, etc. The specific type and implementation method of the task management server and the environments of each user are not particularly limited in this application.

[0072] SeeFigure 2 As shown Figure 2 This is a schematic diagram of the processing flow of a scheduling system provided by an embodiment of the present invention; the task management server includes a receiving and sorting process, a compilation and flashing process, a use case execution process, and a log distribution process. The SoC simulation platform includes Flash (Flash Memory) and an SoC for simulation. The SoC includes RAM (Random Access Memory), a CPU (Central Processing Unit), a serial port / Trace, and hardware IP (Intellectual Property). Among them, Flash is a non-volatile storage medium based on flash memory technology, and data will not be lost after power failure. It is mainly used to store firmware. Flash includes several firmware partition Slots. Usually, one Slot is used to store one firmware version. RAM is used to temporarily store the data that the CPU needs to process during operation and the processed results. The CPU is the core computing unit of the SoC, responsible for executing various instructions, and completing tasks such as data processing, logical operations, and arithmetic operations. The serial port is used for serial data transmission between the SoC and external devices. The hardware IP is a pre-designed hardware module with specific functions, integrated into the SoC, and provides various rich functions for the SoC.

[0073] Furthermore, based on different execution environments, following the submission of debugging tasks in the user environment, the task management server will describe the specific implementation manners of the present invention in the order of sorting, compiling and flashing, and use case execution of the submitted tasks.

[0074] First, for the user environment, the user only needs to submit a debugging task. Refer to Figure 3 As shown Figure 3 This is a schematic diagram of the data structure of a debugging task provided by an embodiment of the present invention; developers, that is, users of the simulation platform, when they need to perform debugging, can submit a debugging request to the task management server through a task submission script and provide parameter configurations as shown Figure 3 As shown. The meanings of each field are described below.

[0075] Code path: This field specifies the directory path where the code to be debugged by the user is located. The task management server will obtain the source code based on this path for compilation and generation of the firmware. Debug type: The debug type field is used to classify the priorities of various debug tasks. Different priorities correspond to different levels of urgency. For example, the debug type field includes bugfix (high priority), feat (medium priority), and debug (low priority). Among them, bugfix usually refers to faults or problems that need to be urgently fixed in the project and has the highest priority. Such tasks include fixing serious errors to ensure the stability and reliability of the software. Feat refers to the debug requirements for new features, usually including new adaptation functions or enhanced features introduced to the software. Although these tasks are important, their priorities are generally lower than those of urgent bugfixes. The debug type of tasks usually includes adding LOG information, comments, and code optimizations for convenient debugging, and its priority is the lowest. Although they are helpful for improving the development experience, their urgency is much lower compared to issues directly affecting the project progress.

[0076] Path for storing use case results: This field is used to specify the location where the task management server will save the execution results after the corresponding use cases for the user's debug function are triggered. Each debug task submitted by a user should have corresponding execution use cases. After these use cases are executed, the results will be recorded at the specified path. The execution results usually include the pass / fail status of the use cases, as well as LOG and Trace information generated during the execution of the use cases. This information will help the user better analyze and locate problems, and then optimize the software performance or fix potential defects.

[0077] Debug use cases: This field supports the user to submit multiple debug use cases, and the task management server will execute these use cases in the order specified by the user. Through such a design of the debug task data structure, developers can define the debug requirements in detail and ensure that the debug tasks are effectively compiled and executed on the task management server.

[0078] Secondly, for the execution environment of the task management server, it needs to perform the reception sorting of debug tasks and implement the compilation and flashing process and the use case execution process. See Figure 4 as shown Figure 4 is a schematic diagram of the processing flow for generating a task queue and firmware flashing provided by an embodiment of the present invention; after the user submits a debug task, the reception sorting process of the task management server will put the task submitted by the user into the task queue for received tasks, and then sort the task queue according to the priority from high to low and the submission order. Whenever a new user debug task is submitted, the queue will be re-sorted.

[0079] After that, the compilation and flashing process starts. After the compilation and flashing process starts, it first checks whether there is an idle slot in the Flash of the SoC simulation environment. If there is, it takes out the debugging tasks according to the sorted queue order, compiles the debugging code according to the code path in the task data structure, and then flashes it into the idle slot in the simulation environment. At the same time, the compilation and flashing process also sends the flashed slot number and the test cases of the corresponding debugging tasks to the test case execution process for automated execution of the test cases. The compilation and flashing process will repeat the above operations after traversing all the idle slots. When there is no idle slot in the Flash, the compilation and flashing process will enter the sleep state until the test case execution process sends the idle slot number after executing the test cases or the simulation platform has an idle slot due to other reasons. Then the compilation and flashing process restarts, and takes out the debugging tasks that have not been flashed with firmware from the sorted task queue for compilation and flashing.

[0080] See Figure 5 as shown Figure 5 in the schematic diagram of the execution process of a debugging task provided by an embodiment of the present invention; the main implementation process of the test case execution process is as Figure 5 shown. First, based on the communication connection between the task management server and the simulation platform, the test case execution process uses the serial port command to query the slot number currently loaded and running on the simulation platform. This serial port command can be implemented by the SoC firmware running in the simulation platform. The simulation platform records and provides the corresponding serial port command, and the test case execution process directly initiates the corresponding serial port command to execute the query. Then the test case execution process queries and obtains the test case information in the corresponding debugging task according to the obtained slot number. The debugging tasks and the test cases therein can be sent from the compilation and flashing process to the test case execution process. After that, the test case execution process interacts with the firmware running on the SoC simulation platform through the serial port to execute the test cases in the debugging tasks one by one. After the test case is executed, the test case execution process can cooperate with the simulation platform to generate a test case execution report including information such as the name of the test case, the number of executions, time, and passing status, and retrieve the log records corresponding to the executed test case and the Trace information at the corresponding time in the LOG of the simulation platform and / or the task management controller for the user to locate problems. Furthermore, the test case execution report, LOG, and Trace information are sent to the log distribution process, and the log distribution process sends the execution result of the test case to the user environment through the network transmission protocol. Then the test case execution process notifies the firmware running on the SoC simulation platform through the serial port command to initiate the reset of the simulation platform and control the simulation platform to switch to the slot corresponding to the firmware of the next debugging task to continue executing the next debugging task.

[0081] After completing a debugging task, the test case execution process can also send the Slot corresponding to the completed debugging task, which has now become an idle Slot, to the compilation and flashing process to wake up the compilation and flashing process to continue compiling and flashing the idle Slot. In this way, while the compilation and flashing process is flashing the idle Slot, the simulation platform can be loading and running the firmware in other Slots for debugging simulation, changing the firmware flashing and firmware running of multiple debugging tasks from a serial process to a parallel process, and reducing the time consumed for flashing the firmware to the Flash of the simulation platform. Through the above process, the automatic execution of test cases and the automatic switching of Slots in the simulation platform are realized. In this way, the firmware flashing of the simulation platform and the execution of test cases for running the firmware are completely automatically executed by the program, eliminating the manual process of executing test cases and waiting for the results of test case execution, achieving full unattended operation, and improving the debugging efficiency of multi-person collaborative development.

[0082] The present invention proposes a fully automated software debugging method for an SoC simulation platform. Software developers only need to submit debugging tasks to the task management server, and the task management server is responsible for interacting with the SoC simulation platform. Users no longer directly interact with the simulation platform. The task management server compiles code, flashes firmware, and executes test cases according to the priorities of the debugging tasks, and feeds back the execution results to the developers. This method reduces the steps of manually switching the simulation platform, improves the time-sharing reuse efficiency of the simulation platform, and sorts and executes according to the priorities of the debugging tasks, thereby improving the collaborative development efficiency of the software development team. Abstracting the debugging requirements of users for the simulation platform into a unified data structure, it realizes automated compilation and flashing, automated execution of test cases and feedback of results, and the process of automatically switching debugging tasks, reduces the links involving manual participation, realizes unattended operation of the simulation platform for executing debugging tasks, and improves the usage efficiency of the simulation platform and the user experience.

[0083] In some embodiments, the debugging task includes a debugging type field, and the debugging type field is used to define the priority of the debugging task; sorting the received debugging tasks to be executed to obtain a task queue, including:

[0084] If a debugging task to be executed is received, identify the debugging type field of the currently received debugging task;

[0085] Compare the debugging type field of the currently received debugging task with the debugging type fields of the debugging tasks in the current task queue;

[0086] Re-sort all debugging tasks according to the comparison result of the debugging type fields to obtain an updated task queue.

[0087] In practical applications, the usage order of the simulation platform completely depends on the order of submitting debugging tasks, which results in some urgent requests for fault repair not being processed in a timely manner, while some non-urgent debugging or development tasks may occupy the platform for a long time, seriously affecting the development efficiency of the project. Therefore, in the present invention, a debugging type field for defining the priority of debugging tasks is set in the debugging tasks. The task management controller will first sort all received debugging tasks according to the debugging type field. When the debugging type fields are the same, the debugging tasks will be sorted based on the submission order. And every time a debugging task is received, the receiving and sorting process in the task management controller will be triggered once for sorting operations. The specific type and implementation method of the debugging type field are not particularly limited in this application.

[0088] Specifically, by setting the debugging type field, the debugging tasks are divided into different priorities, and the debugging type field is preferentially used to sort the task queue, so that the use case execution process can execute each debugging task according to the priority order of the tasks, avoiding non-urgent or unimportant debugging tasks from occupying the platform for a long time, and realizing the reasonable scheduling of the SoC simulation platform in the project.

[0089] In some embodiments, the debugging task includes a result storage path, which is used to specify the storage location of the debugging execution result; after all debugging use cases in the current task are executed, it further includes:

[0090] Generating a use case execution report for the debugging use case based on the execution information of the debugging use case; the execution information includes the name, execution times, execution time, and passing status of the debugging use case;

[0091] Retrieving the log information of the debugging use case;

[0092] Storing the use case execution report and the log information at the storage location specified by the result storage path of the current task.

[0093] It is not difficult to understand that, in order to facilitate users to query and determine the debugging results, a result storage path field is also set in the debugging tasks. After all debugging use cases of a certain debugging task are executed, the task management server will generate a use case execution report for the debugging use case, and retrieve the corresponding log information, etc., and distribute these to the users corresponding to the debugging tasks and store them at the specified storage location. The specific type and implementation method of the result storage path are not particularly limited in this application. The log information is not only limited to being retrieved from the task management server itself, but can also obtain the execution information of the debugging use case from the simulation platform through the communication connection between the task management server and the simulation platform, and retrieve and obtain the log information, etc.

[0094] Specifically, by setting the result storage path, the task management controller can directly store the case execution information and log information corresponding to the debugging task to the specified storage location. The user can directly obtain the debugging information of the entire debugging task from the storage path, which is convenient for the user to perform operations such as fault troubleshooting, problem diagnosis, and performance analysis, and realizes the recording of the entire debugging process.

[0095] In some embodiments, the debugging task includes a code path field, and the code path field is used to specify the directory path where the code of the debugging task is located; converting the code of the selected debugging task into firmware includes:

[0096] Obtain the source code of the debugging task from the corresponding directory path according to the code path field of the selected debugging task;

[0097] Compile the source code to generate the firmware corresponding to the debugging task.

[0098] It can be understood that, in order to improve the memory usage efficiency in the task management server, a code path field is also set in the debugging task. When the task management server needs to generate and burn the firmware corresponding to the debugging task, it can obtain the source code corresponding to the debugging task according to this field, and then perform operations such as compiling and format conversion on the source code to convert it into firmware. The specific operations and compilation methods for converting the source code into firmware are not particularly limited in this application. The specific type and implementation method of the code path field are not particularly limited in this application.

[0099] Specifically, by setting the code path field to help the task management server obtain the source code corresponding to the debugging task, it avoids a large amount of memory occupation when the debugging task directly carries the source code, and at the same time can also reduce security risks such as data tampering, save the storage resources of the task management server, and improve the memory usage efficiency.

[0100] In some embodiments, converting the code of the selected debugging task into firmware includes:

[0101] Parallelly compile the source codes corresponding to the selected idle number of debugging tasks to convert the codes of each selected debugging task into firmware respectively;

[0102] Burning the firmware into the idle firmware partition includes:

[0103] Parallelly burn the firmware corresponding to the selected idle number of debugging tasks into the corresponding idle firmware partitions.

[0104] It is not difficult to understand that, in order to further reduce the time consumed by firmware flashing, when there are multiple idle Slots in the simulation platform and the codes of multiple debugging tasks need to be compiled and flashed into each idle Slot, the compilation and flashing process can perform parallel compilation of the codes of multiple debugging tasks and parallel flashing of multiple firmwares simultaneously. The specific parallel quantity for parallel compilation and parallel flashing is not particularly limited in this application. It is not limited to the parallel operations of the number of idle quantities pointed out in this embodiment, and the codes of multiple debugging tasks can also be compiled in parallel and multiple firmwares can be flashed in parallel in units of a preset fixed quantity. For example, when the number of idle quantities is 9, they can be processed in groups of 3, and each time, parallel compilation of the codes of three debugging tasks and corresponding parallel flashing of three firmwares are performed.

[0105] Specifically, this embodiment also proposes a method for pre-flashing multiple Slots. Based on realizing the parallel execution of firmware operation and flashing in the SoC simulation platform, thereby reducing the firmware flashing time when switching between different debugging tasks in the simulation environment, a method for multi-Slot preloading is proposed. While realizing the parallel execution of use case execution and firmware flashing, the parallel execution of multiple firmware flashes is realized, further improving the efficiency of firmware flashing.

[0106] In some embodiments, after deleting the current task from the task queue, it further includes:

[0107] Re-determine the firmware partition where the firmware corresponding to the deleted current task is located as an idle firmware partition, and re-jump to the step of determining the number of idle firmware partitions in the simulation platform.

[0108] It can be understood that when a certain debugging task is completed, not only does the task management server need to delete it from the task queue, but the simulation platform also deletes the firmware corresponding to the debugging task from the Slot, that is, the firmware in the firmware partition where the firmware corresponding to the current task is located will be deleted. Therefore, the firmware partition where the firmware corresponding to the current task is located will be restored to an idle Slot again and can be flashed with the firmware corresponding to a new debugging task. Therefore, the use case execution process can directly inform the compilation and flashing process of the partition number of the idle firmware partition.

[0109] Specifically, the use case execution process can directly inform the compilation and flashing process of the vacated idle Slot after the debugging task is completed, triggering the compilation and flashing process directly without the compilation and flashing process actively checking and identifying, further improving the processing efficiency of the task management server for debugging tasks.

[0110] In some embodiments, after flashing the firmware into the idle firmware partition, it further includes:

[0111] Establish a correspondence between the queuing number of the debug task and the partition number of the firmware partition where the corresponding firmware is located; where the queuing number is the sequence number of the debug task in the task queue.

[0112] Before interacting with the firmware corresponding to the current task to execute the debug cases in the current task, it further includes:

[0113] If the firmware corresponding to the current task is burned successfully, send a startup instruction to the simulation platform to control the simulation platform to load and run the firmware corresponding to the current task.

[0114] Query the partition number of the firmware that the current simulation platform is running.

[0115] Based on the correspondence, determine whether the partition number of the firmware that the current simulation platform is running corresponds to the current task.

[0116] If so, jump to the step of interacting with the firmware corresponding to the current task to execute the debug cases in the current task.

[0117] It is not difficult to understand that, in order to facilitate the use case execution process and the simulation platform to accurately call and run the firmware corresponding to the debug task, the compilation and burning process will establish a correspondence between the partition number of the firmware partition and the queuing number of the debug task when burning the firmware; when the use case execution process needs to control the simulation platform to switch to the firmware corresponding to the next debug task after executing a debug task, the firmware in the firmware partition with the corresponding partition number can be run through this correspondence. At the same time, before the use case execution process officially executes the debug cases, query and obtain the partition number of the firmware that the simulation platform is running again to repeatedly confirm whether the firmware running on the simulation platform corresponds to the debug task that is about to be executed. The specific implementation method of this correspondence and the like are not particularly limited in this application and can be implemented through a correspondence table and other means. It should be noted that when the task queue is reordered due to deleting tasks or adding tasks, the queuing numbers in the correspondence also need to be updated accordingly. For example, when the first debug task is executed and deleted from the task queue, the queuing numbers of all debug tasks are reduced by 1. The compilation and burning process can also determine which debug task in the task queue has not had the firmware generated and burned based on this correspondence, which is convenient for the compilation and burning process to manage each debug task.

[0118] As a specific embodiment, when burning and programming the firmware, the compilation and burning process can directly perform the debugging task of corresponding queuing numbering according to the Slot number pre-configured in the simulation platform, that is, the partition number of the firmware partition. That is, the firmware of the first debugging task in the task queue is burned into Slot 1, and the firmware of the Nth debugging task in the task queue is burned into Slot N. Among them, N in Slot N is the partition number of the firmware partition. When the simulation platform detects that the firmware in Slot 1, that is, the firmware burning of the first debugging task in the task queue is completed, the simulation platform will automatically execute the firmware in Slot 1. The test case execution process can directly execute the first debugging task. After the first debugging task is completed, the test case execution process controls the simulation platform to reset. After the simulation platform resets, it directly automatically executes the firmware in Slot 2. That is, the SoC simulation platform loads and runs the firmware one by one according to the order of the partition numbers of the Slots, and automatically executes the firmware in the order from Slot 1 to Slot N. At the same time, after Slot 1 becomes idle, the compilation and burning process will burn the (N + 1)th debugging task in the task queue into Slot 1. That is, the firmware corresponding to the (N + 1)th debugging task to the 2Nth debugging task is also burned into the corresponding Slot 1 to Slot N in turn, and so on for burning. The simulation platform also always switches to execute the next firmware in the order from Slot 1 to Slot N. The simulation platform can also perform the switching of running the firmware after receiving the corresponding switching command from the test case execution process. The switching command includes an identifier, and the identifier is used to specify the partition number of the firmware partition corresponding to the next running firmware. When the test case execution process starts to execute a certain debugging task, it will determine the partition number corresponding to the queuing number of the debugging task according to the corresponding relationship, and then inform the simulation platform of the partition number in the form of an identifier, so that the simulation platform runs the corresponding firmware.

[0119] Specifically, the present invention divides the debugging requirements of the SoC simulation platform into different priorities according to types, and performs the compilation, burning and execution of debugging tasks in the order of priorities. At the same time, the parallel execution of the test case of the debugging task and the firmware burning process and the multi-Slot parallel pre-burning process are combined, effectively improving the working efficiency of the simulation platform. The whole development and debugging process, including compilation and burning, test case execution, feedback of execution results, and switching of debugging tasks, is fully automated without manual participation in the method and process.

[0120] See Figure 6 as shown in Figure 6 is a schematic structural diagram of a scheduling device for software debugging tasks provided by an embodiment of the present invention; to solve the above technical problems, an embodiment of the present invention also provides a scheduling device for software debugging tasks, which is applied to a task management server, and the task management server is connected to the simulation platform; the device includes:

[0121] A sorting unit 11 for sorting the received debug tasks to be executed to obtain a task queue;

[0122] A firmware flashing unit 12 for determining the number of free firmware partitions in the simulation platform, sequentially selecting the number of free debug tasks from the task queue, converting the code of the selected debug tasks into firmware, and flashing the firmware into the free firmware partitions;

[0123] A debug start unit 13 for using the first debug task in the current task queue as the current task;

[0124] A debug execution unit 14 for, if the firmware flashing corresponding to the current task is completed, interacting with the firmware corresponding to the current task to execute the debug cases in the current task;

[0125] A debug switching unit 15 for, after all the debug cases in the current task are executed, deleting the current task from the task queue, controlling the simulation platform to reset, and re-triggering the debug start unit.

[0126] In some embodiments, the debug task includes a debug type field for defining the priority of the debug task; the sorting unit 11 includes:

[0127] A type recognition unit for, if a debug task to be executed is received, recognizing the debug type field of the currently received debug task;

[0128] A comparison unit for comparing the debug type field of the currently received debug task with the debug type fields of the debug tasks in the current task queue;

[0129] A sorting subunit for re-sorting all the debug tasks according to the comparison result of the debug type fields to obtain an updated task queue.

[0130] In some embodiments, the debug task includes a result storage path for specifying the storage location of the debug execution result; the apparatus further includes:

[0131] A report generation unit for generating a use case execution report of the debug cases based on the execution information of the debug cases; the execution information includes the name, execution times, execution time, and pass status of the debug cases;

[0132] A log retrieval unit for retrieving the log information of the debug cases;

[0133] A log distribution unit for storing the use case execution report and the log information at the storage location specified by the result storage path of the current task.

[0134] In some embodiments, the debugging task includes a code path field for specifying the directory path where the code of the debugging task is located; the firmware flashing unit 12 includes:

[0135] A code acquisition unit for acquiring the source code of the debugging task from the corresponding directory path according to the code path field of the selected debugging task;

[0136] A firmware generation unit for compiling the source code to generate the firmware corresponding to the debugging task.

[0137] In some embodiments, the firmware flashing unit 12 includes:

[0138] A parallel compilation unit for parallelly compiling the source codes corresponding to the selected idle number of debugging tasks to respectively convert the codes of the selected debugging tasks into firmware;

[0139] A parallel flashing unit for parallelly flashing the firmware corresponding to the selected idle number of debugging tasks into the corresponding idle firmware partitions.

[0140] In some embodiments, it further includes:

[0141] An idle partition determination unit for re-determining the firmware partition where the firmware corresponding to the deleted current task is located as an idle firmware partition and triggering the firmware flashing unit 12.

[0142] In some embodiments, it further includes:

[0143] A correspondence establishment unit for establishing a correspondence between the queuing number of the debugging task and the partition number of the firmware partition where its corresponding firmware is located; wherein, the queuing number is the sequence number of the debugging task in the task queue;

[0144] A firmware start unit for, before interacting with the firmware corresponding to the current task to execute the debugging use case in the current task, if the firmware corresponding to the current task is flashed successfully, sending a start instruction to the simulation platform to control the simulation platform to load and run the firmware corresponding to the current task;

[0145] A running firmware query unit for querying the partition number of the firmware currently running on the current simulation platform;

[0146] A firmware consistency judgment unit for judging, based on the correspondence, whether the partition number of the firmware currently running on the current simulation platform corresponds to the current task; if so, triggering the debugging execution unit 14.

[0147] For the description of the features in the software debugging task scheduling device provided by the embodiments of the present invention, reference can be made to the relevant descriptions in the embodiments of the software debugging task scheduling method, which will not be elaborated here one by one.

[0148] See Figure 7 as shown Figure 7 which is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. To solve the above technical problems, an embodiment of the present invention also provides an electronic device, including:

[0149] A memory 60 for storing a computer program;

[0150] A processor 61 for executing the computer program to implement the steps of the scheduling method for the software debugging task as described above.

[0151] The electronic device provided in this embodiment may include, but is not limited to, a smart phone, a tablet computer, a notebook computer, or a desktop computer, etc.

[0152] Among them, the processor 61 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 61 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the wake state, also known as the central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 61 may be integrated with a graphics processing unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 61 may further include an artificial intelligence (AI) processor, and the AI processor is used to process computational operations related to machine learning.

[0153] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory, as well as non-volatile memory, such as one or more disk storage devices and flash storage devices. In this embodiment, the memory 60 is at least used to store the following computer program 601. After the computer program is loaded and executed by the processor 61, it can implement the relevant steps of the scheduling method for the software debugging task disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602, data 603, etc., and the storage method may be transient storage or permanent storage. Among them, the operating system 602 may include Windows, Unix, Linux, etc. The data 603 may include, but is not limited to, the data in the scheduling method for the software debugging task, etc.

[0154] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0155] Those skilled in the art can understand that Figure 7 the structure shown in does not constitute a limitation on the electronic device, and it may include more or fewer components than those shown in the figure.

[0156] For the description of the features in the electronic device provided by the embodiments of the present invention, reference may be made to the relevant descriptions in the embodiments of the scheduling method for the software debugging task, which will not be elaborated here one by one.

[0157] It can be understood that if the scheduling method for the software debugging task in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. And the foregoing storage medium includes: USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disc, etc., which can store program codes.

[0158] To solve the above technical problems, an embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the scheduling method for the software debugging task as described above.

[0159] For the description of the features in the computer-readable storage medium provided by the embodiments of the present invention, reference may be made to the relevant descriptions in the embodiments of the scheduling method for software debugging tasks, which will not be elaborated here one by one.

[0160] The embodiments of the present invention further provide a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the scheduling method for software debugging tasks described in the above embodiments are implemented.

[0161] For the description of the features in the computer program product provided by the embodiments of the present invention, reference may be made to the relevant descriptions in the embodiments of the scheduling method for software debugging tasks, which will not be elaborated here one by one.

[0162] The above has introduced in detail a scheduling method, device, equipment, and storage medium for software debugging tasks provided by the embodiments of the present invention. Each embodiment in the specification is described in a progressive manner, and the key point of each embodiment is the difference from other embodiments. The same or similar parts among the embodiments can be referred to each other. For the device disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method part.

[0163] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this article can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0164] The above has introduced in detail a scheduling method, device, equipment, and storage medium for software debugging tasks provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A scheduling method for software debugging tasks, characterized in that Applied to a task management server, the task management server being connected to a simulation platform; the method includes: Sorting the received debug tasks to be executed to obtain a task queue; Determining the number of free firmware partitions in the simulation platform, sequentially selecting the number of free debug tasks from the task queue, converting the code of the selected debug tasks into firmware, and burning the firmware into the free firmware partitions; Taking the first debug task in the current task queue as the current task; If the firmware burning corresponding to the current task is completed, interacting with the firmware corresponding to the current task to execute the debug cases in the current task; After all the debug cases in the current task are executed, deleting the current task from the task queue, and controlling the simulation platform to reset, and re-jumping to the step of taking the first debug task in the current task queue as the current task.

2. The scheduling method for software debugging tasks according to claim 1, wherein The debug task includes a debug type field, and the debug type field is used to define the priority of the debug task; Sorting the received debug tasks to be executed to obtain a task queue, including: If a debug task to be executed is received, identifying the debug type field of the currently received debug task; Comparing the debug type field of the currently received debug task with the debug type fields of the debug tasks in the current task queue; Re-sorting all the debug tasks according to the comparison result of the debug type fields to obtain an updated task queue.

3. The scheduling method of the software debugging task according to claim 1, characterized in that The debug task includes a result storage path, and the result storage path is used to specify the storage location of the debug execution result; After all the debug cases in the current task are executed, it further includes: Generating a case execution report for the debug cases based on the execution information of the debug cases; The execution information includes the name, execution times, execution time, and passing status of the debug cases; Retrieving the log information of the debug cases; Storing the case execution report and the log information to the storage location specified by the result storage path of the current task.

4. The scheduling method for software debugging tasks according to claim 1, characterized in that, The debug task includes a code path field, and the code path field is used to specify the directory path where the code of the debug task is located; Converting the code of the selected debug tasks into firmware, including: Obtaining the source code of the debug tasks from the corresponding directory path according to the code path field of the selected debug tasks; Compiling the source code to generate the firmware corresponding to the debug tasks.

5. The scheduling method for software debugging tasks according to claim 4, wherein Converting the code of the selected debug tasks into firmware, including: Compiling the source codes corresponding to the selected number of free debug tasks in parallel to convert the codes of the respective selected debug tasks into firmware; Burning the firmware into the free firmware partitions, including: Burning the firmware corresponding to the selected number of free debug tasks into the corresponding free firmware partitions in parallel.

6. The scheduling method for software debugging tasks according to claim 1, characterized in that After deleting the current task from the task queue, it further includes: Re-determining the firmware partition where the firmware corresponding to the deleted current task is located as a free firmware partition, and re-jumping to the step of determining the number of free firmware partitions in the simulation platform.

7. The scheduling method of software debugging tasks according to any one of claims 1 to 6, characterized in that After burning the firmware into the idle firmware partition, it further includes: Establishing a correspondence between the queuing number of the debugging task and the partition number of the firmware partition where the corresponding firmware is located; wherein, the queuing number is the sequence number of the debugging task in the task queue; Before interacting with the firmware corresponding to the current task to execute the debugging cases in the current task, it further includes: If the firmware burning of the current task is completed, sending a start instruction to the simulation platform to control the simulation platform to load and run the firmware corresponding to the current task; Querying the partition number corresponding to the firmware currently running on the simulation platform; Based on the correspondence, determining whether the partition number corresponding to the firmware currently running on the simulation platform corresponds to the current task; If so, jumping to the step of interacting with the firmware corresponding to the current task to execute the debugging cases in the current task.

8. A scheduling device for software debugging tasks, characterized in that, Applied to a task management server, the task management server is connected to a simulation platform; the device includes: A sorting unit, configured to sort the received debugging tasks to be executed to obtain a task queue; A firmware burning unit, configured to determine the number of idle firmware partitions in the simulation platform, sequentially select the number of idle debugging tasks from the task queue, convert the code of the selected debugging tasks into firmware, and burn the firmware into the idle firmware partitions; A debugging start unit, configured to use the first debugging task in the current task queue as the current task; A debugging execution unit, configured to, if the firmware burning of the current task is completed, interact with the firmware corresponding to the current task to execute the debugging cases in the current task; A debugging switching unit, configured to, after all the debugging cases in the current task are executed, delete the current task from the task queue, and control the simulation platform to reset, and re-trigger the debugging start unit.

9. An electronic device, characterized in that, It includes: A memory, configured to store a computer program; A processor, configured to execute the computer program to implement the steps of the software debugging task scheduling method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the software debugging task scheduling method according to any one of claims 1 to 7 are implemented.

Images