Task Switching stopped when input capture interrupt Given

I am a beginner in FreeRTOS coding.I have three tasks in my application running in STM32 mcu running on 100Mhz which toggle 3 different led’s at different interval i.e 200ms,400ms and 800ms.For delay I have used vTaskDelay. I have also configured input capture pin on which I have given 500Khz square wave signal.The movement I give signal on capture pin context switch stopped.This I can say because xTickCount stopped incrementing.Also when I remove signal from capture pin again xTickCount started incrementing hence led’s were toggling.
What are possible issues for this observation?
Below are my configuration in FreeRTOS_Config.h



configPRIO_BITS is 4

I have used TIM5 for systick whose priority is 0(highest) whereas my capture unit interrupt is at 6.

You mean that you are using TIM5 for driving ST HAL tick?

It seems that the SysTick is not firing. Can you share code for the ISR where you do this capture?

I have called function Serve_Capture_Isr in capture unit ISR.

This is Task which should get notified when ISR hits.But it doesn’t happen like that.
Execution is never coming to Task4_Handle.

I have one more query here,since I am feeding input capture pin with 500khz so ISR will get hit every 2uSec.So whats the best way to handle ISR in such high frequency case.

Are you stuck in a fault handler when this happens? Could it be that you enable your interrupt ok but never get to the isr, eg if you did not store the isr entry point at the correct place in the interrupt vector table? When you set a breakpoint to your isr, does it get hit?

I have put debug point and observed that pending interrupt is getting cleared.
But can you tell me how to handle such high frequency interrupt in FreeRTOS?

That’s quite a high interrupt frequency even with a running @ 100 MHz clock.
2.5 us give you not much CPU cycles/instructions to do something useful.
You can do the math yourself. And when running from flash you might have additional wait states.
What do you want to achieve ?

The best answer for ISR at that rate is to NOT do it as a ISR. You could well be saturating your processor within the ISR (especially if the ISR is using “Hal” code).

As others suggested, you are likely saturating your processor. Can you reduce the interrupt frequency just for verifying?