FreeRTOS and HAL driver timeout issue

[stst9193]

Posted on November 21, 2014 at 19:54

Hello,

in xPortStartScheduler routine, the systick priority is forced to /* Make PendSV and SysTick the lowest priority interrupts. */ Some HAL interrupt drivers implement a time out based upon systick value. With systick priority set to lowest priority the HAL driver hangs instead of timing out. There is a need to either change the systick priority (but this is not straightforward since RTOS make assumption of systick interrupt priority)  or change the HAL handling of timeout while under interrupt by allowing the time tick to increment when reading its value.

[Lix Paulian]

Posted on November 22, 2014 at 15:34

The HAL_Delay function is implemented as ''weak'', so what I have done is to re-map it to the FreeRTOS task-aware vTaskDelay() function:

void

HAL_Delay(

volatile

uint32_t

millis)

{

/* replace HAL library blocking delay function

* with FreeRTOS thread aware equivalent */

vTaskDelay(millis);

}

In addition, I call the HAL_IncTick() function from the FreeRTOS TickHook:

void

vApplicationTickHook(

void

)

{

HAL_IncTick();

}

Hope it helps.Lix

[stst9193]

Posted on November 23, 2014 at 09:16

Hello Lix and all

Thank you for the hunts, but I think I need to be more specific in my problem description. I am using DMA in order to perform I2C reads/writes using functionnality from stm32f4xx_hal_i2c.c and stm32f4xx_hal_dma.c. When the DMA transfer completes, it calls '' I2C_DMAMasterTransmitCplt'' which itself call '' if(I2C_WaitOnFlagUntilTimeout(hi2c, I2C_FLAG_BTF, RESET, I2C_TIMEOUT_FLAG) != HAL_OK)'' (in fact multiple calls to the same function for different flags). The ''I2C_WaitOnFlagUntilTimeout''  relies on the HAL_GetTick. The problem: - in the free rtos port, the  systick priority is set to lowest priority - since my code is currently executing the DMA driver code, the systick cannot execute, so the I2C_WaitOnFlagUntilTimeout hangs in permanent loop if the flag did not reach the expected state. (please note that STM32CubeMx set the systick priority to the highest priority so the hang does not show up in non RTOS application). Since HAL_GetTick is declared weak (thanks Lix for mentionning it), I override it with: uint32_t HAL_GetTick(void) {   // GY bug with timeout function   uint32_t temp = SCB->ICSR & SCB_ICSR_VECTPENDING_Msk; //  )   if (temp ==  0x0f000UL)   {         SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk;         uwTick++;   }   // GY end bug with timeout function   return uwTick; } The timeout is now ''kind of''  working. (It would fail if i get event that would have higher priority than systick). In my opinion, this ''solution''  is a kludge on top of a combination of design flaws.  In the first place, and in fact the route cause of the problem, a driver is supposed to be short lived. The driver should never poll waiting on an event. Instead of polling it should just exit and let an I2c driver wait for the relevant interrupt. (eventually, driver could ''test the water'' and do the job if the flag is in the expected state in order to avoid extra interrupt, but this need to be carefully thought not to fall into time race condition). Doing so would return the processing to user level code allowing low priority drivers to execute and likely letting RTOS do its job. Then the FreeRTOS port should not move the systick priority as long as the base STM32F HAL drivers expect it to be the highest priority. Even if switching systick prirority to highest would solve the ''Driver timeout isssue'', it could only be a short term workaround since being stuck in a driver for tens of milliseconds is bad in standard environment and unacceptable in RTOS environment. Regards Gerard

[Lix Paulian]

Posted on November 23, 2014 at 22:09

Hi Gerard,

You should note several things: first and foremost, FreeRTOS sets the SysTick by itself, and if you try to override it is a bad idea (as the ST HAL libraries sometime do). Normally, the SysTick is set to prio 5 (check the FreeRTOSConfig.h file, the configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY define). That means that all interrupt handlers that use FreeRTOS APIs (semaphores, mutexes, queues, etc) must have a lower priority than the FreeRTOS scheduler. Only interrupt handlers that don't use FreeRTOS APIs can have higher priorities than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY. Therefore keeping the ST original SysTick priority is not an option, on the contrary, all initialisations of SysTick out of FreeRTOS should be eliminated (I found one in the USB Device Library, but maybe there are others too, didn't search for all).Now to my solutions: for one, re-mapping HAL_Delay() to vTaskDelay() solves the problem of blocking a function in a timeout. The FreeRTOS delay doesn't hold the whole processor, only the task that calls it.On another hand, by letting the FreeRTOS tickHook to increment HALs millisecond variable you still assure compatibility to possible functions that would directly use HAL_GetTick() function (as ''I2C_WaitOnFlagUntilTimeout'' does) but with the mention that it is task aware, as it is called from inside FreeRTOS. Moreover, there are no more priority issues, as long as the rule regarding calls from interrupts to the FreeRTOS APIs is observed (see also the FreeRTOS documentation).By the way, did you try the solution proposed by me? I see no reason that it doesn't solve your problem. You only have to take care not to use this delay in interrupt handlers. But who would insert delays in an interrupt handler anyway?Lix

[Lix Paulian]

Posted on November 23, 2014 at 22:22

And yes, you are right that most ST HAL drivers are not (yet) thread aware (in fact, there is a mention of this in the file stm32f4xx_hal_def.h, check the USE_RTOS define). So if you really want to do it properly, then you have to modify the drivers using FreeRTOS semaphores and queues between interrupt handlers and background driver functions. It's what I did e.g. for the USB CDC Device implementation as well as for UARTs.

The fact that the USE_RTOS was defined at all, may give us a slight hope that ST will sometimes later issue also HAL drivers that are RTOS aware. Only time will tell...

[stst9193]

Posted on November 24, 2014 at 10:28

Hi Lix,

Thanks again for those explanations. Yes, I did try your solution but it does not work for me.

You mention '' Normally, the systick is set to prio 5'' but I noticed it is set to 15 (both reading SCB->SHP from debugger and checking source code as described below). Did you initialize it by yourself to that value, and in that case how are you sure there are no side effect?   I concur with yourself that ''all initializations of SysTick out of FreeRTOS should be eliminated'' which is why I am reluctant to modify it.

****** explanantion of systick prio set to 15 ****

This is based on free rtos port from ST

From port.c around line 336 in xPortStartScheduler( void )

                /* Make PendSV and SysTick the lowest priority interrupts. */                      portNVIC_SYSPRI2_REG |= portNVIC_PENDSV_PRI;               portNVIC_SYSPRI2_REG |= portNVIC_SYSTICK_PRI;

Going through the various defines, we can find that both portNVIC_PENDSV_PRI and portNVIC_SYSTICK_PRI are based upon configKERNEL_INTERRUPT_PRIORITY, itself based on configLIBRARY_LOWEST_INTERRUPT_PRIORITY which is set to 15 (effectively the lowest priority /  highest priority number)

They are not based on configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY (value of 5)

****** end explanantion of systick prio set to 15 ****

If Systick prio was set to 5 and my driver interrupt set to higher value than 5 (lower prio) then I think that both your proposed solution and the ST provided HAL driver timeout would work.

Regarding another possibility I did already protect the I2C driver with semaphores and queues to make them RTOS safe for my application.

As you mentionned I also hope we will get RTOS aware HAL drivers

And to your question '' But who would insert delays in an interrupt handler anyway?'', one answer is (but may be not the only one) the STM32F4xx_I2C_hal.c handlers provided by ST.

Regards

Gerard

[Lix Paulian]

Posted on November 25, 2014 at 22:06

Hello,

You are right that the SysTick is set to prio 15, and this is true also for the stock FreeRTOS distribution for ARM. I was confused by the configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY define which is indeed set to 5. But this is another story.That being said, the truth is that there are many interrupt handlers in the HAL library that are not RTOS compliant, and unfortunately for this cases there is no other alternative than to write your our own driver. I jumped on HAL quite recently (about one month ago) and I am still discovering its shortcomings. I am amazed at how many interrupt handlers do delays in interrupt! As an example, I wrote my own UART interrupt handler (still based on HAL) using queues for transmit and receive to communicate between interrupt and background code.So I would do the same for I2C, as there are indeed calls to HAL_Delay() in the I2C interrupt handler. Just use a semaphore and transfer most of the processing out of the interrupt handler (i.e. deferred interrupt handling, see the FreeRTOS user guide).Lix

[stst9193]

Posted on November 26, 2014 at 08:52

Hi Lix,

Thanks for your comments. I concur with you about the shortcomings of the HAL drivers and the need to rewrite them to be user friendly in general (no wait for event loops or call for delay, no un-needed interrupt -or rather user configurable based on handle content- like the half transfer one in DMA) and FreeRTOS aware.  Overall the HAL driver concept is great but the implementation requires significant improvements to make it effective. I would appreciate if someone from ST would comment on the timefrane for improving the HAL drivers (i.e., making them RTOS aware) and for the freeRTOS port to take advantage of them. Regards Gerard

[Shang.Dawei]

Posted on July 29, 2015 at 16:27

uint32_t HAL_GetTick( 
void
)

{

if
( SysTick->CTRL & SysTick_CTRL_TICKINT_Msk ) 
// Interrupt is Enabled

{

if
( SCB->ICSR & SCB_ICSR_PENDSTSET_Msk ) 
// Interrupt is Blocked

{

SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk; 
// Clear Pend Bit

uwTick++;

}

}

else
if
( SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk ) 
//

uwTick++; 
// Interrupt is Disabled


return
uwTick;

}

[Shang.Dawei]

Posted on July 29, 2015 at 16:32

Can SysTick CountFlag always be polled ?