Skip to content

Documentation suggestion for configCHECK_FOR_STACK_OVERFLOW and for LED_BUILTIN #69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wystewart opened this issue Apr 3, 2024 · 2 comments · Fixed by #71
Closed

Documentation suggestion for configCHECK_FOR_STACK_OVERFLOW and for LED_BUILTIN #69

wystewart opened this issue Apr 3, 2024 · 2 comments · Fixed by #71
Labels
enhancement New feature or request
Milestone

Comments

@wystewart
Copy link

wystewart commented Apr 3, 2024

The FreeRTOS web site says that one must implement function vApplicationStackOverflowHook when enabling configCHECK_FOR_STACK_OVERFLOW . This is not the case for STM32FreeRTOS as it is defined in STM32FreeRTOS.c and there is no option to override. Suggest to document this and to clarify that the user must ensure that LED_BUILTIN is defined in their variant.h for their board as vApplicationStackOverflowHook will hang (while 1) when stack overflow detected and flash the LED. At the very least of not documented, hopefully this post will be found by users through google and will be helpful.

Perhaps vApplicationStackOverflowHook and other error functions could be defined as weak in STM32FreeRTOS.c so that the user can override.

@wystewart wystewart added the enhancement New feature or request label Apr 3, 2024
@fpistm
Copy link
Member

fpistm commented Apr 3, 2024

Hi @wystewart
Right it was defined by the library but it can't be defined as weak as it already exist one weaked function.
Maybe an other weak function can be added and called by vApplicationStackOverflowHook like this user can redefine it.

Feel free to submit a PR to document or adding extra function or definition.

fpistm added a commit to fpistm/STM32FreeRTOS that referenced this issue Jul 25, 2024
configUSE_MALLOC_FAILED_HOOK and configCHECK_FOR_STACK_OVERFLOW
allow to define specific function to call when a malloc failed
or a stack overflow occured.
Respectively, vApplicationIdleHook and vApplicationStackOverflowHook.

Previous implementation provide them unconditionally preventing users
to define their own implementation. Now extra config is required to
have the default implementation:

/* Define default blink hook if configUSE_MALLOC_FAILED_HOOK_BLINK is 1 */
/* configUSE_MALLOC_FAILED_HOOK_BLINK */
/* Define default blink if configCHECK_FOR_STACK_OVERFLOW is 1 or 2 */
/* configCHECK_FOR_STACK_OVERFLOW_BLINK */

Fixes stm32duino#69.

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
fpistm added a commit to fpistm/STM32FreeRTOS that referenced this issue Jul 25, 2024
configUSE_MALLOC_FAILED_HOOK and configCHECK_FOR_STACK_OVERFLOW
allow to define specific function to call when a malloc failed
or a stack overflow occured.
Respectively, vApplicationIdleHook and vApplicationStackOverflowHook.

Previous implementation provide them unconditionally preventing users
to define their own implementation. Now extra config is required to
have the default implementation:

/* Set to 1 to use default blink hook if configUSE_MALLOC_FAILED_HOOK is 1 */
#ifndef configUSE_MALLOC_FAILED_HOOK_BLINK
  #define configUSE_MALLOC_FAILED_HOOK_BLINK  0
#endif
/* Set to 1 to used default blink if configCHECK_FOR_STACK_OVERFLOW is 1 or 2 */
#ifndef configCHECK_FOR_STACK_OVERFLOW_BLINK
  #define configCHECK_FOR_STACK_OVERFLOW_BLINK 0
#endif


Fixes stm32duino#69.

Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
@fpistm fpistm closed this as completed in d05df76 Jul 25, 2024
@fpistm fpistm added this to the 10.3.3 milestone Jul 25, 2024
@fpistm
Copy link
Member

fpistm commented Jul 25, 2024

Hi @wystewart
Now by default there is no function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

Successfully merging a pull request may close this issue.

2 participants