Using printf() with FreeRTOS sometimes causes hardfaults
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-27 2:32 PM
I am working on using FreeRTOS for a project, and have implemented printf() debugging by redirecting it to a uart. This works great most of the time, and is very helpful for FreeRTOS debugging, as FreeRTOS_printf() and FreeRTOS_debug_printf() will leverage this functionality.
Unfortunately, it seems to cause hard faults frequently, but not in every case.
One call that consistently caused a hard fault was
FreeRTOS_printf( ( "FreeRTOS_connect: %u to %xip:%u\n", [...]);
Another one I had to manually remove was
FreeRTOS_debug_printf( ( "Socket %u -> [%s]:%u State %s->%s\n", [...]);
I came across a previous post which seemed to have a similar issue, but it appeared to have been resolved.
Is there more configuration that I need to implement to have this work in every case? Or is there something else I am missing?
Some more details about my implementation:
I am using CubeMX to generate my code
I am using OpenOCD and GCC
My printf implementation uses the following code
#ifdef __GNUC__
# define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
#else
# define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
#endif /* __GNUC__ */
PUTCHAR_PROTOTYPE
{
HAL_UART_Transmit(&huart3, (uint8_t *)&ch, 1, 0xFFFF);
return ch;
}
Thanks for reading, any insight is appreciated!
Solved! Go to Solution.
- Labels:
-
FreeRTOS
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 2:44 AM
Hello @skygreenslade
Could you please verify that you give the task that's calling FreeRTOS_printf() enough stack space. Printing functions often use a lot of stack space to format the string.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-27 2:37 PM
Perhaps the stack of the task calling printf is overflowing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 2:44 AM
Hello @skygreenslade
Could you please verify that you give the task that's calling FreeRTOS_printf() enough stack space. Printing functions often use a lot of stack space to format the string.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 5:49 AM - edited ‎2024-06-28 5:51 AM
Are you calling the print function from multiple tasks? I use a print from multiple tasks with no issues, maybe try something like below:
static void debugPrintUART(const char *pData);
void myprintf(const char *fmt, ...)
{
if(osMutexAcquire(debugPrint_MutexHandle, osWaitForever) == osOK)
{
static char buffer[256];
va_list args;
va_start(args, fmt);
vsnprintf(buffer, sizeof(buffer), fmt, args);
va_end(args);
debugPrintUART(buffer);
osMutexRelease(debugPrint_MutexHandle);
}
}
static void debugPrintUART(const char *pData)
{
HAL_UART_Transmit(&huart1, (uint8_t*)&pData[0], strlen(pData), 100);
}
Or you could have the debug print in a single task, and have the other tasks just message this one to do the print.. this may actually be a better alternative.
Task stack size maybe an issue as others mention.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-06-28 11:24 AM
It appears that this was the problem. Increasing my stack size has resolved the issue, thanks for everyone's help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-01 1:16 AM
Could you tell us what exact stack size you used before and what you have now? This can help others with the same problem in the future. Thanks in advance.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-02 7:02 AM
I haven't yet determined the minimum stack size required for the task that was the problem. It will depend on the application how big it needs to be, so I don't want to claim that a specific size will work.
As for the previous size, it had somehow been changed back to the default that CubeMX generates: 128 * 4.
