Pinning tasks to Core for ISR

[rohit269]

I read the following on the ESP-IDF doc

Care should be taken when allocating an interrupt using a task not pinned to a certain core; while running code not in a critical section, these tasks can migrate between cores at any moment, possibly making an interrupt operation fail because of the reasons mentioned above. It is advised to always use xTaskCreatePinnedToCore with a specific CoreID argument to create tasks that will handle interrupts.

I'm using GPIO interrupts in separate tasks, which are not pinned to a core. And only one of them seems to be working.

Does that mean I need to pin both the tasks each to a separate core so that they can work together?

Thanks

[ESP_Dazz]

It means that the interrupt will be allocated to which ever core the allocation API was running on at the time. This becomes a problem when doing so from an unpinned task because the interrupt can be allocated to any core. Interrupt de-allocation must be called on the same core to which the interrupt is allocated to.
Therefore it is recommended that all interrupt allocation/de-allocation be called from a task which is pinned to a core.

[urbanze]

It means that the interrupt will be allocated to which ever core the allocation API was running on at the time. This becomes a problem when doing so from an unpinned task because the interrupt can be allocated to any core. Interrupt de-allocation must be called on the same core to which the interrupt is allocated to.
Therefore it is recommended that all interrupt allocation/de-allocation be called from a task which is pinned to a core.

What happen if you deallocated in another core? I use a task non-pinned that turns touch interrupt on and off and there have never been any problems for months. Luck?

[ESP_Sprite]

Nothing wrong with just enabling and disabling interrupts; we do that using the interrupt matrix which is shared between CPUs and as such that can be done from any CPU. If you however de-allocate an interrupt, the code needs to touch registers that are only in the CPU where the interrupt was allocated. If it can't do that, the de-alloc will fail.