Could Systick be interrupted?

Kernel
1

Hello. I have a question:

I have a hardware timer that is activated every 100 microseconds on the STM32 and I realized that the Systick is interrupted and not pended. Does the portDISABLE_INTERRUPTS function disable interrupts or be interrupted by a hardware (external or internal) interrupt?

The systick time is present on channel zero and the timer time is present on channel one.

image
image1090×144 3.8 KB

That’s my code

void xPortSysTickHandler( void )
{
	/* The SysTick runs at the lowest interrupt priority, so when this interrupt
	executes all interrupts must be unmasked.  There is therefore no need to
	save and then restore the interrupt mask value as its value is already
	known. */
	portDISABLE_INTERRUPTS();
	{
		channel0ON();
		/* Increment the RTOS tick. */
		if( xTaskIncrementTick() != pdFALSE )
		{
			channel0OFF();
			/* A context switch is required.  Context switching is performed in
			the PendSV interrupt.  Pend the PendSV interrupt. */
			portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;
		}else{
			channel0OFF();
		}
	}
	portENABLE_INTERRUPTS();
}

And that is my timer configuration (with internal clock 84MHz):

image

image

Thank you.

2

Hi Bruno,

Yes the ISR for Systick can be interrupted by another interrupt – in your case TIM2. The CubeMX screenshots indicate TIM2 uses the highest interrupt priority (0). Whether an interrupt is “internal” or “external” doesn’t really matter. What matters is the priority you choose for that interrupt.

3

Hi Jeff. Thank you for your reply.

So, what is the purpose of portDISABLE_INTERRUPTS?

4

During the period between the portDISABLE_INTERUPTS and portENABLE_INTERUPTS, while xTaskIncrementTick() is being called, other interrupts that might interact with the scheduler are disabled to avoid race conditions.

5

portDISABLE_INTERRUPTS() masks interrupts only up to a certain priority. Priorities higher than a specific threshold (that you control) are not masked by portDISABLE_INTERRUPTS(). See configMAX_SYSCALL_INTERRUPT_PRIORITY, and don’t forget about how the priority number has an inverse relationship with the priority. Lower numbers are higher priorities. That’s why your priority-0 interrupt occurs even with interrupts “disabled”.