Program crashes while calling snprintf API

dinodavid4 wrote on Friday, March 18, 2016:

I have a program working in baremetal. I now want to run the same program in FREERTOS.
However at certain point of time when this function (snprintf )is executed the program crashes suddenly ie it swithces to dabort.asm file.

I have no clue about whats happening ? Could any one give some pointers.


rtel wrote on Friday, March 18, 2016:

First pointer: - we need to know which port you are using (in particular, which compiler you are using for what target and where the snprintf() is coming from) before we can provide a proper answer.

Have you seen the following: in particular, do you have stack overflow checking switched on, do you have configASSERT() defined, etc.

heinbali01 wrote on Saturday, March 19, 2016:


Please tell more about your port / compiler / platform.

this function (snprintf()) is executed the program crashes suddenly

Some implementations of snprintf() use big amounts of stack. And often snprintf() can not be used from within an ISR.
As for the stack usage, you may try increase the stack and call ‘snprintf()’ again. Also make sure that the parameters are correct.

If not, the following implementation of [v]s[n]printf():

  • uses a small amount of stack
  • recognises a quite complete syntax format
  • does not implement floating point formats (%f %g)

I attached the latest 160112 version as a separate file. Just link printf-stdarg.c in your project to test it. The complete sources can be found at Labs download

dinodavid4 wrote on Saturday, March 19, 2016:


I am using TI’s Hercules(TMS570LS3137) development board. My programming environment is CCS (Code Composer Studio). I am writing data to UART port. Therefore before writing to UART I convert integer value to strings using snprintf() function. Since I am porting my code from baremetal to FreeRTOS, the same code without creating any task was executed in the ISR. It worked.
But now I have to split the work across different tasks. So as a first step, I create 1 task and then trying to evaluate. I will verify about stack size and inform you

ammaree wrote on Sunday, March 27, 2016:

Hi Dino,

I use CCS 6.1.2 with a CC3200 and the TI SDK. The ?printf() functionality is extremely convoluted so I ended up developing my own.
the xprintf library has since grown to be quite bit itself but can be pared down significantly by excluding some esoteric functionality. Nice to have items include:

  • Full floating point support including %[e/EgG] with limited NaN support
  • Significant date and (absolute and relative/elapsed) time (ISO/POSIX) formatting built in.
  • Very powerful hexdump output with significant control over byte/short/word or llong group, separators etc exactly like debug dump style.
  • builtin IP address and MAC address formatting
  • Long and long long support for un/signed integers, in octal, hex or decimal
  • decimal digit grouping support
  • NO dynamic memory allocation, and reasonably limited stack requirements
  • Support display of values in formatted binary representation.
  • Support for pointer formatting, integrated into hexdump or independently
  • Able to selective control inclusion of the functionality required, to keep the size down
  • AND it supports output to strings, UART/console circular buffers and/or files with the provision of a single 1 line function for each…

Maybe have a look at there are also some other support functions there

Richard/Hein, welcom to add some links and/or references to it on the FrreeRTOS web site.


heinbali01 wrote on Sunday, March 27, 2016:

Hi Andre,

Thanks for that link. It looks good and very complete.
It uses the same method of declaring a small struct on stack that is carried around.

For IP-address printing I chose a somewhat downward-compatible format “%xip”. If the original sprint() is used, will appear as a hex number C0A80203ip.

What is interesting is what snprintf() does when the buffer is too small. What is the return value? Is the resulting string always nul-terminated?

ammaree wrote on Sunday, March 27, 2016:

Hi Hein,

xsnprintf() will currently simply discard any extra characters,
It is handled in line 162 vPrintChar() where all print streams go through
The nul termination will also always be done, see line 1149 in xsnprintf()
The return value is always the actual number of characters written, which will be no more than the string buffer size minus 1, or that is how I remember the theory

From all my tests no overflow happens and no memory gets corrupted.

The name length limitation is available in the xnprintf() function where the overflow will also be discarded.