PRINTF with mbed

[hush]

Hey guys,

When I create an Embedded project with mbed, I no longer seem to be able to print out to console with PRINTF. I also tried using mbed’s print functionality without any luck:

Serial pc2(USBTX, USBRX);
pc2.printf(“this is a test”);     // Not working for me either

I also noticed that I no longer get the VisualGDB popup that says, “ARM semihosting system call detected. Do you want VisualGDB to handle those calls and emulate a basic console?”.
What do I need to do to be able to print to console again? Thanks!

[support]

Are you using the Segger J-Link software? Looks like the latest version breaks the semihosting support. We have not investigated this yet, but downgrading to an earlier one should solve the problem.

[hush]

No, I don’t believe I’m using Segger J-Link. I’m using ST’s VLink version 2.1 with OpenOCD.

[support]

Hi,

USB serial port-based printing and Semihosting-based printing are actually using different mechanisms. Did they both stop working?

Can you also reproduce it on a new project? Perhaps the problem happens because the stdlib actually sends the printed text when it encounters a ‘\n’ character and your example above does not send it?

[hush]

I tried creating a new ARM mbed project from scratch. I used…

Board: NUCLEO_F411RE
Floating Point: Hardware w/ Software interface
C Lib Type: Default
Reduce C++ Bins (checked)

Debug method: OpenOCD
Prog Interface: ST-Link v2.1
Debug Transport: use default
Before Debugging: Load into Flash/RAM

#include <mbed.h>

DigitalOut g_LED(LED1);
Serial pc(USBTX, USBRX);

int main()
{
for (;;)
{
g_LED = 1;
wait_ms(500);
g_LED = 0;
wait_ms(500);

printf(“Nothing happening here. Test int %d”, 100);
printf(“Breaks don’t seem to help: %d\n”, 100);
pc.printf(“This doesn’t do anything either”);
}
}

This produces the default “LEDBlink” example. The LED blinks fine, but the printf still doesn’t work as in my project like I describe above. This is a very simple example, so I expect this should work out of the box without any problems. Are you not seeing this if you try it with a STM32 board? Again, I still don’t get the popup about semihosting which sounds very suspicious to me. Thanks for looking into this.

 

[hush]

Ok, I figured out the serial based printing for mbed. I followed this link here for terminal setup:
https://developer.mbed.org/handbook/SerialPC
Unfortunately though, it looks like all printing to VS Output Console is either hijacked by mbed or just not working for whatever reason.

[support]

Hi,

By default mbed provides its own implementation of the _write() function that is used when you call printf().

You can replace it by a VisualGDB-provided one that will print to the Visual Studio window in 2 steps:

1. Remove the retarget.cpp file from your project
2. On the Embedded Frameworks page add reference to the Fast Semihosting and Profiler framework

Let us know if you encounter any problems.

[smartsystemdesign]

Hello,

I am having the same issue – not being able to print to the serial port via printf using mbed.  I’m using a Nucelo-L432KC board and created a simple project with the wizard using the blink LED with rtos template.

I tried adding a reference to the Fast Semihosting and Profiler framework and removing mbed_retarget.cpp from the project located in C:\Users\Username\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.mbed\platform.  Removing this file caused many errors preventing me from compiling.  If I leave the file in, I still get a couple errors (shown below).  Was this the wrong file?  I searched the project for retarget.cpp, and couldn’t find anything else.

Thanks,

Nate

• This reply was modified 6 years, 10 months ago by smartsystemdesign.

[smartsystemdesign]

I got it working.  It was a serial port baud rate issue.  It works without removing retarget.cpp or adding Fast Semihosting and Profiler framework.

[steveh]

I’m having the same issue with a simple program for printing.  This is a LED Blink app with all the settings at their defaults in project creation.   The simple program is below and doesn’t output anything.  I’m using VisgualGDB 5.2R9.

int main()

{
    Serial pc2(USBTX, USBRX, 9600);

    for (;;)

    {
        g_LED = 1;
        wait_ms(500);
        pc2.printf("output\r\n");
     }

}

• This reply was modified 6 years, 10 months ago by steveh.

[support]

Hi,

Just to double-check, the serial port output of the board is connected to a USB-to-COM adapter, you are using a terminal program like SmarTTY to view the transmitted data and you can confirm that the adapter works properly with other boards, right?

[steveh]

Hi,

Sorry.  I neglected to mention that this was on a Nucleo 411RE.  This was trying to use the virtual com port built into the ST-Link.

In March or April I was able to print and have it appear in the VS Output window.  I have been able to utilize a terminal window to see the traffic.  I was hoping that the VS Output window could be used again.

Was this an intended design change?

Thanks!

• This reply was modified 6 years, 10 months ago by steveh.

[support]

Hi,

Perhaps you were using semihosting instead? Basically, VisualGDB supports 3 ways of getting output from an Embedded target:

• Normal semihosting. It works similar to setting a breakpoint inside printf() and other functions, automatically reading the printed data and resuming the program. It’s fairly slow as the program is stopped on each event, but does not require any extra configuration (as long as you are using a C library that supports it).
• Fast semihosting. It uses our own implementation of the low-level _write() function that sends printed data to VisualGDB using an in-memory buffer without stopping the target (unless an overflow occurs). This mode can be enabled by referencing the “Fast Semihosting and Profiler” framework and is the recommended way.
• Using a COM port. The target physically outputs the data to a COM port and VisualGDB connects to it and shows the data. This requires manually configuring the COM port and the speed via VisualGDB Project Properties (Embedded Terminal page) and only works on the Custom edition and higher. If you have a lower edition, you can just run the free SmarTTY tool in the background to get the same effect.

The code shown in the previous post uses the mbed API for accessing serial ports, so it will only work in the 3rd mode (with either Embedded Terminal or a separate instance of SmarTTY or any other terminal program) and requires a physical connection, a driver for the USB-to-COM interface and a correct baud rate setting.

If your setup is not working, please double-check that:

• You are actually outputting the data to the correct UART interface on the board (step into the printf() method to see which one is used and then check the board schematic to ensure this UART is connected to the ST-Link COM-to-USB interface)
• You are opening the correct COM port from VisualGDB Project Properties (check which of the COM ports disappears in Device Manager when you unplug the board).
• The baud rate in VisualGDB Project Properties is explicitly set to 9600

Hope this helps.

[steveh]

Thanks for the response.  I’m seeing the prints while in PuTTY so I’m able to verify that the 3rd option works.

[Author]

Posts