portDISABLE_INTERRUPTS() and portENABLE_INTERRUPTS(); problems

freertos: V9.0.0
MCU: stm32f4
when calling a function like this:

TIM3_Int_Init(9999,7199);		
TIM2_Int_Init(9999,7199);	
...	
void interrupt_task(void *pvParameters)
{
    while(1)
    {
		total_num+=1;
		if(total_num==5) 
		{	portDISABLE_INTERRUPTS();			
			delay_xms(5000);						
			//portDISABLE_INTERRUPTS();
		}
        LED5=~LED5;
        vTaskDelay(1000);
    }
} 

ISR function

void TIM3_IRQHandler(void)
{
	if(TIM_GetITStatus(TIM3,TIM_IT_Update)==SET)
	{
		printf("TIM3 outputs.......\r\n");
	}
	TIM_ClearITPendingBit(TIM3,TIM_IT_Update);  
}


void TIM2_IRQHandler(void)
{
	if(TIM_GetITStatus(TIM2,TIM_IT_Update)==SET) 
	{
		printf("TIM2 outputs.......\r\n");
	}
	TIM_ClearITPendingBit(TIM2,TIM_IT_Update);  
}

the result


Question
in the interrupt_task() function, I just called portDISABLE_INTERRUPTS(), so I think the timer with a lower priority (here is timer 2) will not be enabled forever till I call the portENABLE_INTERRUPTS(), but actually, the result shows that after the delay_xms(), the disabled timer will work again no matter the portENABLE_INTERRUPTS() is called or not. So portENABLE_INTERRUPTS() does not work?

First calling printf in an ISR is a VERY bad idea, it is almost certainly not interrupt safe. and may cause issues with the ISR.

What does your function delay_xms do?

Note, if it calls vTaskDelay, then you are calling that with the interrupt disabled, which something you aren’t supposed to do. For the Cortex M4 port, it might remember that this task had the interrupts disabled, re-enable the interrupts to switch to some other task (like Idle) and when it eventually switches back, disable them again. (Not positive, the other option is the delay just doesn’t happen)

delay_xms(T) acts like some operations which take T ms.

Thanks.

Have you shared the complete code? I do not see the code that prints disable interrupt......\r\n.

As @richard-damon suggested, remove printfs from ISRs - you can replace them with counters which can be examined in debugger and should stop incrementing after the interrupts are disabled.

If you see the counter incrementing, one possibility is that these timer interrupts have higher (numerically lower) priority than configMAX_SYSCALL_INTERRUPT_PRIORITY and as a result, are not masked by the disable interrupt. What is the priority of these interrupts and what is the value of configMAX_SYSCALL_INTERRUPT_PRIORITY? The following links provide more information about these -

Is delay_xms a busy wait not giving up the CPU ?

yes. not giving up CPU

As Gaurav noticed, the output was apparently not generated by the code you posted (your printfs - I will echo here that you should not use those, fcs - output “outputs”, but the log read “output” before the dot group in each line). Please post matching code and log. Also, which port are you using and what is your implementation of portDIS/ENable_interrupts? What is your defintion of max_sycall priority level in your freertosconfig.h?

btw, I ask for apologies for completly misreading your question in my first reaponse (which I deleted after realizing my mistake). These things happen, I guess…