FreeRTOS Task Scheduler & GCC Optimisation Levels

Good day

I have been using MCUXpresso (NXP’s Eclipse-based IDE) to write code for a FreeRTOS-based project.
So far, FreeRTOS has been a wonderfully stable OS for this project.
However, I need to increase the speed at which the code executes, so I looked into GCC’s compiler optimisations.
Up until this point, I had not used any optimisation (used ‘None’ -O0).

I have enough space for the code to grow in size, so I am only optimising for speed.
For this reason, I chose to build my project with the ‘Optimise most’ (-O3) optimisation level.

Unfortunately, since I’ve made this change (no other changes), the task scheduler seems to not respond in the way it did before.
Many of the tasks that used to execute do not respond to their semaphores and task notifications.

Can someone please advise me on using GCC optimisation with FreeRTOS?
Is there a way to make it work?

FreeRTOS code itself is very unlikely the cause of your issues since it’s verified and known to work even with high/aggressive optimization levels.
Activating the optimizer might reveal various coding bugs.
Common pitfall of 'my perfectly running application stopped working in release/optimized build is e.g. missing volatile qualifiers where needed.
Did you try a less aggressive optimization level like ‘-O2’ ?
Bare in mind when running code from rather slow flash less code (using ‘-Os’) might also speed up your application with the nice side effect dealing with smaller binaries.
Good luck !

Hi there D_TTSA,

I have isolated at least two bugs in GCC related to optimization, so what you are seeing may be the result of erratic code being generated only at certain optimization levels.

Also, on top of the right-on-spot remarks of Hartmut, I’d like to add that depending on the MCU in question, the tradeoff between speed and size may be dramatic up to unbelievable. For example, on Cortex-M machines, speed optimization may imply code unfolding that minimizes memory accesses outside the core (yielding potential performance gains in factors of several thousands) but may in return blow up the code by a factor of 4-10 or more.

Which GCC version are you using?

Hi @rtel
I am using v10.2.0

Hi @hs2
Thank you for your detailed response!
You were correct about me missing the volatile qualifier for one of my tasks, so adding that seemed to fix a few problems.
However, there are still some issues with tasks - I think it may be to do with some of NXP’s drivers, but I’m still looking into it.

I’ve been running our tests for a day now using arm-none-eabi-gcc version 10.2.1 20201103 and -O3 and not seen any failures.

1 Like

@rtel Thanks for testing !
I’m also using GCC10.2 since it was released on Cortex-M3/4 and didn’t encounter any related issue.
And this was the case since I started using FreeRTOS (core) with GCC7 at that time :+1:

1 Like

Thank you everyone for your help.
At this point, I’m quite certain it is to do with NXP’s drivers, or their autogenerated code.
I can apply O3 on my source files, just not on the whole project.