Issues viewing serial `printf` output on Mac

Hi there, according to the official docs Mbed OS redirects any printf() statements to the board’s debug USB serial. However, I’m unable to see any output following the minimal Hello World example. The setup:

  • Arduino Nano BLE
  • Computer: 2019 16" MacBook Pro (macOS 12.2.1)
  • Mbed OS: 6.15.1 (Mbed Studio

I’m deploying the Mbed program (.bin) using Arduino’s bossac tool. To view the output I’ve tried running mbed sterm -p <port name> as well as screen /dev/tty.usb* 9600 but the problem is that after flashing the board the USB port is no longer visible, i.e. ls /dev/tty.usb* yields nothing whereas before flashing I do see /dev/tty.usbmodem143201.

What does (partially) work is using a USBSerial instance and passing it into fprintf() calls. However, for some reason this changes the port name after flashing the board and running the program. I.e. before flashing the port is tty.usbmodem143201 and afterwards it becomes tty.usbmodem01234567891.
How can I get this resolved? Any help would be appreciated.


I do not have any experience with that hardware but the behavior seems be logical because…

  • the default STD console (printf) is set to pins P1_03 and P1_10 standart Arduino D0 and D1, I think. But these pins semms to not be connected to the same USB port what is used for upload (because there is not a bridge ofc). That is the reason why you do not see any output from printf in your terminal. With this you probably need another converter like FTDI to pins P1_03 and P1 and so on.
  • USBSerial API is not for UART but is for real USB interface. In schematic is visible the USB interface is connected to the onboard USB port. So it looks like the program switched to provide USB DEVICE, and that is probably the reason why the second option is working and why your PC identified another USB ID and first one disappeared .


I can not test it, so it is only a theory according to sources :slight_smile:

I recommend to read - Hitchhiker’s Guide to Printf in Mbed 6 - Mbed OS - Arm Mbed OS support forum

BR, Jan

Thanks a lot for the reply :+1: The first point makes total sense but I’m not sure I understand why the USBSerial/USBCDC instances would reconfigure the USB ID. I’ve started digging through the code to understand where exactly this is happening and whether there’s a way to use the existing USB interface. Should you have pointers I’d appreciate the help. As a side note, when running a minimal native nRF application to do some prints on the very same board, the USB ID stays the same.

I think the ID is changed because Mbed USBSerial API (all USB APIs) set its own IDs in constructor.

You can retarget/remapping the default console to onboard USB. You can found that in discussion of the topic what I mentioned in my previous post, you can try that.

BR, Jan

Had a look at the code and it turns out 0123456789 is the serial number, hardcoded in USBDevice.cpp. It’s possible to override it in a subclass of USBSerial/USBCDC though :+1: