Delayed task execution

We have been facing a problem that seems to delay a task.
Task is hosting a modbus application.

Problem statement

Modbus queries are fired repeatedly to devices connected in daisy chain. Randomly( Typically after 2-3 days ) the response is observed to have delayed by 2-4 Seconds.

The processing is as follows.

Bytes are received and pushed to a queue from the uart ISR
The task receives the bytes from the queue and once the packet is received, The response is sent


After days of debugging and monitoring, We found no bug in the code.
Our task priorities are defined as

5 Tasks at Priority=5
1 Task at Priority=6
7 Tasks at Priority=10 ← Modbus hosting task
1 Task at Priority=14
1 Task at Priority=15

Recent Development

We recently made the priorities contiguous keeping the hierarchy same such as

5 Tasks at Priority=1
1 Task at Priority=2
7 Tasks at Priority=3 ← Modbus hosting task
1 Task at Priority=4
1 Task at Priority=5

Doing this change, We did not face the issue but we haven’t been able to justify the gaps in priority as the root cause of the problem.

Looking for opinions/suggestions on the issue and the solution.

Priority numbering isn’t important, but the relative priorities are. So both numbering schemes are equal given that all tasks of your application are listed.
Is it right that there is no missed modbus query ?
There might be various reasons including an issue in the modbus driver ISR-task signaling or unexpected behavior of the 2 higher prio tasks. If these tasks consume all processing resources for whatever reasons for 2-3 seconds, the lower prio modbus task is delayed by that amount of time, as you already might know.
If you want to ensure real-time behavior (deterministic response time) of the modbus task make it the highest prio task if possible or make sure that the 2 higher prio tasks have bounded (short) execution time.

Hi there,

I take it that when you streamlined your priorities, you also reduced configMAX_taskPriorities from 15 to 5?

The one difference that makes is to slightly reduce the task switch turnaround time because the highest pri selection algorithm goes from highest to lowest and searches the ready task list on each level downwards to find the highest pri ready task. Reducing the size of the array, and in particular eliminating gaps, will help making the selection algorithm find the highest pri ready task execute faster on the average.

I agree with Hartmut that none of this should be the immediate cause of what you observe, but if it is really the case that this one optimization will eliminate your hiccups, then this one difference will make the difference in timing that makes your problem show.

You may want to run Percepio’s Tracealyzer (or a compatible utility) which is exactly the kind of tool you need to understand the timing of your system.