2018-06-10 02:21 PM
I am developing for a STM32L462 using SW4STM32 eclipse and CubeMx with FreeRtos quite successfully up to this point. The application is interrupt event message driven as you would expect. I need to enable Tickless Idle and use CubeMx to enable the define in FreeRtosConfig.h (like any of the other FreeRtos capabilities) but am having a &sharpinclude wierdness
In the before configuration, configUSE_TICKLESS_IDLE is nowhere present in FreeRTOSConfig.h thus FreeRtos.h conditionally supplies &sharpdefine configUSE_TICKLESS_IDLE 0
In the after configuration, FreeRtosConfig.h supplies a &sharpdefine configUSE_TICKLESS_IDLE 1. I have verified that this properly suppresses the above define within FreeRtos.h
FreeRtos.h is then imported into core.c to configure the various cpu dependent options and, for some reason, all of the
&sharpif (configUSE_TICKLESS_IDLE ==1) conditionals fail to activate as they should.
I have verified that at the end of FreeRtos configUSE_TICKLESS_IDLE==1 IS STILL DEFINED but right after the include in core.c it has somehow reverted to configUSE_TICKLESS_IDLE == 0
Has anyone else ever encountered a similar problem with a define not propagating out of an include like this and what I should be looking for to fix it?
#include-weirdness #visability-of-a-define #freertos #tickless #configuse_tickless_idle2018-06-10 02:43 PM
Never Mind.
For some reason the weirdness went away. What I did was to cycle the CubeMx L4 the library revision from STM32Cube_FW_L4_V1.10.0 to STM32Cube_FW_L4_V1.12.0 and back again with code regen and rebuilds in each state. I'm guessing, at this point, that one or more of the build control files ended up pointing at the wrong thing and couldn't tell me about it and that performing the library cycling fixed it
While I like not having the issue, I hate the fact that this subtle issue seems to have some deep weirdness that consumed a number of head scratching days. Stability is much preferred.