The Firmware Module System debug stack (in the FM_Debug product) supports sending information back to the host from programs running on the embedded target through a method known as semi-hosting. Semi-hosting requires coordination between the target program and the debug server and allow stdio calls such as printf to send text strings to the host for viewing in a console or other tool.
The target firmware must be linked against versions of low-level C-library calls that signal hardware breakpoints using the bkpt instruction (for cortex-M targets). The necessary implementation is found in the "rdimon" libraries available for the newlib-nano library that the Firmware Module System uses as its standard application library. This is all handled automatically by the build system and the customer need only use the BuildTestExec API to enable their application for semi-hosting.
It is important to understand that semi-hosted applications can only function with a debugger attached (in other words, only on the MSP432 Launchpad) - since it is the debugger that must detect and handle the breakpoints that are inserted into the application. Without an attached debugger and "semi-hosting aware" debug server, the application will halt on any printf statement. This is why the customer must explicitly request to build a "test" executable. We don't want production-ready applications built with the possibility of halting.
We at Firmware Modules understand customers that embrace a "fly what you test" philosophy and we will support other methods of logging and runtime application inspection that can be left enabled in release images.