STM32CubeMX fixes timer interrupt priority for HAL timer if RTOS enabled?

[willcfj]

I'm doing my first non-trivial program using FreeRTOS, so suspect this is a newbie question. Besides the timer for FreeRTOS (using SysTick), I need a timer for the HAL (using TIM7), and another timer for some high speed audio DSP routines (using TIM6 and triggering the DAC/ADC). The audio interrupt needs to be the highest of the three. Before the RTOS that was easy, I just make sure TIM6 had a higher priority than HAL SysTick.

FreeRTOS needs to use SysTick and there are lots of warnings about not sharing the HAL and FreeRTOS timer. No problem. I just told CubeMX to use TIM7 as it's timebase instead. Once I do that, however, CubeMX fixes the interrupt priority for TIM7 to be 0 and it can't be altered. I need it higher than 0 so I can have TIM6 for the audio work be the highest priority. With TIM7 fixed at 0, I can't do that.

Since CubeMX is going out of its way to do this, I assume there is a reason. Is it trying to stop me from doing something bad I don't understand? I do need an interrupt higher priority than the HAL's timebase for sure, and before adding FreeRTOS had ho problem doing this. I even tried a dummy configuration without FreeRTOS using TIM7 for the HAL timer interrupt and still could change it's priority just fine. It is only if FreeRTOS is enabled that TIM7's priority gets fixed.

Thanks in advance. I'm on the most current version of CubeMX (5.3.0)

will

[YIzAKat]

@Tilen MAJERLE​ 

Reading this a year later I also am concerned about the same issue. It sounds like a very similar project. I have an audio rate timer which must run at a constant sample rate frequency (48kHz) so I need it to take priority over pretty much everything else, it does some phase calculations which are relatively quick using fixed-point maths but has no RTOS calls so needn't be below the MAXX_SYSCALL priority level.

RTOS is used for some other HMI aspects and housekeeping. I likewise am concerned that the Cube generated software sets the alternative HAL timebase as a priority 0 and disables any ability to change it via the guided UI.

I understand the way that FreeRTOS the tick timer and the reasoning for the configLIBRARY_MAXX_SYSCALL_INTERRUPT_PRIORITY watershed, this is well documented in the FreeRTOS application notes.

Like the OP my main concern is that Cube has set the HAL timebase to 0 for some reason of which I'm unaware. I can change this in the code of course but I want to be sure that I'm not causing some obscure timing problem that I'm not aware of but the HAL architects are.

I was hoping to see the actual reply from the ST team here "R&D team is aware and will take a closer look." but I can't see any actual follow-up.

Any updates on this, please.

Jason.

[willcfj]

YlzAKat:

Unfortunately, I never got a satisfying answer from ST. I did get answers, but despite several attempts, the answer was never actually to the question I had. With the project working very well with no adverse effects for a couple months back then (and a year plus now), I declared my workaround a viable solution!

Like you I see there is good reason for what they do as a general rule, but unfortunately, they don't have a graceful way of handling a legitimate exception to that general rule. "It works, therefore it is OK" is not comforting with as many unknowns as there are with an RTOS. I clearly would have preferred some kind of confirmation from ST I wasn't breaking something unknown, but alas wasn't able to get it.

Good luck! Never hurts to try your luck with ST support. If you succeed, please post!

will

[Pavel A.]

>  I can change this in the code of course but I want to be sure that I'm not causing some obscure timing problem that I'm not aware of but the HAL architects are.

Since the HAL timer handler is very quick (just increments the counter) usually it is not a problem that it has priority 0.

If users know what they are doing, they can change the priority.

Otherwise, just trust ST (as you do with many other things) and don't fix what is not broken?

-- pa

[YIzAKat]

Thanks Pavel, if that is all that it does then that's fine. I'll happily leave well alone! This is the reason I use HAL :)

I merely wanted to ensure that the timer that I'm using to gain a constant sample rate frequency is not impacted by any other slow running ISR. The application uses RTOS but the audio signal processing is all ISR driven and completely independent of the RTOS tasks.

Simply a case that I read through the generated code for interrupts and was just surprised to find the HAL time-base had been set to 0 which seemed oddly high to me compared to the priority of the Systick timer it uses when an RTOS is not being used. I just wondered if the HAL needed a higher priority when an RTOS was in place for some reason.

[YIzAKat]

Thanks Will, I doesn't seem like there is a specific reason why that priority was chosen other than 'it can use it because it doesn't do much'. I'll go with Pavel's view that is just increments a counter and shouldn't impact my ISR servicing the sample frequency rate.

Just me wanting to ensure nothing is going to cause unexpected delays which turn into pops and crackles which are never popular with consumers!

Cheers,

Jason.

[willcfj]

Jason:

I did run into trouble with the HAL messing up my audio sampling. There was more going on than just incrementing a counter, unfortunately. The project was one of my most involved ones to date, the reason I had the RTOS was I had Ethernet (using LwIP), USB, an SD card, and a lot of other stuff all running in parallel and they all triggered off the timer tick. I'm not entirely sure which of those other drivers did it, but some did tie into that timer tick to perform background tasks and so the time spent in the RTOS timer tick interrupt was highly variable and enough to mess up my audio processing. Since the reason for an RTOS is to be able to do all that stuff in parallel, I'm not complaining, that is clearly working as designed! All that stuff wasn't "hard real time" like the audio needed to be. I just needed the audio processing to be the highest priority running "under" the RTOS to guarantee it was handled. Audio was "hard real time". I even slowed the RTOS timer tick to 100Hz instead of the default 1000Hz since none of the tasks it was doing were that urgent.

So, unfortunately, I think the answer to if the timer tick will mess up your audio is "it depends". You'll need to do some sleuthing to see what other code ties into the timer tick. I either dedicate or borrow a few GPIO pins to set/clear at the start/end of an interrupt and watch them on a scope. That is a quick and easy way to see how t hings are going if you have a scope. When a project is really complex I'll set the scope screen persistence to infinite and run the code through a lot of scenarios to see what might affect IRQ processing time too.

Good luck!

will

[YIzAKat]

Hi Will,

Yep OK. I do have a DSO so will do exactly what you've suggested, I have also used instrumented code with Segger's SystemView which helps monitor tasks/ISRs but is subject to timing issues itself depending on load.

Sounds like quite a similar use case. I'm using RTOS for display/touch sensor handling and a real-time MIDI feed (USART not USB). The MIDI uses DMA and RTOS stream buffers (first time I've used these) and the task has no problem keeping up with the relatively slow incoming data.

The audio calculations and SAI comms need absolute deterministic timing so run totally outside of the RTOS.

Thanks again!