In the previous post, we discussed how the pros and cons of using printf in an embedded system and how it could be used to provide information to help debug software. During that post, we saw that a printf statement to the debug terminal in e2 Studio was taking a little more than 60 milliseconds. The reader may be wondering why a simple statement could be taking so much time to execute on a real-time processor running upwards of 200 MHz. In today’s post, we are going to explore semi-hosting which is the culprit in our printf statement.

Semi-hosting is a capability that is built into ARM Cortex-M processors that allows i/o operations to be performed on a host PC from the embedded system through the debugging tool. These operations could be sending keyboard button presses to the embedded target, writing information to a file on the host PC, or transmitting printf strings from the embedded target into a terminal in the ISDE.

On the microcontroller itself, the processor uses Supervisory Call instructions (SVC’s) or the breakpoint (BKPT) instruction to halt the processor and notify the debugger that there is information that needs to be retrieved and sent to the host. As you might image, halting the processor in this way stops code execution which means that using semi-hosting will affect the applications real-time performance. Semi-hosting can still be useful; however, even though in many cases, it is slower than a developer might prefer.

The most common use for semi-hosting is to provide printf messages into a terminal. By default, e2 Studio is setup to enable semi-hosting for printf statements. The reader can verify that semi-hosting is enabled by going to their project properties and navigating to C/C++ Build > Settings > Tool Settings > Cross ARM C Linker > Miscellaneous. There is a linker flag settings for –specs-rdimon.specs that will include the Semi-hosting capabilities. These settings can be seen below:



Beyond that, the “Setting up and using printf” post describes how to use the semi-hosting printf capabilities. The printf functionality is actually very fast, requiring microseconds to store a string in a buffer, but the problem becomes the second a newline character \n is used, semi-hosting is invoked, the processor halted and the tens of millisecond transfer is started.

Semi-hosting is a neat idea and is certainly practical but in most circumstances developers are better off connecting printf to SCI, setting the baud rate to 115200 or even 1 Mbps and simply using a USB to UART converter with a terminal to get their debugging information. This methodology is far faster than the semi-hosting option.

In the next post, we will explore how to redirect printf to UART and explore the worst case timing that this provides a developer with.


Until next time,

Live long and profit!



Hot Tip of the Week

Make sure you subscribe to the Renesas Rulz Technical Bulletin Board System (TBBS) email alerts to get periodic push emails on important Synergy notifications, issues and work arounds. The TBBS is located here: and you can subscribe by clicking on the Join button in the bottom right of the TBBS screen. Select the email option you prefer with the digest options button. You will be better informed and more efficient. And who doesn’t want that?