tasks competing for resource??

[well_tech]

Dears, please help me to unterstand the following case (using ESP32-S3, IDF 6.0):
- I run two independend tasks, Task 1 pinned to core 1 and Task 2 pinned to core 0.
- Task 2 is activated by Task 1 with xTaskNotify and does some sensors reading by i2c with i2c_master_transmit_receive
- I control the process enabling and disabling gpio pins checking when tasks starts and finishes.

And I am struggling with unclear behavior - when Task 2 is activated execution time of Task 1 significantly increases (almost twice, please see attached image) . Task 1 has nothing to do with i2c, it is a single task running at independend core, has much higher priority and should not compete with Task 2 for any resource. But it obviously stuck somewhere for quite a long and waits until Task 2 does something, and this "something" is related to i2c operations (when I replace i2c operations at Task 2 with busy waits (ets_delay_us) all starts working normally).

Capture.JPG (64.26 KiB) Viewed 180 times

Any idea what is causing the issue and if it is possible to overcome it?

[Sprite]

Could be an interrupt thing... perhaps the I2C subsystem is initialized in a task that also runs on the same core Task 1 runs on? In that case, that core will handle the I2C interrupts, causing task1 to slow down.

[nopnop2002]

Task 1 has nothing to do with i2c, it is a single task running at independend core

This is not accurate.
The ipcX task is running on Core X with very high priority.

Code: Select all

Task                  Prio                     Core#
main            R       1       2080    3       0
IDLE1           R       0       1032    5       1
IDLE0           R       0       924     4       0
ipc0            S       24      508     1       0
ipc1            S       24      500     2       1

[MicroController]

Task 1 [...] should not compete with Task 2 for any resource.

No way to tell whether it actually does or doesn't without seeing your code.

[well_tech]

thanks for replying. I also assumed that could be an interrupt thing and therefore tried to clearly separate tasks, cores and their interrupts:
- i2c is initialized from "init" task which was created pinned to core 0.
- Task 1 processes its interrupts which are created within this task (pinned to core 1).
My entire code is fairly large therefore do not hope anyone will dig into it but may be you can give any ideas how to isolate the issue. I am specifically concerned about how large this delay is, about 400us, this is enternity for S3@240MHz. Looks like Task 1 just does nothing when Task 2 reads i2c and this is weird...

[MicroController]

Ok, so generally: One task using I2C should indeed not delay any other task by itself. Your tasks behave as expected when you do busy-waiting instead of I2C operations, which would indicate that there really is no contention in your code. If so, I'd also check for some sort of memory corruption (stack overflow,...) with the use of I2C.

[well_tech]

thanks to everyone who replied, you forced me to investigate in a right direction. After some tries I found Instruction cache size settings in menuconfig and changed it from default 16KB to 32KB and it started to work as expected, execution timeline of Task 1 looks now nice and regular, as should be.

Capture2.JPG (63.1 KiB) Viewed 97 times

[MicroController]

Resizing the cache did not solve the problem.
My guess is still some memory corruption. By resizing the cache data in RAM moved to some other locations, and the corruption now probably happens to some other data.

[well_tech]

well, for now it looks like task 1 operates stable without any suspensions but..to shift the issue to other unknown so far location is probably the worst thing I would like to do )). How can I check potential memory corruption? So far I can think only about to increase memory size allocated to the task but this is a blind action. Any other methods?

[MicroController]

Yes, stack size is the first thing to check. uxTaskGetStackHighWaterMark() can be helpful in determining a proper stack size for a task.
Another possibility to exclude is the use of invalid pointers, esp. uninitialized pointers and pointers to local variables leaking out of a function.
Although admittedly, memory corruption usually shows itself as some kind of crash/"panic", not just as delayed execution; I'm actually groping in the dark here without knowing/seeing any of the code. Might also still be some unintended contention on some lock/mutex/semaphore...