Variadic functions (like prinf)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 12:28 AM
Hi community,
I wrote the following function
UINT PrintOut(const char* format, ...)
{
va_list args;
va_start(args, format);
char buffer[1024] = { 0 };
vsprintf(buffer, format, args);
va_end(args);
return PrintString(buffer);
}
No problems at compiling time, but at runtime the execution falls in HardFault.
Any suggestion?
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 1:59 AM
Probably related to 1KB stack usage.
See if making buffer static changes failure or results in Linker flagging memory size issue.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 1:10 AM
The code looks OK. Debug as usual. HardFault where? The debugger of CubeIDE has convenient tool to analyze HardFaults.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 1:12 AM - edited ‎2024-04-18 1:12 AM
So where, exactly, does the Hard Fault occur?
And what Fault is reported?
Some links here on debugging Cortex-M Hard Faults:
https://community.arm.com/support-forums/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault
See also CubeIDE Fault Analyser:
https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf
A complex system designed from scratch never works and cannot be patched up to make it work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 1:27 AM
Line 6 is a waste of code. Isn't line 7 copying data over buffer? In embedded development especially, all code should be for a reason and no code should be without a reason.
Line 7 should use vsnprintf. Else what would happen if the format or its expansions overrun buffer?
Ways this code could fail are to numerous to list. Let it hard-fault in a debugger and then debug it. Configure your IDE or makefile to generate a link map file and check that for the addresses in the hard-fault information. Check ST's applicable programmer manual for your variety of STM32. Search community for other posts on hard faults.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 1:41 AM
@diego-z.esse-ti wrote:I wrote the following function
Why?
Why not just use printf() - you just have to add a simple write() function to support output to whatever device you require; eg, UART.
The bulk of the code in printf() is accounted for by vsprintf() anyhow - so you're not saving much (if anything).
https://shawnhymel.com/1873/how-to-use-printf-on-stm32/
A complex system designed from scratch never works and cannot be patched up to make it work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 1:59 AM
Probably related to 1KB stack usage.
See if making buffer static changes failure or results in Linker flagging memory size issue.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 9:40 AM
Thank you @Tesla DeLorean,
you nailed the problem!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-04-18 10:15 AM
Then you have a worse problem. No detection of stack growing out of limits.
