Closed fra87 closed 1 year ago
Hello @fra87 ,
The FreeRTOS files are out of scope of STMicroelectronics as they are provided by FreeRTOS . All changes and updates to these files are not managed by our technical team. Therefore, you may report this issue on FreeRTOS GitHub. Please allow me then to close this issue and thank you for your contribution.
With regards,
FreeRTOSConfig.h is a file generated by STM32CubeMX wth all the User Code BEGIN/ENDs that STM inserts into generated code. Unfortunately, these do not bracket the generated code in question which. Simply adding these would be very useful, but the generated code should properly follow the calling conventions required by FreeRTOS.
I believe this was an unfortunate4 side effect of implementing these two "functions" as "dumb" C preprocessor macros losing any real compiler validation of calling convention.
The file referred to does not exist in ANY of the FreeRTOS repositories, nor has it ever existed in them.
Hello @fra87 ,
Thank you for this contribution. I can't reproduce the problem from my side. So could you please give us more details about how you got this issue? And share the steps you have followed to reproduce this problem.
Best Regards,
Hello @fra87 ,
Please allow me to close this thread as no activity. You may reopen it at anytime if you have any details to share with us in order to help you to solve the issue. Thank you for your comprehension.
With regards,
I think the current implementation of the PreSleep and PostSleep management is not correct when
configUSE_TICKLESS_IDLE == 1
.First the main issue: the current macro for
configPRE_SLEEP_PROCESSING
sets to zero thexModifiableIdleTime
variable, and thePreSleepProcessing
function is unable to modify it, thus preventing the MCU from entering low power mode. Removing the x = 0 part solves the problem, but 1) I'm not sure why it was added and 2) it gets added back every time I generate the code.The relevant code gets generated in FreeRTOSConfig.h file, and is used in Source/portable/GCC/ARM_CM4F/port.c.
An additional comment is that in the documentation I found online the prototype for PreSleepProcessing accepted a pointer to uint32_t, so that it could be modified.