2018-05-14 09:14 AM
.
2018-05-14 02:53 PM
How is this related to this thread?
Check that you have a working SysTick interrupt, and that it is incrementing the HAL Tick properly.
If you are calling this delay in an interrupt you'll need to ensure the SysTick preempts everything else.
There should be a whole collection of Free RTOS examples, perhaps review how they work and are structured, and apply that to your code.
2018-05-15 03:10 AM
Thank ou Clive One for your reply
ensure the SysTick preempts everything else. please ?? I am blocked
2018-05-15 06:30 AM
Review the NVIC preemption and sub-priority settings, and the group settings that determine the bits assigned to each. System Handler priorities managed in the SCB
Read up on the functionality of the processor
https://www.amazon.com/Definitive-Guide-Cortex%C2%AE-M3-Cortex%C2%AE-M4-Processors/dp/0124080820
2018-05-15 06:39 AM
Is the systick good when using FreeRTOS or shall I change it to timer ? I saw in some forums saying systick is not good performing when it comes to rtos is that true please ? Shall i continue using systick or not ?
2018-05-15 07:59 AM
I changed the systick functions in which will be usuable by FreeRTOS like this ..systick and HAL_GetTick are declared weak so I changed it like this
/**
* dummy function to avoid the standard initialization code */HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority){ return HAL_OK;}/**
* @brief Get the value of the Kernel SysTick timer* @param None* @retval None* @note MUST REMAIN UNCHANGED: \b osKernelSysTick shall be consistent in every CMSIS-RTOS.*/uint32_t HAL_GetTick(void){ return osKernelSysTick();}/*** @brief This function handles System tick timer.*/void SysTick_Handler(void){ /* USER CODE BEGIN SysTick_IRQn 0 */if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED)
{ osSystickHandler(); }/* USER CODE END SysTick_IRQn 0 */
/* USER CODE BEGIN SysTick_IRQn 1 */
/* USER CODE END SysTick_IRQn 1 */
}void HAL_Delay ( volatile uint32_t millis)
{
/* remplace la fonction de délai de blocage de la bibliothèque HAL avec l'équivalent de la reconnaissance de threads FreeRTOS *//*(mappage HAL_Delay () à vTaskDelay () résout le problème du blocage d'une fonction dans un timeout)*/
osDelay (millis);}I am not sure if I am doing well or not
what do you think ?
2018-05-15 08:00 AM
and how
ensure that SysTick preempts ALL other interrupt sources and routine ?? is there something in the code I use it to ensure this please ???
2018-05-15 09:49 AM
It is as usable as any other interrupt.
I don't like software interrupt based counters for the kinds of applications the ST HAL uses them for.
If you use SysTick, and you use the tick count it generates, and you use that count in other interrupt routines, then you are going to have to ensure that SysTick preempts ALL other interrupt sources and routines.
I don't particularly like the HAL implementation.
When your call-back routines are called you are running in interrupt context, you should do what you need quickly and leave, or queue more complex processing for a deferred thread or worker task.
2018-05-15 11:19 PM
Hello,
I would recommend to you to keep SysTick as a time base for FreeRTOS. In this case it will have lowest possible priority (0xF in STM32) and the same like PendSV.
Both of them are specified in FreeRTOSConfig.h file as 'configLIBRARY_LOWEST_INTERRUPT_PRIORITY'.
If you are using HAL libraries you would need a timer to generate all delay functions and timeouts. For this I would suggest to use either TIM6 or TIM7. Both are 16 bit without any input/output channels, so you would not loose any input/output timer channels. If you are using STM32CubeMX for code generation this timer assignment can be done within SYS peripheral section -> Timebase. This timer (used by HAL) will have highest possible priority (0).
Concerning rest of the interrupts you need to specify which interrupts will execute functions of FreeRTOS. For those interrupts you should set priority specified by configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY (by default in STM32CubeMX it is set to 5). Rest of the interrupts should have higher priority (lower number).
In such a model your hardware and its interrupts which will not use OS functions will not be interrupted/blocked by OS as operating system in most of its functions is using critical sections which are blocking interrupts to the level of configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY.
I hope it clarifies the topic a bit.
Best Regards,
Artur
2018-05-16 12:03 AM
Hello,
Thank you so much
Artur for your reply .
in reeRTOSConfig.h I have this
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5
#define configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )
#define configPRIO_BITS __NVIC_PRIO_BITS with
__NVIC_PRIO_BITS 4
the interruption priorities is correct right ??
the functino HAL_Delay and HAL_GetDelay are weak functon so I thought to rewrite them with using the freeRTOS functinos like this :
uint32_t HAL_GetTick(void)
{ return osKernelSysTick();}/*** @brief This function handles System tick timer.*/void SysTick_Handler(void){ /* USER CODE BEGIN SysTick_IRQn 0 */if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED)
{ osSystickHandler(); }/* USER CODE END SysTick_IRQn 0 */
}void HAL_Delay ( volatile uint32_t millis)
{
/* remplace la fonction de délai de blocage de la bibliothèque HAL avec l'équivalent de la reconnaissance de threads FreeRTOS *//*(mappage HAL_Delay () à vTaskDelay () résout le problème du blocage d'une fonction dans un timeout)*/
osDelay (millis);}When I debug it blocks in portmacro.h of FreeRTOS in this function
portFORCE_INLINE static void vPortRaiseBASEPRI( void )
{uint32_t ulNewBASEPRI;__asm volatile
( ' mov %0, %1 \n' \ ' msr basepri, %0 \n' \ ' isb \n' \ ' dsb \n' \ :'=r' (ulNewBASEPRI) : 'i' ( configMAX_SYSCALL_INTERRUPT_PRIORITY ) );}If I am not wrong the vPortRaiseBASEPRI function is related to the priorities right ??
How can solve this please ?
Thank you so much in advance
Best regards