2014-06-04 05:57 AM
The HAL_GetTick() is used implement timeouts within the HAL library with code similar to:
/* Get timeout */ timeout = HAL_GetTick() + HSE_TIMEOUT_VALUE; /* Wait till HSE is disabled */ while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) != RESET) { if(HAL_GetTick() >= timeout) { return HAL_TIMEOUT; } }However there is no consideration for timer rollover which will occur after approximately 47 days. This will lead to unexpected behavior where a timeout will fire before the timeout period expires. Unfortunately similar timer code to this is used pervasively throughout the HAL.On a related note is there an official bug tracker for the HAL library, or is this forum the suggested route for reporting bugs?Matt #i-want-to-smack-people2014-06-04 07:13 AM
Is the clock/interrupt even ticking at this point?
The new library is full of this amateurish crap...[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/%5bbug%20report%5d%20Bug%20in%20HAL%20%28SPL%29%20delay%20function&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=230]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2F[bug%20report]%20Bug%20in%20HAL%20%28SPL%29%20delay%20function&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=230[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/STM32F4xx%20HAL_TIM_IRQHandler%20misses%20interrupts%20on%20nearly%20overlapping%20TIM%20interrupts&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx¤tviews=73]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fSTM32Java%2fSTM32F4xx%20HAL_TIM_IRQHandler%20misses%20interrupts%20on%20nearly%20overlapping%20TIM%20interrupts&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2FAllItems.aspx¤tviews=73[DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/STM32CubeF4%20__HAL_UART_CLEAR_FLAG%20macro%20is%20incorrect&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx¤tviews=58]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fSTM32Java%2fSTM32CubeF4%20__HAL_UART_CLEAR_FLAG%20macro%20is%20incorrect&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https%3A%2F%2Fmy.st.com%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2FAllItems.aspx¤tviews=582014-06-04 07:52 AM
SysTick may not be active at this point - I simply copied the first example of this timeout structure I saw. There are about 150 places throughout the HAL with this defect.
So the developer must assume that any call that can return HAL_TIMEOUT may return HAL_TIMEOUT at random even when there is no underlying failure.. I suppose this is marginally better than the library becoming stuck in a tight loop polling for a bit that will never become set.Thanks for the link, I see ST is already aware of this problem.2014-06-17 08:29 AM
Hi Matt,
We have already the limitation in the STM32Cube HAL bugs list, it is resolved within CubeL0, and will be fixed in next releases of CubeF4 (early July).Thanks for the report.With regards.2015-12-21 04:13 AM
My bad, please forget about my previous post.
I re-checked and I suppose there should not be any tick overrun problem with the HAL I use. Sorry for the spam.