HAL_GetTick() freezes and stops to update

[GComes]

During the debugging, I noticed HAL_GetTick() freezes, I mean uwTick does not update anymore and holds the same value.

This issue is happening while the TIM15_IRQHandler is called and executes a function responsible for reading from an SPI communication, it is shown below:

uint8_t canSpi_readAdresss(spi_SlaveInterface* spi, uint8_t adress, uint8_t* rxData, uint8_t rxBytes)
{
	uint8_t rxArray[2 + rxBytes];
	uint64_t timeout = HAL_GetTick() + 5;
	while (timeout > HAL_GetTick())
	{
		if (spi->master->activSlave == NULL)
		{
			uint8_t msgData[2];
			msgData[0] = 0b00000011; // read
			msgData[1] = adress;
			if (spi_TransmitReceive_(spi, msgData, 2, rxArray, rxBytes) == 0)
			{
				for (uint8_t i = 0; i < rxBytes; ++i)
				{
					rxData[i] = rxArray[2 + i];
				}
				return 0;
			}
			else
			{
				//rxData = 0;
			}
		}
	}
	return 0xff;
}

The HAL_GetTick()  holds the same value, therefore the execution gets stuck in the while-loop. It can happen just after the debugging starts or any time later.

The Tick priority uwTickPrio is 0 "zero", always.

Below is an image from the code execution shown in Parallel Stacks:

As it is the first time I am facing this kind of issue, I am a bit confused about what might be causing it.
Any help would be highly appreciated. 
 
The settings are:
MCU: STM32F303VE
Microsoft Visual Studio Professional 2019 - Version 16.11.30
VisualGDB Version 5.6R9

[KnarfB]

Timer tick prio must be higher (lower number) than TIM15_IRQHandler prio to increment the tick value within the handler.

hth

KnarfB

[GComes]

Hi @KnarfB , thanks for the answer.

I forgot to mention, the uwTickPrio is lower than TIM15_IRQHandler, which is 1

Here is the function to set the TIM15 

void EnableTimerInterruptTim15()
{
	uint8_t NVIC_IRQChannel = TIM15_IRQn;
	uint8_t NVIC_IRQChannelPreemptionPriority = 1;
	uint8_t NVIC_IRQChannelSubPriority = 1;
	FunctionalState NVIC_IRQChannelCmd = ENABLE;
	
	uint32_t tmppriority = 0x00, tmppre = 0x00, tmpsub = 0x0F;
  
	/* Check the parameters */
	assert_param(IS_FUNCTIONAL_STATE(NVIC_IRQChannelCmd));
	assert_param(IS_NVIC_PREEMPTION_PRIORITY(NVIC_IRQChannelPreemptionPriority));  
	assert_param(IS_NVIC_SUB_PRIORITY(> NVIC_IRQChannelSubPriority));
    
	if (NVIC_IRQChannelCmd != DISABLE)
	{
		/* Compute the Corresponding IRQ Priority --------------------------------*/    
		tmppriority = (0x700 - ((SCB->AIRCR) & (uint32_t)0x700)) >> 0x08;
		tmppre = (0x4 - tmppriority);
		tmpsub = tmpsub >> tmppriority;

		tmppriority = (uint32_t)NVIC_IRQChannelPreemptionPriority << tmppre;
		tmppriority |=  NVIC_IRQChannelSubPriority & tmpsub;
		tmppriority = tmppriority << 0x04;
        
		NVIC->IP[NVIC_IRQChannel] = tmppriority;
    
		/* Enable the Selected IRQ Channels --------------------------------------*/
		NVIC->ISER[NVIC_IRQChannel >> 0x05] =
		  (uint32_t)0x01 << (NVIC_IRQChannel & (uint8_t)0x1F);
	}
	else
	{
		/* Disable the Selected IRQ Channels -------------------------------------*/
		NVIC->ICER[NVIC_IRQChannel >> 0x05] =
		  (uint32_t)0x01 << (NVIC_IRQChannel & (uint8_t)0x1F);
	}
}

Thank you!

[TDK · Accepted solution]

	uint8_t NVIC_IRQChannelPreemptionPriority = 1;
	uint8_t NVIC_IRQChannelSubPriority = 1;

The typical configuration has 4 bits for preemption priority and 0 for subpriority. Have you changed the NVIC priority grouping?

If you show the contents of the relevant NVIC registers, surely the issue will be apparent.

[KnarfB]

In addidtion to @TDK :

compare your code to (or better use directly) CMSIS NVIC functions.

See https://arm-software.github.io/CMSIS_5/Core/html/group__NVIC__gr.html

and your local CMSIS installation like Drivers/CMSIS/Core/Include/core_cm*.h

hth

KnarfB