标签：
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:
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.
STM32CubeF4 FreeRTOS Examples don't work correctly with HAL_GetTick
标签：
原文地址：http://www.cnblogs.com/shangdawei/p/4684798.html
