Forums

CubeMX and FreeRTOS: Systick

Started by pozz December 15, 2019
As you know, I'm playing with STM32 and CubeMX autogeneration code tool. 
I don't like ST HAL libraries generated by CubeMX, but this is my first 
approach to STM32 MCUs and CubeMX tool lets me have a fully-functional 
project in minutes. Maybe I will rewrite some HAL drivers in the future, 
but at the moment I'd like to leave with them.

Now I have to add FreeRTOS and this is very simple with CubeMX. However 
I have some doubts.

First of all CubeMX strongly suggests to change hw timer for ST HAL, 
because Systick is already used by FreeRTOS. I understood the problem is 
with interrupt priority: ST HAL needs the highest priority (because 
ticks counting must continue during whatever ISR, because some ISR code 
could wait for some time... how bad!!!); FreeRTOS needs the lowest 
priority (sincerely I couldn't understand why).

If you don't call ST HAL functions that uses ticks from ISR, you can 
leave with both modules (ST HAL and FreeRTOS) using Systick. I'm not 
going to block an ISR waiting for ms, so this limitation is acceptable 
to me. However I suspect some ST HAL ISR (USB? SD?) call HAL delay 
functions, so I can't be sure I will respect the limitation.

At the moment, it seems the only solution is to use two different hw 
timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste 
of resources, but there isn't another immediate solution.

I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can 
be done with UART, SPI and similar simple peripherals. But it takes time 
and anyway I will never rewrite USB or other complex driver.

What is your solution?

luni, 16 decembrie 2019, 02:30:17 UTC+2, pozz a scris:
> As you know, I'm playing with STM32 and CubeMX autogeneration code tool. > I don't like ST HAL libraries generated by CubeMX, but this is my first > approach to STM32 MCUs and CubeMX tool lets me have a fully-functional > project in minutes. Maybe I will rewrite some HAL drivers in the future, > but at the moment I'd like to leave with them. > > Now I have to add FreeRTOS and this is very simple with CubeMX. However > I have some doubts. > > First of all CubeMX strongly suggests to change hw timer for ST HAL, > because Systick is already used by FreeRTOS. I understood the problem is > with interrupt priority: ST HAL needs the highest priority (because > ticks counting must continue during whatever ISR, because some ISR code > could wait for some time... how bad!!!); FreeRTOS needs the lowest > priority (sincerely I couldn't understand why). > > If you don't call ST HAL functions that uses ticks from ISR, you can > leave with both modules (ST HAL and FreeRTOS) using Systick. I'm not > going to block an ISR waiting for ms, so this limitation is acceptable > to me. However I suspect some ST HAL ISR (USB? SD?) call HAL delay > functions, so I can't be sure I will respect the limitation. > > At the moment, it seems the only solution is to use two different hw > timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste > of resources, but there isn't another immediate solution. > > I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can > be done with UART, SPI and similar simple peripherals. But it takes time > and anyway I will never rewrite USB or other complex driver. > > What is your solution?
If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes". CubeMX or not.
Il 16/12/2019 08:01, raimond.dragomir@gmail.com ha scritto:
 >> [...]
>> What is your solution? > > If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes". > CubeMX or not.
Oh yes, I know. Anyway starting with a fully-functional project thanks to CubeMX is very good. I use the next time to improve CubeMX code and my question regarding Systick was born from this goal.
luni, 16 decembrie 2019, 10:11:30 UTC+2, pozz a scris:
> Il 16/12/2019 08:01, raimond.dragomir@gmail.com ha scritto: > >> [...] > >> What is your solution? > > > > If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes". > > CubeMX or not. > > Oh yes, I know. Anyway starting with a fully-functional project thanks > to CubeMX is very good. I use the next time to improve CubeMX code and > my question regarding Systick was born from this goal.
CubeMX is about the initializations. It's a pitty it doesn't have a "register level" mode. It uses HAL, LL, whatever, so you will need to use these drivers in your application AFTER the CubeMX. Do you understand the init code generated by CubeMX? How much documented is the HAL, LL whatever? How easy it is to cross-reference the HAL, LL to the real user manual of the chip? Do you really know what to do next AFTER the CubeMX generated his code? Or, how easy it is to continue and write your own application AFTER the CubeMX? You need to answer these questions first. I think it's too early to improve the CubeMX code.
Il 16/12/2019 09:31, raimond.dragomir@gmail.com ha scritto:
> luni, 16 decembrie 2019, 10:11:30 UTC+2, pozz a scris: >> Il 16/12/2019 08:01, raimond.dragomir@gmail.com ha scritto: >> >> [...] >>>> What is your solution? >>> >>> If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes". >>> CubeMX or not. >> >> Oh yes, I know. Anyway starting with a fully-functional project thanks >> to CubeMX is very good. I use the next time to improve CubeMX code and >> my question regarding Systick was born from this goal. > > CubeMX is about the initializations. It's a pitty it doesn't have a "register level" mode. It uses HAL, LL, whatever, so you will need to use these drivers in your application AFTER the CubeMX.
I understood LL is somewhat "register level" mode, even if I'm using HAL yet.
> Do you understand the init code generated by CubeMX?
Yes, it's not difficult to follow the code with a debug.
> How much documented is the HAL, LL whatever?
> How easy it is to cross-reference the HAL, LL to the real user manual of the chip? I don't know, I will check when I use them. At the moment I'm working on a code already written by someone else.
> Do you really know what to do next AFTER the CubeMX generated his code?
Build and test. Write the main application.
> Or, how easy it is to continue and write your own application AFTER the CubeMX?
In my experience, nothing is easy.
> You need to answer these questions first. I think it's too early to improve the CubeMX code.
On Sunday, December 15, 2019 at 7:30:17 PM UTC-5, pozz wrote:
> At the moment, it seems the only solution is to use two different hw > timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste > of resources, but there isn't another immediate solution. > > I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can > be done with UART, SPI and similar simple peripherals. But it takes time > and anyway I will never rewrite USB or other complex driver. > > What is your solution?
First, use systick for FreeRTOS and a different timer for HAL. Second, you probably will need to rewrite ST drivers to properly use OS facilities instead of idiotic timer-based polling etc. Especially USB, which is incomplete, buggy, and not integrated with OS. I still have to track down and fix periodic dropping of 64-byte packets during USB-CDC transmission to host, aaarrrggg... Third, you may find ST drivers non-performant due to above issues plus bizarre number of layers and pointers to pointers to static structures. Hope that helps, Best Regards, Dave
On 16.12.19 15:57, Dave Nadler wrote:
> On Sunday, December 15, 2019 at 7:30:17 PM UTC-5, pozz wrote: >> At the moment, it seems the only solution is to use two different hw >> timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste >> of resources, but there isn't another immediate solution. >> >> I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can >> be done with UART, SPI and similar simple peripherals. But it takes time >> and anyway I will never rewrite USB or other complex driver. >> >> What is your solution? > > First, use systick for FreeRTOS and a different timer for HAL. > > Second, you probably will need to rewrite ST drivers to properly > use OS facilities instead of idiotic timer-based polling etc. > Especially USB, which is incomplete, buggy, and not integrated with OS. > I still have to track down and fix periodic dropping of 64-byte packets > during USB-CDC transmission to host, aaarrrggg... > > Third, you may find ST drivers non-performant due to above issues > plus bizarre number of layers and pointers to pointers to static structures. > > Hope that helps, > Best Regards, Dave
Both ST and Atmel hardware-builder created code is not worth the trouble needed to debug it. I'd like instead have honest hardware descriptions. I lost 3 weeks on clock initialization, as the hardware description did not tell that only one control field can be changed at any one time, or the wait-for-ready functionality does never get ready. -- -TV
On Mon, 16 Dec 2019 13:42:57 +0100, pozz <pozzugno@gmail.com> wrote:

>Il 16/12/2019 09:31, raimond.dragomir@gmail.com ha scritto: >> luni, 16 decembrie 2019, 10:11:30 UTC+2, pozz a scris: >>> Il 16/12/2019 08:01, raimond.dragomir@gmail.com ha scritto: >>> >> [...] >>>>> What is your solution? >>>> >>>> If you don't have any experience with STM32 chips, then expect much much longer time to have a fully functional project than "minutes". >>>> CubeMX or not. >>> >>> Oh yes, I know. Anyway starting with a fully-functional project thanks >>> to CubeMX is very good. I use the next time to improve CubeMX code and >>> my question regarding Systick was born from this goal. >> >> CubeMX is about the initializations. It's a pitty it doesn't have a "register level" mode. It uses HAL, LL, whatever, so you will need to use these drivers in your application AFTER the CubeMX. > >I understood LL is somewhat "register level" mode, even if I'm using HAL
I generated a project in LL mode recently and when I looked at the generated C code, it looked very similar to HAL generated code. Since I have a hard time trying to follow the HAL code, I just use the HAL code which I am semi-familiar with and leave it at that. Then, of course, use low level register code of my own after things are initialized.
>yet. > >> Do you understand the init code generated by CubeMX? > >Yes, it's not difficult to follow the code with a debug. > >> How much documented is the HAL, LL whatever? > > How easy it is to cross-reference the HAL, LL to the real user manual >of the chip? > >I don't know, I will check when I use them. At the moment I'm working on >a code already written by someone else. > > >> Do you really know what to do next AFTER the CubeMX generated his code? > >Build and test. >Write the main application. > >> Or, how easy it is to continue and write your own application AFTER the CubeMX? > >In my experience, nothing is easy. > > >> You need to answer these questions first. I think it's too early to improve the CubeMX code.
Il 16/12/2019 14:57, Dave Nadler ha scritto:
> On Sunday, December 15, 2019 at 7:30:17 PM UTC-5, pozz wrote: >> At the moment, it seems the only solution is to use two different hw >> timers (systick and another timer) for ST HAL and FreeRTOS. It's a waste >> of resources, but there isn't another immediate solution. >> >> I know I can rewrite ST HAL drivers to avoid delays in ISR, but this can >> be done with UART, SPI and similar simple peripherals. But it takes time >> and anyway I will never rewrite USB or other complex driver. >> >> What is your solution? > > First, use systick for FreeRTOS and a different timer for HAL.
What is the real reason to proceed in this way? Does HAL code really use ticks in ISRs, that would block forever if the HAL ticking timer has the lowest priority (as the ticking timer of FreeRTOS)?
> Second, you probably will need to rewrite ST drivers to properly > use OS facilities instead of idiotic timer-based polling etc.
Do you know of projects with those drivers rewritten in a better way? Mainly: UART, SPI and I2C.
> Especially USB, which is incomplete, buggy, and not integrated with OS. > I still have to track down and fix periodic dropping of 64-byte packets > during USB-CDC transmission to host, aaarrrggg...
Same question as before.
> Third, you may find ST drivers non-performant due to above issues > plus bizarre number of layers and pointers to pointers to static structures.
Yes I know. At the moment, I'd like to leave with them. Optimization can be done later. Another question related to STM32 world. What is the main community site? Official ST community appears very bad initially. I posted two times for wrong, because I thought that was a search form, not a new post form. ST Community website has two sections: Communities, that seem not frequented, and Q&A taht seem much more updated. I think I have found a bug in MX initialization code. HAL_InitTick() is called two times: first during HAL_Init() and second during SystemClock_Config()/HAL_RCC_ClockConfig() [*]. The first time HAL_InitTick(TICK_INT_PRIORITY) is used. Second time HAL_InitTick(uwTickPrio) is used. If timebase source is Systick, HAL_InitTick() in stm32l4xx_hal.c updates the variable uwTickPrio. If timebase source is TIM1, HAL_InitTick() in stm32l4xx_hal_tim.c doesn't update uwTickPrio. So the second time HAL_InitTick() is called, the value of uwTickPrio is the initialization value that is an invalid priority. When HAL_NVIC_SetPriority() is called the second time, an assert is fired if the priority number is invalid. void HAL_NVIC_SetPriority(IRQn_Type IRQn, uint32_t PreemptPriority, uint32_t SubPriority) { uint32_t prioritygroup = 0x00; /* Check the parameters */ assert_param(IS_NVIC_SUB_PRIORITY(SubPriority)); assert_param(IS_NVIC_PREEMPTION_PRIORITY(PreemptPriority)); prioritygroup = NVIC_GetPriorityGrouping(); NVIC_SetPriority(IRQn, NVIC_EncodePriority(prioritygroup, PreemptPriority, SubPriority)); } [*] I don't know exactly why initialization code needs to initialize ticks two times. I imagine the first time ticks are initialized with the default/startup clock configuration, so ticks can be used *before* clock is configured. After clocks are configured, the ticks are re-initialized again with the final configuration.
On Tuesday, December 17, 2019 at 5:30:48 AM UTC-5, pozz wrote:
> Il 16/12/2019 14:57, Dave Nadler ha scritto: > > Second, you probably will need to rewrite ST drivers to properly > > use OS facilities instead of idiotic timer-based polling etc. > > Do you know of projects with those drivers rewritten in a better way? > Mainly: UART, SPI and I2C. > > > Especially USB, which is incomplete, buggy, and not integrated with OS. > > I still have to track down and fix periodic dropping of 64-byte packets > > during USB-CDC transmission to host, aaarrrggg... > > Same question as before. > > > > Third, you may find ST drivers non-performant due to above issues > > plus bizarre number of layers and pointers to pointers to static structures. > > Yes I know. At the moment, I'd like to leave with them. Optimization can > be done later. > > Another question related to STM32 world. What is the main community > site? Official ST community appears very bad initially. I posted two > times for wrong, because I thought that was a search form, not a new > post form. > > ST Community website has two sections: Communities, that seem not > frequented, and Q&A taht seem much more updated.
The community is helpful but the forum software is pathetic and constantly complained about. ST staff are haphazard about responding to bugs or questions. As far as a good set of drivers, there are many isolated examples, but not from ST, and of course they are different for different chip families. ARM Embed claim to have a complete, solid, debugged RTOS and stack (Ethernet, file system, USB, some drivers). I haven't tried it but if I'd known how much time I'd waste with ST stuff maybe I'd have gone that route, but who knows if its really better. Hope that helps! Best Regards, Dave