I met a problem for the task switch when porting tcp stack.
I have a interrupt, and inside it , it will call:
another task will process DMA data:
//xxx doing some processing
however, when data comes, switch from the interrupt to taska cost > 500ms and even seconds.
the ping delay is amont 300ms to 3s.
If I create 2 idle tasks in the system doing nothing, just forever loop and delay(1). The ping delay will be < 1ms.
Does anyone know why is that?
What other tasks are there in the application and what are their priorities? Is it possible that some other higher priority task is running and not letting the data processing task run?
Could you have preemption turned off in your system?
I am using freertos_tcp, in the system ,there are 1 rx task get buffer from dma pri 9, 1 tx task to clear tx buffer pri 10, 1 task for freertos_tcp pri 8. 1 iperf task test netweork pri 3, and no other tasks on that cpu.
Are you clearing the interrupt? If not it could be continuously re-entering.
the interrupts are cleared. I count the interrupt trigger times. it is normal.
The General rule for assigning priorities with the TCP stack is:
Priority( application using TCP ) < Priority( TCP stack ) < Priority( Task Processing DMA data )
Can you share your code - maybe in GitHub somewhere? That might help us debug.
Also, can you step through the code and see what task is running after the interrupt returns?
…also pause the debugger during the half second delay and see what is executing.
Thanks, I have changed the task pri accordingly.
Thanks, I found some problems in my system, there’s some variable conflict between local and global vars. And an interrupt value overlap. All the probelm together make this behavior.