Queue Read from ISR and Queue Write from ISR related issue, when using file GCC\ARM_CM4\port.c and software interrupts on STM32H753BIT6

[Rajeev Arora]

Hello @ASELSTM , @Khouloud ZEMMELI​  ,

To observe the below reported issue it is mandatory that macro configASSERT_DEFINED == 1

The issue is observed inside the function 

void vPortValidateInterruptPriority( void )

which is available with FreeRTOS file GCC\ARM_CM4\port.c

I am observing two ASSERTS / concerns in the file (triggered as a result of Reading from or Writing to a Queue from ISR):

First Issue:

Is observed for 

configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );

when variable

uwTickPrio = TICK_INT_PRIORITY 

(either assigned directly or with help of variable TickPriority), where macro TICK_INT_PRIORITY is assigned a value of 0.

If I do not use a software interrupt to process the Queue, then because of uwTickPrio value (i.e. 0) being used as priority for FreeRTOS Timer (i.e. Timer 2), the ASSERT gets raised.

If I use the software interrupt, then I observe the second issue stated below

Second issue:

Is observed for 

configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue );

especially when triggered software interrupts are being handled. The software interrupt is triggered by updating the related interrupt number NVIC->STIR

Additional observations and concerns:

1. May you please help me understand whether TICK_INT_PRIORITY value is user changeable?
2. Also should the 

NVIC_SetPriorityGrouping(4)

 or

NVIC_SetPriorityGrouping(0)

 to be used? It is observed that

HAL_Init() calls  HAL_NVIC_SetPriorityGrouping(4)

hence if the Priority Group is to be set to 0  (in case this is the desired approach), then should  NVIC_SetPriorityGrouping(0) called just after calling HAL_Init()?

Flow:

SW_FroTimer_IRQHandler() triggered -> SW_FroTimer_IRQHandler() serviced -> calls third party library function -> Third part library calls function rvAddEventToInterruptEvents() which I've coded -> rvAddEventToInterruptEvents() triggers another software interrupt -> SW_IRQHandler() executes for good number of times and then suddenly the issue 2 occurs.

Important Observation: It is observed that 

pxCurrentTCB->pcTaskName == "IDLE"

 when any of the software interrupt is executing.

My code has:

// USART2 IRQ being used for software interrupt and is triggered from a third party library on which my code does not have any control. This execution is the result of execution of SW_FroTimer_IRQHandler() when reviewed in Call Stack.
#define SW_Int_IRQn USART2_IRQn
#define SW_IRQHandler USART2_IRQHandler
 
// This software interrupt is triggered from Timer 2 (which is used as the default FreeRTOS timer)
#define SW_FroTimer_Int_IRQn SPI4_IRQn
#define SW_FroTimer_IRQHandler SPI4_IRQHandler

below added to main() function:

	HAL_NVIC_SetPriority(SW_Int_IRQn, 6, 0);
	HAL_NVIC_EnableIRQ(SW_Int_IRQn);
 
	HAL_NVIC_SetPriority(SW_FroTimer_Int_IRQn, 6, 0);
	HAL_NVIC_EnableIRQ(SW_FroTimer_Int_IRQn);

Inside HAL_TIM_PeriodElapsedCallback()  below code is added:

		if((htim->Instance == TIM2) && (nRTOSTimerAndFMCInit == nRTOSTimerAndFMCInitStatus))
		{
			CucHighMinusLowSystemTicks++;
			NVIC->STIR = SW_FroniusTimer_Int_IRQn;
		}
 

The other piece of code that triggers the software interrupt is:

void				rvAddEventToInterruptEvents
	(
		toTaskEventHandler	*		poTaskEventHandler
	)
{
	uint32_t u32IRQMasked;
	dvDisableInterrupts;
	{
		if (osOK != osMessageQueuePut(Q_EventHandlerHandle, &poTaskEventHandler, dDummyMessagePriority, 0 /* Do not use osWaitForever as IRQ is disabled */))
		{
 			// #DRA: #ToDo: add error handling here
			++u32EventHandlerErrorCounts;
			assert_failed((uint8_t*)__FILE__, __LINE__);
		}
		else
		{
			NVIC->STIR = SW_Int_IRQn; 
		}
	}
	dvEnableInterrupts;
	return;
}
 

Is it possible for you to suggest some pointers on how to fix the issues.

Thanks

@rxa1031

[Rajeev Arora]

Hello @Khouloud ZEMMELI​ ,

Additional information:

I observe STM32CubeMX generated FreeRTOS examples have macro TICK_INIT_PRIORITY set to 0xF.

The code generated by STM32CubeMX for my IOC file has TICK_INIT_PRIORITY set to 0.

Is there a way to inform STM32CubeMX to change the macro value?

Regards,

@Rajeev Arora​