COOPERATIVE SCHEDULER WITH DETECTION OF A TASK THAT RUNS LONGER THAN AN EXPECTED EXECUTION TIME WITHOUT INTERRUPTING THE EXECUTION OF THE TASK

Abstract

A device comprising a cooperative scheduler for an application task, a timer circuit for detecting an application task that is running longer than its expected execution time without interrupting the task's execution, and a recording circuit for recording that the timer circuit has detected a task running longer than its expected execution time. A method for cooperatively scheduling application tasks that detects an application task running longer than its expected execution time without interrupting the task's execution and records that an overflow has been detected.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS

[0001] This application claims priority over Indian patent application No. 202311019603, filed on March 21, 2023, which is hereby incorporated by reference in its entirety as if it were reproduced here in full. TECHNICAL AREA

[0002] The present disclosure relates to cooperative schedulers and, in particular, to the detection and recording of a “wrong allocation of execution time” task overflow in a cooperative scheduler. BACKGROUND

[0003] The "design recommendation," defined in Annex D, ISO 26262, Part 6:2018, available from the International Organization for Standardization, Geneva, Switzerland, aims to achieve "interference-free operation" between software elements. In the context of "Cooperative Scheduler," the software elements are tasks. One of the identified errors is task overflow, which is described as "incorrect allocation of execution time." A deadman timer or watchdog timer (DMT / WDT) can provide a first line of defense against task overflows, for example, when task execution hangs due to the failure of a hardware module, infinite loops within the task, or other overflows without restriction. Task overflows due to software errors, despite validated allocation of execution time, can be detected by DMT / WDT.Unlike task overflows due to correctly allocated execution time, a task overflow with "incorrect execution time allocation" is a problem with the user's allocation of execution time and could be due to insufficient loop timeout values ​​for hardware access in the tasks, an incorrect baud rate setting, or incorrect synchronization between tasks, all of which are correctable.

[0004] A secondary timer can calculate the execution time of tasks, since the primary timer is used by the cooperative scheduler to execute the tasks. A secondary timer can calculate the execution time of tasks and then detect task overflows, if any, in various ways. To detect task overflows, the secondary timer can use an expected execution time for a specific task. This is entered by the user via a parameter in the software's application programming interface (API). This expected execution time is set as the period of the secondary timer. There are various methods for detecting task overflows.

[0005] One approach is to utilize the secondary timer's interrupt mechanism. If the task execution time exceeds this period, an interrupt is generated to create a task overflow. Unfortunately, the interrupt mechanism can temporarily "pause" task execution, which constitutes a defect according to Annex D of ISO 26262-Part 6. Secondly, the tasks themselves can pause interrupts during the execution of critical code sections (e.g., when reading a value from an analog-to-digital converter (ADC)) to maintain uninterrupted CPU access. Furthermore, the factor by which the task exceeds the expected execution time cannot be precisely calculated due to an intermediate jump to the Interrupt Service Routine (ISR).

[0006] A second method can configure a secondary hardware timer (if available) and set its period to match the "expected execution time" of the task. A secondary timer is used in both this second and first methods. The difference is that the first method generates an interrupt to create a timer overflow, while the second method does not generate an interrupt but instead detects the timer overflow status in the hardware register bit of the secondary timer module. Interrupts are typically enabled, so when the period matches, an interrupt is triggered, and the corresponding interrupt service routine (ISR) is started to register the overflow. However, similar to the first method, this method also blocks task execution.Since interrupts partially pause code execution, this approach is impractical. To mitigate the problem of interrupts partially pausing code execution, the tasks themselves can disable interrupts as part of the execution of priority code sections. Therefore, if an overflow occurs during the execution of a priority code section, the overflow event can be overlooked.

[0007] A third method can use the secondary timer in a non-interrupt mode and check the timer overflow interrupt flag in the interrupt status register once task execution is complete. A set flag indicates a task overflow. However, the interrupt status register can have both read and write access. If the application task clears the secondary timer overflow interrupt flag in the interrupt status register, the overflow status may be lost.

[0008] A fourth method uses the timer difference method to configure an additional hardware timer and set its period to match the expected execution time of the task. The timer is started, and its value is recorded before and after task execution. If task execution resumes after the rollover, the timer is reset and starts counting from zero (0). However, this method does not distinguish between a simple difference between the two timer values ​​and the difference after a rollover event. Distinguishing between the simple difference and the difference after a rollover can be difficult because both are positive values.

[0009] Software applications that utilize the mechanisms and functions provided by the cooperative scheduler must execute tasks within defined timeframes. The software applications provide task definitions, and the cooperative scheduler provides the mechanisms for task execution. Tasks voluntarily relinquish central processing power (CPU) resources to ensure that other tasks do not incur CPU resource demands. Since the scheduler does not block task execution, task execution should flag overflows, which should then be reported to the application by the cooperative scheduler. Currently available methods are either invasive, temporarily blocking task execution to report the overflow, or they fail to provide clear results.

[0010] There is a need for a cooperative scheduler that reports a task overflow (incorrect allocation of execution time) without interrupting the execution of the task. SUMMARY

[0011] According to an example, a device is provided which includes: a cooperative scheduler for a task of an application; a timer circuit to capture a task of an application that runs for longer than an expected execution time for the task without interrupting the execution of the task; and a recording circuit to record that a task that runs for longer than an expected execution time has been captured by the timer circuit.

[0012] Another example features a procedure that includes: cooperative scheduling of tasks of an application; detecting a task of an application that is running for longer than an expected execution time for the task without interrupting the execution of the task; and recording that a task running for longer than an expected execution time has been detected.

[0013] According to an example, a system is provided that includes: a cooperative scheduler for tasks of an application; a timer circuit; a recording circuit; a memory for storing instructions to operate the cooperative scheduler, the timer circuit, and the recording circuit; and a processor coupled to the memory to execute the instructions to cause: the cooperative scheduler to schedule tasks of an application; the timer circuit to detect a task of an application that is running longer than an expected execution time for the task, without interrupting the execution of the task; and the recording circuit to record that a task running longer than an expected execution time has been detected by the timer circuit. BRIEF DESCRIPTION OF THE FIGURES

[0014] The figures illustrate exemplary cooperative schedulers that register a task overflow with "incorrect execution time allocation" when the task exceeds its expected execution time, without interrupting the task's execution. Exemplary cooperative schedulers can also inform the application that defines the task about the "incorrect execution time allocation" task overflow and provide the application with a correction factor for the expected task execution time. Fig. Figure 1 shows a block diagram of a system for executing tasks of an application, scheduled by a cooperative scheduler, a timer circuit and a recording circuit for detecting and recording when a task is executed for longer than an expected execution time. Fig. Figure 2 shows a more detailed block diagram of a system than in Figure 2. Fig. Figure 1 shows a cooperative scheduler, a timer circuit, a recording circuit, a correction circuit, and an application programming interface. Fig. Figure 3 shows a flowchart of the operation of the [system / device / etc.] in [location / etc.]. Fig. 1 systems shown and Fig. Figure 4 shows a block diagram of an alternative timer circuit. Fig. Figure 5 shows a flowchart of the operation of a system that uses the timer circuit of Fig. 4. Fig. Figure 6 shows a procedure for the cooperative planning of tasks, for the detection of task overflows and for recording the detected overflows. Fig. Figure 7 shows a block diagram of a device that includes a cooperative scheduler, a timer circuit, and a recording circuit. Fig. Figure 8 shows a block diagram of a system that includes a processor, a memory, a cooperative scheduler, a timer circuit, and a recording circuit.

[0015] The reference signs for each illustrated element that appears in several different figures have the same meaning in all figures, and the mention or discussion of an illustrated element in connection with one particular figure also applies to any other figure in which the same illustrated element is shown. DETAILED DESCRIPTION

[0016] One aspect provides a cooperative scheduler that detects an incorrect execution time allocation task overflow without interrupting task execution. The cooperative scheduler detects when a task has run longer than expected, records that the task has run longer than expected, and notifies the application that defines the task of an incorrect execution time allocation task overflow without interrupting task execution. According to one aspect, a cooperative scheduler provides the application that defines the task with a correction factor to apply to the expected execution time. The cooperative scheduler may include a correction circuit to adjust the expected execution time by adding a correction factor based on the time the task is executed after an incorrect execution time allocation task overflow has been recorded.The cooperative scheduler can include a timer circuit to record the execution time of the task.

[0017] An aspect identifies erroneous expected execution time allocations and provides a correction factor when the expected execution time allocation is less than the actual execution time. Instead of interrupting a task that is running longer than expected, the actual execution time can be captured, and then a correction factor can be statically applied in the form of an "increased expected execution time." An aspect provides a procedure that detects erroneous execution time allocations for task overflows, records the detected overflows, and notifies the user so that they can adjust the task's expected execution time or modify the task implementation to ensure the task's execution time falls within the expected timeframe. A correction factor for a task overflow can be provided to the user as information.The correction factor can be applied by the user to change the expected execution time and entered via the same application programming interface (API) that the user initially used to enter the expected execution time for the task. Alternatively, the user can also revise the task for faster execution.

[0018] For example, a user initially enters an expected execution time of 100 microseconds for a specific task via the API. However, the actual CPU time required to execute the task is 120 microseconds. The user is informed that the task exceeded the expected execution time by 20 microseconds. The user can then use the same API again to enter a revised expected execution time of 120 microseconds for the task. A correction factor can be the actual execution time divided by the expected execution time. In this example, the correction factor can be 120 microseconds divided by 100 microseconds, resulting in a correction factor of 1.2 (CF = 1.2). The correction factor can be multiplied by the originally expected execution time to provide a revised expected execution time.Alternatively, the user can examine the task to determine where the additional 20 microseconds are being consumed and make appropriate changes to the task so that the CPU can complete the task in less than 100 microseconds.

[0019] These aspects can be implemented as a function in a cooperative scheduler to monitor task execution time. Annex D of Part 6 of ISO 26262:2018 describes the "noiselessness" of software elements (tasks) used in applications running on a CPU device that aim to comply with functional safety. "Incorrect execution allocation" is a defect in this annex for software elements (tasks). An aspect provides the application that defines a task running on a CPU device with a task overflow update for its allocated execution time. Detecting this task overflow can provide compliance with ISO 26262.

[0020] In one example, a task overflow can be identified and recorded using a combination of a timer circuit and a recording circuit. From the software's perspective, the "expected execution time" for each task is passed as user input to the application, which defines the task on a CPU device via an application programming interface (API). The timer circuit can be configured in a timer mode (e.g., interrupts disabled or not enabled, since the function can also operate without interruptions), where the "expected execution time" is entered as a timer period. Before the task is executed, a timer in the timer circuit is started, for example, by setting a start bit in a start register of the timer circuit via task monitoring software code of the cooperative scheduler or a correction circuit. If a rollover occurs, i.e.,If the counter register matches the expected execution time in a period register, a detection output for the timer rollover can be provided in a hardware register of the timer circuit. The timer rollover detection output can be a pulse output. However, a pulse output cannot be detected independently because the signal is neither output to an I / O pin nor can it be recorded in a special function register (SFR) of the timer circuit. Therefore, a recording circuit can detect the timer rollover event by inputting a detection output bit into a recording register (a special function register (SFR)) of the recording circuit.

[0021] Since user tasks scheduled for CPU execution by a cooperative scheduler have full, uninterrupted access to the CPU, they should complete their execution within their expected execution time. If, for any reason, a task fails to meet its expected execution time, a procedure is provided to inform the user that a particular task has exceeded its expected execution time. The time allocated to a task (expected execution time) can be used as user input. Because tasks have uninterrupted access to the CPU, they must not be interrupted by other tasks or interrupts. In such a scenario, a procedure for recording task overflows without interrupting task execution can enable more efficient application performance.This can be important when used in conjunction with a functional safety-compliant cooperative scheduler.

[0022] Circuits are provided that can be implemented by instructions for execution by a processor, an analog circuit, a digital circuit, control logic, digital logic circuits programmed by a hardware description language, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), or any suitable combination thereof, whether in a single device or distributed across multiple devices. Circuits can be implemented by instructions executed by a processor, such as a function, an application programming interface (API) call, a script, a program, compiled code, interpreted code, a binary file, an executable file, firmware, an object file, a container, assembly code, or an object.For example, circuits can be implemented by instructions stored in a non-transitory medium such as memory, which, when loaded and executed by a processor (or other suitable method), produce the functionality of the circuits described here.

[0023] Fig. Figure 1 shows a block diagram of a system for executing tasks of an application, which is time-controlled by a cooperative scheduler 110, a timer circuit 120, and a recording circuit 130 for detecting and recording when a task runs for longer than its expected execution time. The system also includes an application 100, a correction circuit 140, an application programming interface 150, and a processor (CPU) 106. The application 100 can contain multiple tasks 102i to 102n. The timer circuit 120 can detect an overflow of a task 102i to 102n of the application 100 that takes longer than its expected execution time without interrupting the task's execution. The recording circuit 130 can record that an overflow has been detected by the timer circuit 120.Correction Circuit 140 allows a user to correct or revise the expected execution time using a correction factor after an overflow has been detected. Correction Circuit 140 can be a combination of hardware and software, purely hardware, or purely software, without restriction. A correction factor can be the remaining time until a task completes after a rollover event, the execution time for a task, or a multiplier of the originally entered expected execution time. Correction Circuit 140 provides the user of the application with a correction factor via the application programming interface (API) circuit 150. The user can also use API circuit 150 to provide the expected execution time to Timer Circuit 120, regardless of whether it has been corrected by a correction factor or not.The user can provide an update that responds, at least partially, to the correction factor. For example, correction circuit 140 can adjust the expected execution time by adding the time the task takes to execute after an overflow is detected to the expected execution time.

[0024] Fig. 2 shows a more detailed block diagram of several in Fig. Figure 1 shows components for detecting a task overflow. A cooperative scheduler 210 provides a task start indication and a task end indication to a correction circuit 240. Upon receipt, the correction circuit 240 provides a corresponding start bit in the start register 228 in response to the task start indication and an end bit in the end register 229 of the timer circuit 220 in response to the task end indication. The correction circuit 240 also receives an expected execution time from a user via an application programming interface 250 and enters the expected execution time into an expected execution time register 224 of the timer circuit 220. A timer circuit 220 includes a time base generator 221, a timer 222, a timer counter register 223, an expected execution time register 224, a start register 228, an end register 229 and a comparator 225.Timer 222 acts as a controlled clock generator, responding to the start register 228 and the end register 229, and incrementing the timer counter register on a predetermined edge of a clock provided by the timebase generator 221. The timebase generator 221 is part of a hardware module that provides the clock for counting timer 222. The timebase generator 221 can use clock signals available on the microcontroller, including a system clock and other on-chip oscillator sources, as well as external clock inputs. A recording circuit 230 can include a D flip-flop with set and reset inputs. The recording circuit 230 can be a configurable module and have a configuration in which the inputs can be controlled by software. The recording circuit 230 can be implemented as hardware and provide the S, R and D inputs 231, 232 and 233 respectively with the software values ​​0, 0 and 1 respectively, as shown in . Fig. 2 shown.

[0025] A detection output 226 of the timer circuit 220 can be fed as a clock input 234 into the D flip-flop of the recording circuit 230. A timer rollover can occur on various occasions. For example, when the timer counter register 223 reaches the value FFFF (hexadecimal), the timer counter register 223 can switch to 0000 (hexadecimal). According to another example, if the Expected Execution Time Register 224 contains the expected execution time (e.g., 1234 (hexadecimal)) when the Timer Counter Register 223 counts up from 0000 (hexadecimal) until it matches the Expected Execution Time Register 224 (e.g., 1234 (hexadecimal)), then a comparator 225 signals to a reset / trigger control 227, and the reset / trigger control 227 resets the Timer Counter Register 223 to 0000 (hexadecimal) or performs a rollover.The reset / trigger control 227 monitors the value in the timer counter register 223 and receives output signals from the comparator 225. It uses this information to determine whether the value in the timer counter register 223 has rolled over to 0000 (hexadecimal) or to reset the value in the timer counter register 223. On each rollover or reset of the timer counter register 223, the reset / trigger control 227 can generate a pulse detection output 226, which is fed as a clock input 234 to the D flip-flop of the recording circuit 230. This clock pulse locks the logic input fed into the D input 233, which is logic high and appears at the Q output 235. This logical output can be read directly as a recognition output bit from the recording register 236 present in the recording circuit 230 as soon as the task execution is complete.The overflow of the expected execution time register can thus be recorded in the recording register 236 while the task executes without interruption. Two overflows can trigger a watchdog reset. Since task execution is not interrupted, the calculation of the execution time can also be easily recorded, both in the case of an expected overflow of the execution time register and in the case of an expected non-overflow of the execution time register. The correction factor in the form of the overrun time for the task can be provided to the user. The expected execution time can be corrected, or in some cases, suitable changes can be made to the task implementation so that the task can be completed within the expected execution time. The detection output 226 can also be read from the recording register 236 and provided to the correction circuit 240.The correction circuit 240 can also read the current execution time from the timer counter register 223 of the timer circuit 220. The correction circuit 240 can calculate a correction factor and provide it to the user via the application programming interface 250.

[0026] Fig. Figure 3 shows a flowchart for detecting a task overflow via the in Fig. 2. Timer circuit shown. An execution time expected by the user is entered into the Expected Execution Time register 302, and the Timer Counter register is set to zero. The Start register 304 is checked to see if it contains a start bit indicating that a task has begun execution. If no, the circuit returns and checks again for the start bit 304. If yes, the End register 306 is checked to see if it contains an end bit indicating that the task has finished. If no, the timer increments the Timer Counter register 308. The expected execution time in the Expected Execution Time register is compared to the value in the Timer Counter register 310 to determine if they are equal.If YES, the reset / trigger control generates a detection output 312, the detection output is recorded 314, the value in the timer counter register is reset to zero (0) by the reset / trigger control 315, and the process returns to recheck the end register 306. If NO, i.e., the expected execution time in the expected execution time register is not equal to the value in the timer counter register, the process returns to recheck the end register 306. If the end register is checked 306 and it is found to have an end bit indicating that the task has finished executing, then 316 the process checks if there is a detection output in the record register. If NO, the process terminates. If YES, the correction circuit reads the elapsed execution time from the timer counter register.The correction circuit then calculates a correction factor (320) based on the expected execution time, the elapsed execution time, and the detection output in the recording register, which indicates a rollover event. The correction circuit then communicates the correction factor (322) to the user via the application programming interface.

[0027] Fig. Figure 4 shows an alternative timer circuit 420. This timer circuit 420 operates with a cooperative scheduler, an application programming interface, and a recording circuit as shown in Fig. 2 shown, but in Fig. 4 not shown. The timer circuit 420 has a start register 428, an end register 429, a timer counter register 423 and an expected execution time register 424, similar to the one in Fig. The timer circuit 220 is shown in Figure 2. The timer circuit 420 also has a time base generator 421, similar to the one in Figure 2. Fig. The timer circuit 220 is shown in Figure 2. The timebase generator 421 can provide a timebase or clock for the rest of the timer circuit 420 by using clock signals available on a microcontroller. This serves as the timebase for the timer circuit 420 without relying on any other on-chip timer circuit. The timebase generator 421 can have up to eight clock inputs available, including a system clock and other on-chip oscillator sources. Depending on the device, external clock inputs may also be available. A prescaler can divide the selected clock source to a suitable frequency for use by the timer circuit 420. The timebase generator 421 can synchronize its operation with the selected clock source, subject to input timing constraints or the operating conditions of the circuit. Setting a timer synchronization bit can enable synchronization of the timebase with the clock input.

[0028] However, timer circuit 420 does not have a comparator, and timer 422 counts down to zero (0) instead of counting up from zero (0). A reset / trigger controller 427 reads the expected execution time from the expected execution time register 424 and writes this value to the timer counter register 423, which then begins counting down from the expected execution time. The reset / trigger controller 427 first writes the expected execution time to the timer counter register 423, and the timer counter register 423 decrements the value according to a clock signal from the time base generator 421 until it reaches zero (0). When the timer counter register 423 reaches zero (0), the reset / trigger control 427 receives this information from the timer counter register 423 and generates a detection output 426 indicating that the execution of the task has exceeded the expected execution time.The recognition output 426 can be sent to a recording circuit, as shown in . Fig. 2 shown, but in Fig. Figure 4 is not shown. The reset / trigger control 427 rolls over the timer counter register 423 by re-entering the expected execution time from the expected execution time register 424 into the timer counter register 423, which again counts down to zero (0). When the end bit is entered into the end register 429 by the correction circuit 440, the timer circuit 420 stops decrementing, and the correction circuit 440 reads the execution time from the timer counter register 423. If the counter register 427 has a rollover of the expected execution time, the correction circuit 440 calculates a correction factor equal to the expected execution time minus the countdown execution time. In this case, the correction factor is the time the task ran beyond the expected execution time.The correction circuit 440 can transmit the correction factor to a user via an application programming interface (not shown). If the recording register 236 does not show an overrun of the expected execution time, the correction factor does not need to be calculated. Alternatively, if the recording register 236 does not show a rollover of the expected execution time register, the countdown execution time from the timer counter register 423 can be reported as available time not used by the task.

[0029] Fig. Figure 5 shows a flowchart for task overflow detection via the in Fig. 4. Timer circuit shown. A user-expected execution time is entered into the Expected Execution Time register 502. The user's expected execution time is also entered into the Timer Counter register 503. The Start register 504 is checked to see if it contains a start bit indicating that a task has begun execution. If NO, 504 returns and checks again for the start bit. If YES, the End register 506 is checked to see if it contains an end bit indicating that the task has finished. If NO, the Timer Counter register 508 is decremented according to a clock signal from the timebase generator. The value in the Timer Counter register 510 is checked to see if it is equal to zero (0).If YES, a detection output 512 is generated. The detection output is recorded by a recording circuit 514. The value in the timer counter register 515 is reset to the expected execution time, which is obtained from the expected execution time register. The process then returns to check the end register again 506. If NO 510, the value in the timer counter register is not zero (0). The process then returns to check the end register again 506. If the end register 506 is checked and it is found to have an end bit indicating that the task has finished executing, then 516 the process checks if there is a detection output in the recording register. If NO, the process terminates. If YES, the correction circuit reads the countdown execution time from the timer counter register.The correction circuit then calculates a correction factor (520) based on the expected execution time, the countdown execution time, and the detection output in the recording register. The correction circuit then communicates the correction factor (522) to the user via the programming interface.

[0030] An alternative timer circuit can increment the timer counter register according to the timebase generator before, during, and after task execution. The timer circuit can also reset the timer counter register to zero (0) when it reaches the estimated execution time and generates a detection output. The correction circuit can read the value of the timer counter register when the start bit is entered into the start register. Conversely, the correction circuit can read the value of the timer counter register when an end bit is entered into the end register. The correction circuit can check for a detection output indicating a rollover during task execution. If a rollover is indicated by a detection output, the correction circuit can determine that the total execution time of the task is equal to the expected execution time plus the difference between the values ​​of the timer counter register at start and end.If no rollover is specified, the correction circuit can determine the task's execution time to be equal to the difference between the timer counter register values ​​at start and end. Safety mechanisms in the cooperative scheduler can provide a watchdog reset if the task requires at least twice the expected execution time.

[0031] The identification of the task overflow (rollover event) can be recorded in the background while CPU 106 is busy executing tasks 102i to 102n. See Fig. 1. Task overflows (rollover events) can be identified and recorded in software or hardware, indicating whether the task has overflowed or not. Overflows can be recorded in hardware by setting a detection output in a hardware register, where the detection output can be a binary bit (high or low) recorded in a register. Timer circuit 120 can identify task overflows (rollover events). The expected execution time can be loaded into an expected execution time register 224 (see Fig. 2), either before or during the execution of the task by CPU 106. See Fig. 1. Alternatively, a timer with an expected execution time can be loaded and the timer can have a countdown to zero (0), after which it generates a rollover pulse indicating that a task has been running for longer than the expected execution time.

[0032] Examples can record task overflows in hardware without software intervention. Hardware examples can measure the elapsed execution time by incrementing or decrementing the timer counter register, record the overflow (detection output), and then store the detection output as a bit in a hardware recording register. See Fig. 2. The detection output 226 can be stored in the hardware record register without CPU intervention and during task execution. Examples may also have no external hardware connections (using external pins) to store the detection output in the hardware register. The signals can be routed internally, and the overflow status can be captured or recorded as data in a memory (not shown). As in Fig. As shown in Figure 2, the detection output 226 of the timer circuit 220 is sent to the recording circuit 230, and the Q output 235 of the recording circuit 230 is available in the recording register 236.

[0033] Examples can also include software routines that are part of a functionally safe cooperative scheduler and are used in applications running with that cooperative scheduler. The algorithms can prevent execution blockages, deadlocks, livelocks, or incorrect allocation of execution time.

[0034] Task execution monitoring can be performed for individual tasks. After a task has finished executing, it is determined whether that task has exceeded its expected execution time. Exceeding the execution time can be detected for each individual task as soon as it has completed its execution.

[0035] Fig. Figure 6 shows a flowchart for a procedure. It is observed that a task of an application runs for longer than the expected execution time without interrupting the task's execution. The task, which has a longer than expected execution time, is recorded. Alternative examples of the procedure can notify a user of task overflows (rollover events) beyond an expected execution time for the task, so that the user can correct the expected execution time using a correction factor. The user can correct the expected execution time for a particular task using the correction factor, thus resolving the problem of misallocating execution time.

[0036] Detecting and correcting an expected execution time can involve identifying extreme task overflows (e.g., stuck execution due to hardware errors, infinite loops within the task) and mitigating these extreme overflows using a watchdog timer or a dead-man timer, which can still occur even after a correct expected execution time has been assigned. A task overflow (rollover event) exceeding an incorrectly assigned expected execution time can be caused by an insufficient loop timeout, an incorrect baud rate, or incorrect synchronization between software elements. These overflow causes are typically correctable.

[0037] A cooperative scheduler can use a primary timer to execute tasks periodically. An additional, or secondary, timer can monitor task execution time and overflow. The secondary timer can be a timer circuit operating in timer mode. The expected execution time for the task can be entered by a user as the period of this secondary timer.

[0038] With reference to Fig. The expected execution time is the value in the expected execution time register 224, which is compared to the current execution time in the timer counter register 223. If the current execution time in the timer counter register 223 matches the expected execution time in the expected execution time register 224, the time for the task has presumably expired, but has not finished, because the end bit has not been stored in the end register 229. For example, if the expected execution time of a particular task is 100 microseconds, this expected execution time can be set in the expected execution time register 224. When the timer 222 is started by entering a start bit into the start register 228, the value in the timer counter register 223 is zero (0), and the timer 222 increments the timer counter register 223 periodically in response to time signals received from the time base generator 221.The comparator 225 compares the current execution time in the timer counter register 223 with the expected execution time in the expected execution time register 224. If they are equal, the comparator 225 generates a detection output 226, and the value in the timer counter register 223 is reset to zero (0) by the reset / trigger control 227. As long as the timer 222 is not stopped by the input of an end bit in the end register 229, the timer counter register 223 performs a rollover and continues counting from zero (0) until the next match with the expected execution time in the expected execution time register 224 or an end bit is input in the end register 229. Security mechanisms in the cooperative scheduler can provide a watchdog reset if the task runs for more than twice the expected execution time, with the watchdog timeout being set to twice the expected execution time of the task.

[0039] Alternatively, with reference to Fig. 4. A timer can be loaded with a value corresponding to an expected execution time for a task, and the timer can generate a rollover when the timer reaches "zero".

[0040] With reference to Fig. 2. If a timer overflow is indicated due to a task overflow, a detection output 226 can be captured or recorded by the timer circuit 220 from the recording circuit 230.

[0041] The pulse generated by the detection output 226 of the timer circuit 220 can be a pulse. To capture this pulse, the detection output 226 can be routed from the timer circuit 220 to the recording circuit 230. The recording circuit 230 can be implemented as a D flip-flop, with the detection output 226 being fed to the clock input of the D flip-flop so that the pulse can generate a predefined output from the D flip-flop. In one example, the predefined output of the D flip-flop in response to a pulse output from the detection output 226 is a logic HIGH output. In the absence of a pulse output from the detection output 226, the output of the D flip-flop is the opposite of the predefined output, which in this example is a logic LOW output. The output of the D flip-flop of the recording circuit 230, i.e. the Q output 235, can be captured in one bit of the recording register 236 (see Fig. 2), as shown in TABLE 1. Once the task execution is complete, the bit can be read to check if the timer overflows, which in turn indicates a task overflow (rollover event). One advantage of this method is that the detection of the timer overflow occurs seamlessly while the task executes without interruption. TABLE 1 Erkennungsausgabe-Bit AUSGANGSSIGNAL 0 Kein Rollover 1 Rollover

[0042] With reference to Fig. 2. The timebase generator 221 can provide a timebase or clock source for the rest of the timer circuit 220 by using clock signals available on a microcontroller. This serves as the timebase for the timer circuit 220 without relying on any other on-chip timer circuit. The timebase generator 221 can have up to eight clock inputs available, including a system clock and other on-chip oscillator sources. Depending on the device, external clock inputs may also be available. A prescaler can divide the selected clock source to a suitable frequency for use by the timer circuit 220. The timebase generator 221 can synchronize its operation with the selected clock source, subject to the limitations of the input timing or the operating conditions of the circuit. Setting a timer synchronization bit can enable synchronization of the timebase with the clock input.

[0043] The timer circuit 220 can generate a detection output 226 when the value in the timer counter register 223 equals the expected execution time register 224 and a rollover of the timer counter register 223 occurs. The detection output 226 can be provided to other circuits as a synchronization source or to cause another peripheral to take action in response to a rollover event. The detection output 226 can be separate from the interrupts of the device 220 of the timer circuit or other outputs. The timer circuit 220 can be a configuration of a capture-compare pulse-width modulation (CCP) recording circuit.

[0044] The recording circuit 230 can be configured as a clocked D-latch with Set (S) 231 and Reset (R) 232. A detection output 226 can be a low-to-high pulse and can be captured by the recording circuit 230 as a bit stored in the recording register 236 and output by the recording circuit 230 as a Q output 235 to the correction circuit 240. The correction circuit 240 can provide the user with a correction factor and receive an expected execution time via the application programming interface 250. The correction circuit 240 can provide the expected execution time, a correction factor, or a value representing a combination of the expected execution time and the correction factor to the expected execution time register 224 of the time switch 220 from the user.

[0045] With reference to Fig. 2. The correction circuit 240 can store an expected execution time in the expected execution time register 224. The timer circuit 220 can be implemented by a circuit configured in timer mode, without interrupts, with an expected execution time, i.e., the time that is loaded into the expected execution time register 224. Whenever a task is executed, the timer 222 is started by setting a start bit in a start register 228, and when the current execution time of the task (stored in the timer counter register 223) matches its expected execution time (stored in register 224 for the expected execution time), a timer rollover occurs, triggered by the reset / trigger control 227, because the expected execution time (stored in register 224 for the expected execution time) matches the current execution time (in the timer counter register 223).The reset / trigger controller 227 generates a detection output 226, which produces the detection output pulse 226. As shown in Table 1, the Q output 235 is low when the bit of the counter register 236 is "0" to indicate no rollover. When the bit of the record register 236 is "1", the Q output 235 indicates a rollover. The detection output 226 is fed to the record circuit 230 in a D flip-flop configuration so that the pulse is captured or recorded in the record register 236, and the record circuit 230 outputs a Q output 235 to the correction circuit 240. Once the task has finished executing, the bit stored in the record register 236 indicates any task execution overflow. Task execution is not interrupted, and any overflows are captured or recorded.After the overflow has been detected or recorded, the current execution time can be read from the timer circuit 220 by the correction circuit 240. Based on a Q output 235 and the execution time value, the correction circuit 240 can calculate a correction factor. The correction circuit 240 can then report this correction factor, which indicates that a task overflow has occurred, to a user via an application programming interface (API) 250. The user can correct the execution time allocation using this correction factor and input a revised expected execution time into the correction circuit 240 via API 250. The user can adjust the expected execution time for a specific task using the correction factor, thus resolving the problem of incorrect execution time allocation.The correction factor can be communicated to the user, allowing them to decide whether to apply it. The correction factor can be the total execution time minus the expected execution time, or it can be the remaining time until a task completes after a rollover event, the execution time for a task, or a multiple of the originally entered expected execution time. The user can use the correction factor to make changes to the task code to ensure task execution occurs within the expected time, or to modify the expected execution time itself. The correction is not applied dynamically during task execution. Using this correction factor can resolve the "incorrect execution time allocation" issue for a task.

[0046] Aspects identify task overflows and provide the user with a correction factor, allowing adjustments to ensure tasks execute correctly within the expected timeframe. By providing this correction factor, the user can resolve the application's "incorrect execution time allocation" problem.

[0047] If the task completes its execution before the expected time, there is no timer rollover. Q output 235 does not output a pulse, and the bit in recording register 236 is not set. However, if the task exceeds the expected execution time, execution is not interrupted. Instead, the detection output 226 provides a pulse, which is detected by the bit in recording register 236 of the recording circuit 230 as Q output 235. Once task execution is complete, the bit is checked for a detection output.

[0048] The timer circuit, the recording circuit, the correction circuit, the scheduler circuit, and the API circuit can each be implemented by instructions executed by a processor, an analog circuit, a digital circuit, control logic, digital logic circuits programmed via a hardware description language, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), or any suitable combination thereof, whether in a single device or distributed across multiple devices. The circuits can each be implemented by instructions for execution by a processor, e.g.,through a function, an API (Application Programming Interface) call, a script, a program, compiled code, interpreted code, a binary file, an executable file, firmware, an object file, a container, assembly code, or an object. For example, the circuits can each be implemented by instructions stored in a non-transient medium such as memory, which, when loaded and executed by a processor (or other suitable method), bring about the functionality of the circuits as described here.

[0049] Fig. Figure 7 shows a block diagram of a device comprising: a cooperative scheduler 702, a timer circuit 704 for detecting an overflow of a task of an application that runs longer than an expected execution time for the task without interrupting the execution of the task; and a recording circuit 706 for recording that an overflow has been detected by the timer circuit. Fig. Figure 8 shows a block diagram of a system that includes: a cooperative 802 scheduler for tasks of an application; a timer circuit 804; a recording circuit 806; a memory 810 for storing instructions for operating the cooperative scheduler 802, the timer circuit 804, and the recording circuit 806; and a processor 808 coupled to the memory 810 for executing the instructions to cause the cooperative scheduler 802 to schedule tasks of an application; to cause the timer circuit 804 to detect an overflow of a task of an application that is running longer than an expected execution time for the task, without interrupting the execution of the task; and to cause the recording circuit 806 to record that an overflow has been detected by the timer circuit 804.

[0050] Although the above examples represent embodiments, other variations and embodiments may be derived from this disclosure without departing from the spirit and scope of protection of these embodiments. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] IN 202311019603

[0001]

Claims

[1] Device comprising: a cooperative scheduler for a task of an application; a timer circuit to detect that an application task is running longer than the expected execution time for the task, without interrupting the task's execution; and a recording circuit to record that the application's task has been detected by the timer circuit and is running for longer than the expected execution time for the task. [2] Device according to claim 1, comprising a correction circuit to correct the expected execution time by adding a correction factor based on the time it takes to execute the task after an overflow has been detected. [3] Device according to one of claims 1 to 2, wherein the timer circuit serves to record an execution time of the task. [4] Device according to any one of claims 1 to 3, wherein the timer circuit increments a timer counter when the task is executed, and compares the timer counter with the expected execution time for the task and has a detection output when the timer counter and the expected execution time are equal, wherein the detection output is recorded by the recording circuit to record that the task of the application was detected by the timer circuit as being executed for longer than the expected execution time for the task. [5] Device according to any one of claims 1 to 4, wherein the timer circuit decrements a timer counter from the expected execution time towards zero (0) when the task is executed, and has a detection output when the timer counter is equal to zero (0), wherein the detection output is recorded by the recording circuit to record that the task of the application was detected by the timer circuit as being executed for longer than the expected execution time for the task. [6] Device according to any one of claims 1 to 5, wherein the timer circuit comprises: a time base generator; a timer; a timer counter register to store timer counter values ​​when the task is executed; an expected execution time register to store an expected execution time for the task; and wherein the timer circuit serves to generate a detection output based on a timer counter value stored in the timer counter register, the detection output being recorded by the recording circuit to record that the application's task was detected by the timer circuit as having been executed for longer than the expected execution time for the task. [7] Device according to any one of claims 1 to 6, which has an application programming interface to provide the expected execution time for the timer circuit and to enable a user to provide a corrected expected execution time for the timer circuit. [8] Device according to any one of claims 1 to 7, wherein the recording circuit serves to detect a pulse signal from the timer circuit, wherein the pulse signal output corresponds to a detection of a task overflow. [9] Device according to any one of claims 1 to 8, wherein the timer circuit serves to record an execution time of the task and has a correction circuit to calculate a correction factor on the basis of the expected execution time and the elapsed execution time. [10] Method which features: Capturing an application task that runs longer than the expected execution time for the task, without interrupting the task's execution; and Record that the application task running for longer than the expected execution time for the task has been detected. [11] Method according to claim 10, comprising capturing an execution time of the task and calculating a correction factor based on an expected execution time and an elapsed execution time. [12] Method according to one of claims 10 to 11, comprising incrementing a timer counter during the execution of the task, wherein the detection of the task that is executed for longer than an expected execution time comprises comparing the timer counter and the expected execution time for the task. [13] Method according to any one of claims 10 to 12, comprising correcting the expected execution time by adding a correction factor based on the time the task runs after the overflow has been detected. [14] A method according to any one of claims 10 to 13, comprising: incrementing a timer counter when the task is executed, storing the timer counter, storing an expected execution time for the task; and comparing the timer counter and the expected execution time for the task to detect the application task that is running for longer than the expected execution time for the task. [15] Method according to any one of claims 10 to 14, which has an interface to a user via an application programming interface to obtain the expected execution time for a task and to provide the user with a correction factor for a task.

Images