2020-11-25 12:01 AM
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:
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
2020-11-25 12:27 AM
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