Printf() does not work or causes strange effects
From DSignT Support Database
1 Problem
Sometimes a simple printf() (sprintf(), snprintf(), fprintf()) function call seems to fail since no CCS ( or terminal or buffer) output occurs. In other cases a printf() conversion of integer or float seems to affect data on the stack or delays or stalls the code execution for a long time.
Please check the following steps:
2 Solution
- missing include <stdio.h>.
Since printf() is a variadic function, calling such a function without a valid prototype invokes undefined behavior - missing trailing CR LF (\r\n) or flush.
By default the CCS output is line-buffered. To see the outputs close the line with CR LF or fflush(stdout); - insufficient stack size.
Make sure the stack size is at least 0x800. - insufficient heap size.
Each stream needs its own heap buffer. Make sure the heap size is at least 0x400 per stream. - Avoid C I/O inside interrupt handler functions.
C I/O functions are not reentrant and can cause a huge delay. - Stop-mode C I/O causes huge delay.
The current C I/O ABI works by setting a breakpoint at C$$IO$$. When this breakpoint is hit, the CPU is halted. The debugger then reads the contents of the .cio buffer through JTAG, performs the requested C I/O operation, writes the results back to .cio, and restarts the CPU. This is a very expensive operation in terms of cycles, and can be very disruptive in real-time systems.
3 Additional Links
More details can be found on TI's Wiki page:
http://processors.wiki.ti.com/index.php/Tips_for_using_printf
https://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/99381
https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/199796