cancel
Showing results for 
Search instead for 
Did you mean: 

Bug: HAL not used for SysTick?

RAltm
Senior

Hi,

what's needed to make CubeIDE to use the HAL implementation for the SysTick? I'm using STM32L011F4 device. It seems that the generated code uses Systick_Handler() from stm32l0xx_it.c instead of HAL_SYSTICK_IRQHandler() from stm32l0xx_hal_cortex.c.

This seems to be something I observed when enabling LL for any of the used peripherals (which is an error IMHO) - it shouldn't disable the HAL for the SysTick or anything other than the affected peripheral.

Even in a project which hasn't enabled any peripherals, I can't get the HAL implementation for SysTick up and running.

I already reported some other bugs regarding using this device with CubeIDE - if this is another bug I've to get rid of CubeIDE, it isn't usable for me in this state. But I hope I only missed some setting.

Regards

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

CubeMX will generate its own SysTick_Handler, as you saw. This is the default implementation which will call HAL_IncTick. That's all you need.

See this bug report:

https://community.st.com/s/question/0D50X0000A1kvxcSQA/cubemx-5-bug-halsystickirqhandler-call-missing-from-systickhandler

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

6 REPLIES 6
TDK
Guru

CubeMX will generate its own SysTick_Handler, as you saw. This is the default implementation which will call HAL_IncTick. That's all you need.

See this bug report:

https://community.st.com/s/question/0D50X0000A1kvxcSQA/cubemx-5-bug-halsystickirqhandler-call-missing-from-systickhandler

If you feel a post has answered your question, please click "Accept as Solution".
TDK
Guru

> I can't get the HAL implementation for SysTick up and running.

Perhaps you can explain why you think it's not up and running. Is HAL_GetTick() not increasing? Does HAL_Delay never return?

If you feel a post has answered your question, please click "Accept as Solution".
RAltm
Senior

Hello @TDK​ ,

> CubeMX will generate its own SysTick_Handler, as you saw. This is the default implementation which will call HAL_IncTick. That's all you need.

> See this bug report:

No, it is not what I need 🙂 The former behaviour was that the HAL_SYSTICK_IRQHandler() was called. However, the link you provided indeed states that there was a change. Okay, but why is the SysTick handler only for debug? I want to hook up to the callback. Yes, I know I can modify the files, as it also was stated in your link.

But I don't get the reason why it's only for debug. If there's a real reason, then all other callbacks for peripherals should also be for debug only - most of them are useless anyway, because they're called on places in the HAL code where you'll loose the timing due to the (unneccessary in places) complexity of the HAL. Okay, to be honest, I only can confirm this for UART implementation.

>> I can't get the HAL implementation for SysTick up and running.

> Perhaps you can explain why you think it's not up and running. Is HAL_GetTick() not increasing? Does HAL_Delay never return?

Indeed SysTick_Handler() is called, as I wrote above, but I want it to call HAL_SYSTICK_IRQHandler() instead.

I assume HAL_GetTick() and HAL_Delay() are working, but HAL_Delay() is a blocking function (I assume, never used it) - blocking functions are a no-go 🙂

I prefer to have multiple software timers, which are initialized in application and counting down by SysTick. Querying them if they're (non-)zero allows me to do other tasks while the timer counts down.

So, it seems I've to restructure my code base... Thank you for pointing me to the new convention or "rules".

Regards

TDK
Guru

> So, it seems I've to restructure my code base...

Isn't that a little dramatic when all you have to do is add 1 line to SysTick_Handler?

Note that the IRQ never called HAL_SYSTICK_IRQHandler directly, it was always indirect through SysTick_Handler.

You do you, but if it were me I'd just add the line in the user section and move on with my project.

If you feel a post has answered your question, please click "Accept as Solution".
RAltm
Senior

Hello @TDK​ ,

>> So, it seems I've to restructure my code base...

> Isn't that a little dramatic when all you have to do is add 1 line to SysTick_Handler?

It depends on if this is really the only thing which has to be changed - for SysTick my answer is indeed dramatic 😉 But I'm not sure if any other things have changed with the new(er) CubeMX implementations.

> Note that the IRQ never called HAL_SYSTICK_IRQHandler directly, it was always indirect through SysTick_Handler.

> You do you, but if it were me I'd just add the line in the user section and move on with my project.

I'll check this when I'm back in office, I'm not sure if the "new" implementation has the user code tags.

Thank you.

Regards

RAltm
Senior

Hello @TDK​ ,

> I'll check this when I'm back in office, I'm not sure if the "new" implementation has the user code tags.

Verified, it works now. Interestingly I'm getting several warnings about redefinition of VDD_VALUE and PREFETCH_ENABLE from stm32L0xx_hal_conf.h file now. The only things which had changed since the last build were the additional call of HAL_SYSTICK_IRQHandler() in SysTick_Handler() and a reduction of stack/heap size from 512 to 256 bytes for both. Even reverting back to the original state will fire those warnings. But the initial problem was solved, so thank you for your help.

Regards