STM32CubeF4 FreeRTOS Examples don't work correctly with HAL_GetTick
because the SysTick ISR has been assigned to the FreeRTOS xPortSysTickHandler() function without regard to HAL operations.
I think this can be corrected by calling HAL_IncTick() before calling xPortSysTickHandler() in SysTick_Handler() similar to as follows:
void SysTick_Handler(void)
{
// for internal HAL function HAL_GetTick() use
HAL_IncTick(); // *must* be called last or a Hard Fault will be generated
xPortSysTickHandler();
}
Note: For some reason, if the xPortSysTickHandler() function is not called last in SysTick_Handler(), a Hard Fault exception will occur!
Also note, it is quite confusing to see multiple instances of SysTick being initialized in these examples:
- in HAL_Init()
- in SystemClock_Config()
- in vTaskStartScheduler()
Also, HAL code initializes and expects the SysTicks generated to be 1 mS ticks,
but the FreeRTOS can easily be configured (via FreeRTOSConfig.hconfigTICK_RATE_HZ)
to be another value, which would cause the HAL-related timeouts to be incorrect.
A hard fault occurs because we execute the xPortSysTickHandler() and the scheduler is not yet started,
to avoid it you can add the following code into the systick interrupt:
void SysTick_Handler(void)
{
if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED)
{
xPortSysTickHandler();
} HAL_IncTick();
}
Actually in this STM32Cube version we have to configure both HAL and FreeRTOS ticks with Systick interrupt
and with the same frequency (every 1 ms), an update will be done on next releases
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();
}
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.
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?
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...
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.
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).
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.
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 ) // Read and Clear COUNTFLAG
uwTick++; // Interrupt is Disabled return uwTick; }
STM32CubeF4 FreeRTOS Examples don't work correctly with HAL_GetTick的更多相关文章
- Trimmomatic安装与使用
默认参数: java -jar trimmomatic-0.30.jar PE s_1_1_sequence.txt.gz s_1_2_sequence.txt.gzlane1_forward_pai ...
- TOMCAT-报错The BASEDIR environment variable is not defined correctly
<span style="font-size:18px;">The BASEDIR environment variable is not defined correc ...
- (转载)SQL Reporting Services (Expression Examples)
https://msdn.microsoft.com/en-us/library/ms157328(v=SQL.100).aspx Expressions are used frequently in ...
- 【TOMCAT启动异常】The BASEDIR environment variable is not defined correctly
<span style="font-size:18px;">The BASEDIR environment variable is not defined correc ...
- FreeRTOS如何结束和重新启动调度程序
大多数主机或桌面系统(比如Linux,Mac或Windows)都有一个正常的用例,你可以在早上启动操作系统,然后在晚上关闭它,然后你就离开机器.嵌入式系统是不同的:他们没有参加,他们应该“永远”运行. ...
- nRF52832 SDK15.3.0 基于ble_app_uart demo FreeRTOS移植
参考资料:https://blog.csdn.net/u010860832/article/details/86235993 这里把移植经验记录下来,供有需要的同学参考,有不对的地方也请大家批评指正. ...
- 在Amazon FreeRTOS V10中使用运行时统计信息
在MCU on Eclipse网站上看到Erich Styger在8月2日发的博文,一篇关于在Amazon FreeRTOS V10中使用运行时统计信息的文章,本人觉得很有启发,特将其翻译过来以备参考 ...
- FreeRTOS的内存管理
FreeRTOS提供了几个内存堆管理方案,有复杂的也有简单的.其中最简单的管理策略也能满足很多应用的要求,比如对安全要求高的应用,这些应用根本不允许动态内存分配的. FreeRTOS也允许你自己实现内 ...
- Think you can pronounce these 10 words correctly? You might be
Think you can pronounce these 10 words correctly? You might be surprised! Share Tweet Share Tagged ...
随机推荐
- CTSC2018&APIO2018游记
CTSC2018&APIO2018游记 Day 0 傍晚出发,从长沙通往帝都的软卧哟. 然而长沙某中学坐高铁比我们晚出发还早到 Day 1 为了正经地写游记我决定忍住不在博客里吐槽酒店. 午饭 ...
- 利用overflow-x实现横向滚动的xiaoguo
在进行app开发中经常遇到横向滚动的效果,相信很多人都是用js写的吧,其实用css的overflow-x也可以写出啦哦~~~ (1)介绍overflow-x: 1)浏览器支持 所有主流浏览器都支持 o ...
- 概率dp(A - Scout YYF I POJ - 3744 )
题目链接:https://cn.vjudge.net/contest/276241#problem/A 题目大意:首先输入n和p,n代表地雷的个数,p代表走一步的概率,1-p代表走两步的概率,然后问你 ...
- jdk1.8源码Synchronized及其实现原理
一.Synchronized的基本使用 关于Synchronized在JVM的原理(偏向锁,轻量级锁,重量级锁)可以参考 : http://www.cnblogs.com/dennyzhangdd/ ...
- 用代码截图去理解MVC原理
[概述] 看了蒋金楠先生的<Asp.Net Mvc框架揭密>,这本书详细地讲解了mvc的原理,很深奥也很复杂,看了几遍才将就明白了一点.他在第一章用了一个他自己写的mvc框架作为例子,代码 ...
- sqlmap工作流程图
- 整理OpenResty+Mysql+Tomcat+JFinal+Cannal+HUI
阿里云运维主机 118.190.89.22 26611 1.CentOS6.9下安装OpenResty 2.CentOS6.9下安装MariaDB10.2.11 3.使用Intellij IDEA把J ...
- hdu 5003 模拟水题 (2014鞍山网赛G题)
你的一系列得分 先降序排列 再按0.95^(i-1)*ai 这个公式计算你的每一个得分 最后求和 Sample Input12530 478Sample Output984.1000000000 # ...
- ref:spring配置数据库方式
ref:https://blog.csdn.net/alsyuan/article/details/73239240 1.使用org.springframework.jdbc.datasource.D ...
- 基于FPGA dspbuilder的DNLMS滤波器实现
自适应滤波器一直是信号处理领域的研究热点之一,经过多年的发展,已经被广泛应用于数字通信.回声消除.图像处理等领域.自适应滤波算法的研究始于20世纪50年代末,Widrow和Hoff等人最早 ...