Collaborative scheduler detecting task execution longer than expected execution time without interrupting execution of task

Abstract

An apparatus has a collaborative scheduler of tasks of an application; a timer circuit to detect that a task execution of the application is longer than an expected execution time of the task without interrupting execution of the task; and a recording circuit to record that a task has been detected by the timer circuit to be executed longer than the expected execution time. A method for collaborative scheduling of tasks of an application includes: detecting that task execution of the application is longer than an expected execution time of the task without interrupting execution of the task; and recording that the overrun has been detected.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to Indian Patent Application No. 202311019603, filed on 21 March 2023, the entire contents of which are incorporated herein by reference as if fully set forth herein. Technical Field

[0003] This disclosure relates to cooperative schedulers, and more specifically to detecting and logging "incorrect allocation of execution time" task overruns in cooperative schedulers. Background Technology

[0004] The “Design Recommendations” defined in Annex D of ISO 26262 Part 6:2018, available from the International Organization for Standardization in Geneva, Switzerland, aim to achieve “non-interference” between software elements. Software elements in the context of a “cooperative scheduler” are transformed into tasks. One of the identified errors is task overrun, referred to as “incorrect allocation of execution time”.

[0005] A dead timer or watchdog timer (DMT / WDT) provides the first line of defense against task overruns (i.e., task execution stalling due to hardware module failure, infinite loops within the task, or other unrestricted overruns). Even with properly allocated execution time, task overruns due to software faults can still be detected by the DMT / WDT. Unlike task overruns caused by correctly allocated execution time, "incorrectly allocated execution time" task overruns are due to problems with the user's allocation of execution time and can be caused by insufficient loop timeout values ​​for hardware accesses within the task, incorrect baud rate settings, or incorrect synchronization between tasks—all of which are correctable characteristics.

[0006] The auxiliary timer calculates the task's execution time because the cooperative scheduler uses the main timer to execute the task. The auxiliary timer calculates the task's execution time and then detects task overruns (if any) through various methods. To detect task overruns, the auxiliary timer uses the expected execution time of the specific task. This expected execution time is considered as input obtained from the user via parameters in the software application programming interface (API). This expected execution time is set as the period of the auxiliary timer. Various methods exist to determine task overruns.

[0007] The first method can use an interrupt mechanism on the auxiliary timer. If the task execution time exceeds the period, an interrupt is generated indicating the task overrun. Unfortunately, the interrupt mechanism can temporarily "block execution" of the task, which is an error according to Annex D in ISO 26262 - Part 6 standard. Secondly, to gain uninterrupted access to the CPU, the task itself can disable interrupts during execution of critical sections of code (e.g., while reading values from an analog-to-digital converter (ADC)). Additionally, it is not possible to accurately calculate the factor by which the task has overrun the expected execution time due to any intermediate jumps to the interrupt service routine (ISR).

[0008] The second method can configure an auxiliary hardware timer (if available) and configure its period to equal the "expected execution time" of the task. While an auxiliary timer is used in both this second method and the first method, the difference is that in the first method, an interrupt is generated as soon as there is a timer overflow, while in this second method, no interrupt is generated, but the timer overflow status is captured in a hardware register bit in the auxiliary timer module. Typically, interrupts are enabled so that when the period matches, an interrupt occurs and the corresponding interrupt service routine (ISR) is triggered to record the overflow. However, similar to the first method, this method blocks the execution of the task. Because the interrupt partially blocks the execution of the code, this method is not feasible. Additionally, to alleviate the problem of the interrupt partially blocking the execution of the code, the task itself can disable interrupts as part of the execution of the priority section of the code. Thus, if an overflow occurs during the execution of the priority section of the code, the overflow event can be missed.

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

[0010] The fourth method uses a timer difference method to configure an additional hardware timer and configure its period to equal the "expected execution time" of the task. The timer is started and the timer value is recorded before the task execution and after the task execution. If the task execution continues after the rollback, 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 a difference after a rollback event. It can be difficult to distinguish between a simple difference and a difference after a rollback because both are positive values.

[0011] Software applications using the mechanisms and features provided by a cooperative scheduler need to execute tasks in defined execution time allocations. The software applications provide task definitions and the cooperative scheduler provides the mechanisms for executing the tasks. Tasks must voluntarily yield a central processing unit (CPU) to ensure that other tasks do not lack CPU resources. Because the scheduler does not prevent execution of a task, task execution overruns should be identified and reported by the cooperative scheduler to the application. Currently available methods are intrusive and either temporarily prevent execution of a task to report an overrun or do not provide explicit results.

[0012] There is a need for a cooperative scheduler that records "incorrect allocation of execution time" task overruns without interrupting execution of the task. SUMMARY

[0013] According to an example, there is provided an apparatus comprising: a cooperative scheduler of tasks of an application; timer circuitry to detect that a task of the application executes longer than an expected execution time of the task without interrupting execution of the task; and recording circuitry to record that the timer circuitry has detected that the task executes longer than the expected execution time.

[0014] Another example provides a method comprising: cooperatively scheduling tasks of an application; detecting that a task of the application executes longer than an expected execution time of the task without interrupting execution of the task; and recording that the task executes longer than the expected execution time has been detected.

[0015] According to an example, there is provided a system comprising: a cooperative scheduler of tasks of an application; timer circuitry; recording circuitry; a memory to store instructions for operating the cooperative scheduler, the timer circuitry, and the recording circuitry; and a processor coupled to the memory to execute the instructions to cause: the cooperative scheduler to schedule tasks of an application; the timer circuitry to detect that a task of the application executes longer than an expected execution time of the task without interrupting execution of the task; and the recording circuitry to record that the timer circuitry has detected that the task executes longer than the expected execution time. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings illustrate an example cooperative scheduler that records "incorrect allocation of execution time" task overruns when a task exceeds its expected execution time without interrupting execution of the task. The example cooperative scheduler can also notify an application that defines a task of "incorrect allocation of execution time" task overruns and provide the application with a correction factor to apply to the expected execution time of the task.

[0017] Figure 1A block diagram of a system for performing tasks of an application scheduled by a cooperative scheduler is shown, the system including a timer circuit and a logging circuit for detecting and recording when a task is performed longer than an expected performance time.

[0018] Figure 2 A block diagram of a system is shown in greater detail than Figure 1 the system having a cooperative scheduler, a timer circuit, a logging circuit, a correction circuit, and an application programming interface.

[0019] Figure 3 A flowchart of the operation of the system shown in Figure 1 and Figure 2 is shown.

[0020] Figure 4 A block diagram of an alternative timer circuit is shown.

[0021] Figure 5 A flowchart of the operation of the system having the timer circuit shown in Figure 4 is shown.

[0022] Figure 6 A method for cooperatively scheduling tasks, detecting task overruns, and recording detected overruns is shown.

[0023] Figure 7 A block diagram of a device having a cooperative scheduler, a timer circuit, and a logging circuit is shown.

[0024] Figure 8 A block diagram of a system having a processor, a memory, a cooperative scheduler, a timer circuit, and a logging circuit is shown.

[0025] The reference numbers of any shown elements appearing in multiple different figures have the same meaning in multiple figures, and any mention or discussion herein of any shown element in the context of any particular figure also applies to every other figure in which the same shown element is shown, if any. DETAILED DESCRIPTION

[0026] One aspect provides a cooperative scheduler that records an incorrect allocation of execution time (task overrun) without interrupting execution of the task. The cooperative scheduler determines when a task has executed longer than an expected execution time, records that the task has executed longer than expected, and notifies the application that defines the task of an "incorrect allocation of execution time" task overrun without interrupting execution of the task. According to one aspect, the cooperative scheduler provides a correction factor to the application that defines the task for application to the expected execution time. The cooperative scheduler can have a correction circuit to correct the expected execution time by adding a correction factor based on the time the task executes after an incorrect allocation of execution time (task overrun) has been recorded. The cooperative scheduler can have a timer circuit to capture the running execution time of a task.

[0027] One aspect identifies an incorrect allocation of expected execution time and provides a correction factor if the expected execution time allocation time is less than the actual execution time. Rather than interrupting a task that executes longer than expected, the actual execution time can be captured and then the correction factor can be applied statically in the form of an "increased expected execution time."

[0028] One aspect provides a method for detecting an incorrect allocation of execution time (task overrun), recording the detected overrun, and notifying a user so that the user can adjust the expected execution time of the task or modify the task implementation so that the execution time of the task will be within the expected execution time. A correction factor for the task overrun can be provided as information to the user. The user can apply the correction factor to revise the expected execution time and enter the revised expected execution time using the same application programming interface (API) that the user originally used to enter the expected execution time of the task. Alternatively, the user can revise the task to execute more quickly.

[0029] For example, a user originally enters an expected execution time of 100 microseconds for a particular task using an API. However, the running execution time of the task by the CPU is 120 microseconds. The user is provided information that the task has overrun by 20 microseconds. The user can again use the same API to enter a revised expected execution time of 120 microseconds for the task. The correction factor can be the actual execution time divided by the expected execution time. In this example, the correction factor can equal 120 microseconds divided by 100 microseconds so that the correction factor equals 1.2 (CF = 1.2). The correction factor can be multiplied by the original expected execution time to provide the revised expected execution time. Alternatively, the user can examine the task to see where the additional 20 microseconds are spent and make appropriate changes to the task so that the CPU can execute the task in less than 100 microseconds.

[0030] Aspects can be implemented as features in a cooperative scheduler to monitor execution time of tasks. Annex D of ISO 26262 Part 6 2018 standard describes the "non-intrusiveness" of software elements (tasks) used in applications running on CPU devices that pursue functional safety compliance. "Incorrect allocation of execution" is an error in this annex for software elements (tasks). One aspect provides an update to an application that defines a task running on a CPU device about a task overrun of its allocated execution time. Detecting the task overrun can ensure compliance with the ISO 26262 standard.

[0031] In one example, a task overrun can be identified and recorded by using a combination of a timer circuit and a recording circuit. From a software perspective, the "expected execution time" of each task is treated as a user input to an application that defines a task running on a CPU device through an application programming interface (API). The timer circuit can be configured in a timer mode (e.g., interrupts are disabled or not enabled because the feature can work without interrupts), where the "expected execution time" is input as the period of the timer. Before executing the task, the timer of the timer circuit is started, for example, by setting a start bit in a start register of the timer circuit through task monitoring software code via the cooperative scheduler or the correction circuit. If there is a rollback, i.e., when the counter register matches the expected execution time in the period register, a detection output of the timer rollback can be available in a hardware register of the timer circuit. The timer rollback of the detection output can be a pulse output. However, the pulse output can not be captured independently because the signal is neither brought onto any I / O pin nor recorded in any special function register (SFR) of the timer circuit. The timer rollback can not be recorded independently, so the recording circuit can capture the timer rollback event by inputting the detection output bit in a recording register (special function register (SFR)) of the recording circuit.

[0032] Because user tasks scheduled by the cooperative scheduler for CPU execution have full uninterrupted access to the CPU, the tasks should complete their execution within the "expected execution time". However, if a task violates the "expected execution time" due to some problem, a method is provided to inform the user that a particular task has exceeded its "expected execution time". The time allocated to the task (expected execution time) can be as input by the user. Because the tasks have uninterrupted access to the CPU, they are not interrupted by other tasks or interrupts. In such scenarios, a method to record the task overrun without interrupting the execution of the task can ensure more efficient execution of the application. This can be important when used in relation to a cooperative scheduler that is compatible with functional safety.

[0033] Embodiments provide circuitry that can be implemented by instructions for execution by a processor, analog circuitry, digital circuitry, control logic, digital logic circuitry programmed through a hardware description language, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), or any appropriate combination thereof, whether in a single device or distributed across several devices. The circuitry can be implemented by instructions for execution by a processor, such as a function, an application programming interface (API) call, a script, a program, compiled code, interpreted code, binary, executable, executable file, firmware, object file, container, assembly code, or object. For example, the circuitry can be implemented by instructions stored in a non-transitory medium, such as a memory, that when loaded and executed by a processor (or any other appropriate process) cause the functions of the circuitry described herein.

[0034] Figure 1 A block diagram of a system for performing tasks of an application scheduled by a cooperative scheduler 110 is shown, the system including a timer circuit 120 and a logging circuit 130 for detecting and recording when a task is executing longer than an expected execution time. The system also has an application 100, a correction circuit 140, an application programming interface 150, and a processor (CPU) 106. The application 100 can have several tasks 102i to 102n. The timer circuit 120 can detect an overrun of a task 102i to 102n of the application 100 executing longer than an expected execution time of the task without interrupting execution of the task. The logging circuit 130 can record that the timer circuit 120 has detected an overrun. The correction circuit 140 can allow a user to correct or revise the expected execution time via a correction factor after an overrun has been detected. The correction circuit 140 can be a combination of hardware and software, pure hardware, or pure software, but is not limited thereto. The correction factor can be a multiplier of the originally entered expected execution time, a remaining time to complete execution of the task after a rollback event, or a run time of the execution of the task. The correction circuit 140 provides the correction factor to a user of the application through the application programming interface circuit 150. The user can also use the application programming interface circuit 150 to provide the expected execution time to the timer circuit 120, whether revised by the correction factor or not. The user can provide an update at least partially in response to the correction factor. In one example, the correction circuit 140 can correct the expected execution time by adding the time the task executed after the overrun was detected to the expected execution time.

[0035] Figure 2 A block diagram of a system for performing tasks of an application scheduled by a cooperative scheduler 110 is shown, the system including a timer circuit 120 and a logging circuit 130 for detecting and recording when a task is executing longer than an expected execution time. The system also has an application 100, a correction circuit 140, an application programming interface 150, and a processor (CPU) 106. The application 100 can have several tasks 102i to 102n. The timer circuit 120 can detect an overrun of a task 102i to 102n of the application 100 executing longer than an expected execution time of the task without interrupting execution of the task. The logging circuit 130 can record that the timer circuit 120 has detected an overrun. The correction circuit 140 can allow a user to correct or revise the expected execution time via a correction factor after an overrun has been detected. The correction circuit 140 can be a combination of hardware and software, pure hardware, or pure software, but is not limited thereto. The correction factor can be a multiplier of the originally entered expected execution time, a remaining time to complete execution of the task after a rollback event, or a run time of the execution of the task. The correction circuit 140 provides the correction factor to a user of the application through the application programming interface circuit 150. The user can also use the application programming interface circuit 150 to provide the expected execution time to the timer circuit 120, whether revised by the correction factor or not. The user can provide an update at least partially in response to the correction factor. In one example, the correction circuit 140 can correct the expected execution time by adding the time the task executed after the overrun was detected to the expected execution time. Figure 1A more detailed block diagram of several components for detecting task overrun is shown. The cooperative scheduler 210 provides task start indications and task end indications to the correction circuit 240. Upon receiving the indications, the correction circuit 240 provides a corresponding start bit to the start register 228 in response to the task start indication and an end bit to the end register 229 of the timer circuit 220 in response to the task end indication, respectively. The correction circuit 240 also receives an expected execution time from a user via the application programming interface 250 and inputs the expected execution time into the expected execution time register 224 of the timer circuit 220. The timer circuit 220 has 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. The timer 222 acts as a controlled clock in response to the start register 228 and the end register 229 and increments the timer counter register on a predetermined edge of a clock provided by the time base generator 221. The time base generator 221 is part of a hardware module that provides a clock to time the timer 222, where the time base generator 221 can use clock signals available on the microcontroller, including the system clock and other on-chip oscillator sources, and external clock inputs. The recording circuit 230 can have a D flip-flop with a set and a reset input. The recording circuit 230 can be formed from a configurable module and have a configuration that can be controlled by software inputs. The recording circuit 230 can be hardware and provide software values of 0, 0, and 1 to the S input 231, the R input 232, and the D input 233, respectively, as Figure 2 shown.

[0036] The detection output 226 from the timer circuit 220 can be fed as a clock input 234 to a D flip-flop of the record circuit 230. Timer rollover can occur in various scenarios. For example, when the timer counter register 223 reaches FFFF (hexadecimal), the timer counter register 223 can roll back to 0000 (hexadecimal). According to another example, if the expected execution time register 224 holds an expected execution time (e.g., 1234 (hexadecimal)), then when the timer counter register 223 starts timing from 0000 (hexadecimal) until it matches the expected execution time register 224 (e.g., 1234 (hexadecimal)), then the comparator 225 signals the reset / trigger control component 227, and the reset / trigger control component 227 resets or rolls back the timer counter register 223 to 0000 (hexadecimal). The reset / trigger control component 227 monitors the value in the timer counter register 223 and receives the output signal of the comparator 225 and uses this information to note that the value in the timer counter register 223 has rolled back to 0000 (hexadecimal) or to reset the value in the timer counter register 223. Each time there is a roll back of the timer counter register 223 or a reset of the timer counter register 223, the reset / trigger control component 227 can generate a pulse detection output 226 that is fed as a clock input 234 to a D flip-flop of the record circuit 230. This clock pulse latches the logic input fed at the D input 233, which latches a logic high at the Q output 235. This logic output can be read as a detection output bit directly from the record register 236 available from the record circuit 230 once the task execution is complete. Thus, when the task is executed without interruption, the roll back of the expected execution time register can be recorded in the record register 236. If there are two overflows, a watchdog reset can occur. Additionally, because the task execution is uninterrupted, the calculation of its execution run time can be easily recorded under both the expected execution time register overflow scenario and the expected execution time register non-overflow scenario. A correction factor according to the excess time of the task can be provided to the user. The expected execution time can be corrected, or in some cases, appropriate changes can be made in the implementation of the task to ensure that the execution of the task is completed within the expected execution time. The detection output 226 can also be read from the record register 236 and provided to the correction circuit 240. The correction circuit 240 can also read the run 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.

[0037] Figure 3 A method for correcting a task execution time via a computing device is shown. Figure 2The illustrated timer circuit detects the flowchart of a task overrun. The expected execution time from the user is input 302 to the expected execution time register, and the timer counter register is set to zero. The start register is checked 304 for whether it has received a start bit indicating that the task has started execution. If not, then the process returns and the start bit is checked 304 again. If yes, then the end register is checked 306 for whether it has received an end bit indicating that the task has ended execution. If not, then the timer increments the timer counter register 308. The expected execution time in the expected execution time register is compared 310 to the value in the timer counter register to determine whether they are equal. If yes, then a detection output is generated 312 by the reset / trigger control component, the detection output is logged 314, the value in the timer counter register is reset 315 to zero (0) by the reset / trigger control component, and the process returns to checking 306 the end register again. If no, i.e., the expected execution time in the expected execution time register is not equal when compared 310 to the value in the timer counter register, then the process returns to checking 306 the end register again. If the end register is checked 306 and determined to be “yes”, then the end register has received an end bit indicating that the task has ended execution, then the process checks 316 whether the detection output is in the log register. If no, then the process ends. If yes, then the correction circuit reads the run execution time from the timer counter register. Then, the correction circuit calculates 320 a correction factor from the expected execution time, the run execution time, and the detection output in the log register indicating a rollback event. Then, the correction circuit communicates 322 the correction factor to the user via the application programming interface.

[0038] Figure 4 An alternative timer circuit 420 is illustrated. The timer circuit 420 operates with a cooperative scheduler, an application programming interface, and a logging circuit as illustrated but not shown in Figure 2 Figure 4 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, which is similar to the timer circuit 220 as illustrated in Figure 2 The timer circuit 420 also has a time base generator 421, which is similar to the timer circuit 220 as illustrated in Figure 2 ​The timer circuit 220 is shown. The time base generator 421 can use the clock signals available on the microcontroller to provide a time base or clock for the rest of the timer circuit 420. This is used as the time base for the timer circuit 420 without relying on another on-chip timer circuit. The time base generator 421 can use up to eight clock inputs, including the system clock and other on-chip oscillator sources. External clock inputs can also be available depending on the device. A pre- divider can divide the selected clock source to an appropriate frequency for use by the timer circuit 420. The time base generator 421 can synchronize its operation with the selected clock source, which is subject to input timing constraints or operating conditions of the circuit. Setting the timer synchronization bit can enable synchronization of the time base with the clock input.

[0039] However, the timer circuit 420 does not have a comparator, and the timer 422 counts down to zero (0) rather than counting up from zero (0). The reset / trigger control 427 reads the expected execution time from the expected execution time register 424, and inputs that value into the timer counter register 423, which counts down from the expected execution time. The reset / trigger control 427 first inputs the expected execution time into the timer counter register 423, and the timer counter register 423 decrements the value in the timer counter register 423 according to the 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 that information from the timer counter register 423, and generates the detection output 426 indicating that the execution of the task has exceeded the expected execution time. The detection output 426 can be communicated to the task scheduler 410, which can then take action to address the task that has exceeded the expected execution time. Figure 2 shown but not in Figure 4The record circuit is shown in FIG. 4. The reset / freeze control component 427 rolls back the timer counter register 423 by inputting the expected execution time from the expected execution time register 424 into the timer counter register 423 again, which counts down again towards zero (0). When the end bit is input into the end register 429 from the correction circuit 440, the timer circuit 420 stops decrementing, and the correction circuit 440 reads the countdown execution time from the timer counter register 423. If the record register 236 has recorded the rollback of the expected execution time register, the correction circuit 440 calculates the correction factor as equal to the expected execution time minus the countdown execution time. In this case, the correction factor is the amount of time that the task execution exceeded the expected execution time. The correction circuit 440 can communicate the correction factor to the user via an application programming interface (not shown). If the record register 236 has not recorded the rollback of the expected execution time register, then no correction factor needs to be calculated. Alternatively, if the record register 236 has not recorded the rollback of the expected execution time register, then the countdown execution time from the timer counter register 423 can be reported as the available time that was not utilized by the task.

[0040] Figure 5 FIG. 4 shows a flowchart of a method for recording the execution time of a task via a Figure 4The illustrated timing circuit detects the flowchart of an overrunning task. An expected execution time from a user is input 502 in an expected execution time register. The expected execution time from the user is also input 503 in a timer counter register. A start register is checked 504 if a start bit indicating that the task has started execution has been received. If no, the process returns and the start bit is checked 504 again. If yes, an end register is checked 506 if an end bit indicating that the task has ended execution has been received. If no, the timer counter register is decremented 508 according to a clock signal from a time base generator. The value in the timer counter register is checked 510 if it is equal to zero (0). If yes, a detection output is generated 512, the detection output is recorded 514 by a recording circuit, the value in the timer counter register is reset 515 to the expected execution time obtained from the expected execution time register, and the process returns to check 506 the end register again. If no 510, the value in the timer counter register is not equal to zero (0), the process returns to check 506 the end register again. If the end register is checked 506 and determined to be "yes", the end register has received the end bit indicating that the task has ended execution, then the process checks 516 if the detection output is in a recording register. If no, the process ends. If yes, a correction circuit reads a countdown execution time from the timer counter register. Then, the correction circuit calculates 520 a correction factor according to the expected execution time, the countdown execution time, and the detection output in the recording register. Then, the correction circuit communicates 522 the correction factor to the user via an application programming interface.

[0041] An alternative timer circuit can increment a timer counter register according to a time base generator before, during, and after a task is executed. The timer circuit can also roll back the value of the timer counter register to zero (0) when it reaches an estimated execution time, and generate a detection output. A correction circuit can read the value of the timer counter register when a start bit is input in a start register. The correction circuit can read the value of the timer counter register again when an end bit is input in an end register. The correction circuit can check the detection output indicating a rollback that occurred during the execution of the task. If the detection output indicates a rollback, the correction circuit can determine the total execution time of the task to be equal to the expected execution time plus the difference between the value of the timer counter register at the start and the value of the timer counter register at the end. If there is no indication of a rollback, the correction circuit can determine the execution time of the task to be equal to the difference between the value of the timer counter register at the start and the value of the timer counter register at the end. If the task takes at least twice the expected execution time, a safety mechanism in the collaborative scheduler can provide a watchdog reset.

[0042] While the CPU 106 is busy performing the tasks 102i-102n, the identification of the task overrun (rollback event) can be recorded in the background. See Figure 1 The identification of the task overrun (rollback event) can be recorded in software or hardware, indicating whether the task has overrun. The overrun can be recorded in hardware, where the detection output is set in a hardware register, where the detection output can be a binary bit (high or low) recorded in the register. The timer circuit 120 can identify the task overrun (rollback event). The expected execution time can be loaded into the expected execution time register 224 (see Figure 2 ) before or during the execution of the task by the CPU 106. See Figure 1 Alternatively, the timer can be loaded with the expected execution time, and the timer can count down to zero (0), whereupon it can generate a rollback pulse indicating that the task has executed longer than the expected execution time.

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

[0044] Examples can also include software routines that are part of the functionally safe compliant cooperative scheduler, which are used in applications that run using these cooperative schedulers. The algorithms can avoid execution being blocked, deadlocked, livelocked, or incorrect allocation of execution time.

[0045] Task execution monitoring can be performed on individual tasks. After the execution of individual tasks is complete, it is determined whether the individual tasks have exceeded their expected execution time. When individual tasks complete execution, they can be individually determined for overrun.

[0046] Figure 6A flowchart of a method is shown. A task of an application is detected 602 to be executing longer than an expected execution time of the task without interrupting execution of the task. It is recorded 604 that the task execution has been detected to be longer than the expected execution time. An alternative example of the method can report to a user that a task overrun (rollback event) exceeds the expected execution time of the task, allowing the user to use a correction factor to correct the expected execution time. The user can use the correction factor to adjust the expected execution time of a particular task so that problems with incorrect assignment of execution time can be resolved.

[0047] Detection and correction of the expected execution time can include detecting extreme task overruns (e.g., stalled execution due to hardware failure, infinite loops in the task), and mitigating the extreme task overruns by watchdog timers or hang timers, which can still occur even after the expected execution time has been correctly assigned. Task overruns (rollback events) that exceed the incorrectly assigned expected execution time of a task can be due to inadequate loop timeouts, incorrect baud rates, or incorrect synchronization between software elements. These overrun causes can be correctable.

[0048] A cooperative scheduler can use a base timer (master timer) to periodically execute tasks. Additional or secondary timers can monitor task execution time and task overruns. The secondary timers can be timer circuits used in timer mode. The expected execution time of a task can be input by a user as a period of the secondary timer.

[0049] References Figure 2, the expected execution time is the value in the expected execution time register 224 that is used for comparison with the running execution time in the timer counter register 223. When the running 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 should have elapsed, but it has not completed because the end bit has not been stored in the end register 229. For example, if the expected execution time for a particular task is 100 microseconds, that expected execution time can be set in the expected execution time register 224. When the timer 222 is started by the start bit input in 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 the timing signal received from the time base generator 221. The comparator 225 compares the running 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 will generate the detection output 226, and the value in the timer counter register 223 is reset by the reset / trigger control component 227 to zero (0). Before the timer 222 is stopped by the end bit input in the end register 229, the timer counter register 223 rolls back and continues to count from zero (0) until the next match with the expected execution time in the expected execution time register 224 or the end bit is input in the end register 229. If the task executes longer than twice the expected execution time, a safety mechanism in the cooperative scheduler can provide a watchdog reset, where the watchdog timeout can be configured to be twice the expected execution time of the task.

[0050] Alternatively, with reference to Figure 4 , the timer can be loaded with a value corresponding to the expected execution time of the task, and when the timer reaches "zero", the timer can generate a roll back.

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

[0052] The pulse generated by the detection output 226 of the timer circuit 220 can be a pulse. To capture the pulse, the detection output 226 can be fed from the timer circuit 220 to a recording circuit 230. The recording circuit 230 can be configured as a D flip-flop, where the detection output 226 is fed to the clock input of the D flip-flop, such that the pulse can generate a predetermined output of the D flip-flop. In one example, the predetermined output of the D flip-flop in response to the 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 opposite the predetermined 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 a bit of a recording register 236 (see Figure 2 ) as shown in Table 1. Once the execution of the task is complete, the bit can be read to check for a timer overflow, which in turn indicates a task overrun (roll-back event). The advantage of this approach is that the timer overflow capture occurs seamlessly while the task is executed without interruption.

[0053] Detection output bit Output signal 0 No rollback 1 Rollback

[0054] Table 1

[0055] Reference Figure 2 , the time base generator 221 can use the clock signals available on the microcontroller to provide a time base or clock for the rest of the timer circuit 220. This serves as the time base for the timer circuit 220 without relying on another on-chip timer circuit. The time base generator 221 can use up to eight clock inputs, including the system clock and other on-chip oscillator sources. External clock inputs can also be available depending on the device. A pre- divider can divide the selected clock source to an appropriate frequency for use by the timer circuit 220. The time base generator 221 can synchronize its operation with the selected clock source, which is subject to input timing limitations or operating conditions of the circuit. Setting the timer sync bit can enable synchronization of the time base with the clock input.

[0056] The timer circuit 220 can generate the detection output 226 when the value in the timer counter register 223 equals the expected execution time register 224, and a roll-back of the timer counter register 223 can occur. The detection output 226 can be available to other circuits as a synchronization source, or can be used to trigger another peripheral device to take action in response to a roll-back event. The detection output 226 can be separate from a device-level interrupt or other output of the timer circuit 220. The timer circuit 220 can be configured as a capture compare pulse width modulation (CCP) circuit.

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

[0058] Reference is made to Figure 2, the expected execution time register 224. Each time a task is executed, the timer 222 is started by inputting a start bit in the start register 228, and when the run execution time of the task (stored in the timer counter register 223) matches its expected execution time (stored in the expected execution time register 224), there is a timer roll-back triggered by the reset / trigger control component 227 because the expected execution time (stored in the expected execution time register 224) is the same as the run execution time (in the timer counter register 223). The reset / trigger control component 227 generates a detect output 226 which produces a pulse of the detect output 226. As shown in Table 1, when the bit of the record register 236 is "0", the Q output 235 is low to indicate no roll-back. When the bit of the record register 236 is "1", the Q output 235 indicates a roll-back. The detect 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 the Q output 235 to the correction circuit 240. Once the task completes its execution, the bit stored in the record register 236 indicates the task execution overrun, if any. The execution of the task is not interrupted and the overrun, if any, is captured or recorded. After the roll-back is captured or recorded, the run execution time can be read from the timer circuit 220 by the correction circuit 240. The correction circuit 240 can calculate a correction factor based on the presence of the Q output 235 and the value of the run execution time. The correction circuit 240 can report the correction factor to the user through the application programming interface circuit 250, which indicates that a task overrun has occurred. The user can use the correction factor to correct the allocation of execution time, and input the revised expected execution time to the correction circuit 240 through the application programming interface circuit 250. The user can use the correction factor to adjust the expected execution time of a particular task so that the problem of "incorrect allocation of execution time" can be solved. The correction factor can be reported to the user so that the user can decide whether to apply the correction factor. The correction factor can be equal to the total execution time minus the expected execution time, or the correction factor can be a multiple of the original inputted expected execution allocation, the remaining time to complete the execution of the task after the roll-back event, or the run execution time of the task. The user can use the correction factor to change the task code to ensure that the task execution falls within the expected execution time, or use the correction factor to modify the expected execution time. The correction is not done dynamically during the execution run time of the task. By using the correction factor, the problem of "incorrect allocation of execution time" for a task can be solved.

[0059] Aspects identify task overruns and provide a correction factor to a user so that the user can input an adjustment in order for the task to perform well within an expected execution time. When the correction factor is provided, a user of the application can resolve the problem of "incorrect allocation of execution time."

[0060] Based on the expected execution time, if the task completes its execution before the expected execution time, there is no timer rollback. The Q output 235 gives no pulses and the bit in the record register 236 is not set. However, whenever the task exceeds the expected execution time, the execution is not interrupted, but the detect output 226 provides a pulse that is captured by the bit in the record register 236 of the record circuit 230 as the Q output 235. Once the task execution is complete, the detect output of the bit is checked.

[0061] The timer circuit, the record circuit, the correction circuit, the scheduling circuit, and the API circuit can each be implemented by instructions for execution by a processor, analog circuitry, digital circuitry, control logic, digital logic circuitry programmed through a hardware description language, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), or any appropriate combination thereof, whether in a single device or distributed across several devices. The circuits can each be implemented by instructions for execution by a processor through, for example, a function, an application programming interface (API) call, a script, a program, compiled code, interpreted code, binary, executable, executable file, firmware, object file, container, assembly code, or object, stored in a non-transitory medium such as a memory. For example, the circuits can each be implemented by instructions stored in a non-transitory medium such as a memory that, when loaded and executed by a processor (or any other appropriate process), cause the functions of the circuits described herein.

[0062] Figure 7 A block diagram of a device is shown that includes a cooperative scheduler 702; a timer circuit 704 to detect an overrun of a task of an application that executes longer than an expected execution time of the task without interrupting execution of the task; and a record circuit 706 to record that the timer circuit has detected an overrun. Figure 8 A block diagram of a system is shown that includes a cooperative scheduler 802 of a task of an application; a timer circuit 804; a record circuit 806; a memory 810 to store instructions to operate the cooperative scheduler 802, the timer circuit 804, and the record circuit 806; and a processor 808 coupled to the memory 810 to execute the instructions to cause: the cooperative scheduler 802 to schedule the task of the application; the timer circuit 804 to detect an overrun of the task of the application that executes longer than an expected execution time of the task without interrupting execution of the task; and the record circuit 806 to record that the timer circuit 804 has detected an overrun.

[0063] While example implementations have been described above, other variations and implementations can be made by those skilled in the art without departing from the spirit and scope of the disclosure.

Claims

1. An apparatus comprising: a cooperative scheduler of tasks of an application; a timer circuit to detect that a task of the application executes longer than an expected execution time of the task without interrupting execution of the task; and a recording circuit to record that the task of the application has been detected by the timer circuit to execute longer than the expected execution time of the task.

2. The apparatus of claim 1, comprising a correction circuit to correct the expected execution time by adding a correction factor based on a time of execution of the task after the overrun has been detected.

3. The apparatus of any one of claims 1 to 2, wherein the timer circuit is to capture a running execution time of the task.

4. The apparatus of any one of claims 1 to 3, wherein the timer circuit is to increment a timer counter as the task executes and compare the timer counter to the expected execution time of the task, and generate a detection output when the timer counter is equal to the expected execution time, the detection output recorded by the recording circuit to record that the task of the application has been detected by the timer circuit to execute longer than the expected execution time of the task.

5. The apparatus of any one of claims 1 to 4, wherein the timer circuit is to decrement a timer counter from the expected execution time towards zero (0) as the task executes, and generate a detection output when the timer counter is equal to zero (0), the detection output recorded by the recording circuit to record that the task of the application has been detected by the timer circuit to execute longer than the expected execution time of the task. a time base generator; 6. The apparatus of any one of claims 1-5, wherein the timer circuit comprises: a timer; a timer counter register to store a timer counter value as the task executes; an expected execution time register to store an expected execution time of the task; and wherein the timer circuit is to generate a detection output based on a timer counter value stored in the timer counter register, the detection output recorded by the recording circuit to record that the task of the application has been detected by the timer circuit to execute longer than the expected execution time of the task.

7. The apparatus of any one of claims 1 to 6, comprising an application programming interface to provide the expected execution time to the timer circuit and to allow a user to provide a corrected expected execution time to the timer circuit.

8. The apparatus of any one of claims 1 to 7, wherein the recording circuit is to capture a pulse signal from the timer circuit, wherein the pulse signal output corresponds to a detection of a task overrun. ​ 9. The apparatus of any of claims 1 to 8, wherein the timer circuit is to capture a run execution time of the task, and the apparatus comprises a correction circuit to calculate a correction factor based on the expected execution time and the run execution time.

10. A method comprising: detecting that a task of an application executes longer than an expected execution time of the task without interrupting execution of the task; and recording that the task of the application has been detected to execute longer than the expected execution time of the task.

11. The method of claim 10, comprising capturing a run execution time of the task, and calculating a correction factor based on expected execution time and run execution time. incrementing a timer counter as the task executes, and wherein detecting that the task executes longer than an expected execution time comprises comparing the timer counter to the expected execution time of the task.

12. The method of any one of claims 10-11, comprising:

13. The method of any of claims 10 to 12, comprising correcting the expected execution time by adding a correction factor based on a time the task executes after the overrunning has been detected. incrementing a timer counter as the task executes, storing the timer counter, storing an expected execution time of the task; 14. The method of any one of claims 10-13, comprising: and comparing the timer counter to the expected execution time of the task to detect that the task of the application executes longer than the expected execution time of the task.

15. The method of any of claims 10 to 14, comprising interfacing with a user via an application programming interface to obtain the expected execution time of a task and to provide the user with a correction factor for a task. ​

Images