Getting Your First printf Logs: Configuring Baud Rates and COM Ports

When you power up a new development board for the first time, nothing is more reassuring than seeing your firmware print a log message. A simple printf() confirms that your toolchain works, your microcontroller boots correctly, and your code actually runs.

In this guide, you’ll configure UART settings, match baud rates, select the correct COM port, and capture your first logs on the Texas Instruments CC2340 series and Nordic Semiconductor 54 L series development boards.

Let’s get your firmware talking.

Understanding What You’re Configuring

Before you begin changing the UART settings on your development board, it helps to understand what you’re doing. UART communication requires both sides — your microcontroller and your PC terminal — to use the same settings:

Baud rate (commonly 115200)
8 data bits
No parity
1 stop bit
No flow control

If you mismatch the baud rate, your terminal will display garbage characters or nothing at all.

When you plug in your board, your computer creates a virtual COM port (Windows) or /dev/ttyACM* (macOS/Linux). You’ll connect your terminal to that port using the same UART settings you configure in the firmware.

Note: You need a serial terminal to properly read UART data. Examples of serial terminal applications include PuTTY (Windows), Tera Term (Windows), screen (macOS/Linux), and minicom (Linux).

Configuring UART on the TI CC2340R5

You can easily configure UART on the CC2340R5 LaunchPad using its SimpleLink SDK and TI’s Code Composer Studio IDE.

Step 1: Configure UART in SysConfig

Add a UART2 instance in your project’s SysConfig
Assign the TX Pin to your board’s UART transmit pin

Step 2: Add UART2_write()

Add the following code to your main application file to initialize UART:

#include <ti/drivers/UART2.h> // Include the TI UART2 driver library definitions

UART2_Handle uart;            // Create a handle to reference the UART instance later
UART2_Params uartParams;      // Create a structure to hold the configuration settings

int main(void)
{
    // Initialize the parameters structure with default hardware values
    UART2_Params_init(&uartParams); 
    
    // Explicitly set the communication speed to 115,200 bits per second
    uartParams.baudRate = 115200;   
    
    // Set the data payload size to 8 bits (standard for ASCII text)
    uartParams.dataLength = UART2_DataLen_8; 
    
    // Disable parity checking (no extra bit for error detection)
    uartParams.parityType = UART2_Parity_NONE; 
    
    // Use 1 stop bit to signal the end of a character frame
    uartParams.stopBits = UART2_StopBits_1; 

    // Open index 0 of the UART hardware using the defined parameters
    uart = UART2_open(0, &uartParams); 

    // Send the string buffer over the UART line; 20 is the specific byte count
    size_t bytesWritten;
    UART2_write(uart, "Hello from CC2340R5!\r\n", 20, &bytesWritten); 
    
    // Enter an infinite loop to prevent the program from exiting/resetting
    while (1); 
}

Step 3: See Terminal Output

Build and flash your firmware onto the board. In your serial terminal, select the board’s virtual COM port and set the speed to 115200. You should immediately see:

Terminal showing Hello from CC2340R5 output

If you don’t, verify:

Your terminal is connected to the correct COM port
Your terminal baud rate matches the firmware
Proper pin configuration for your board’s UART interface

Configuring UART on the Nordic nRF54L15

You can easily configure the Nordic nRF54L15 board with the nRF Connect SDK built on Zephyr OS. You have a few ways to set up UART on this board, but using the UART console is by far the easiest.

Step 1: Enable UART Console

Add the following to your prj.conf:

CONFIG_UART_CONSOLE=y      # Route the serial console output to the UART hardware
CONFIG_CONSOLE=y           # Enable the generic console subsystem in Zephyr
CONFIG_LOG=y               # Enable the logging module for structured debugging
CONFIG_LOG_BACKEND_UART=y  # Direct the log module to use UART as the output transport

Step 2: Add printk()

Add the following code to your main application file:

#include <zephyr/sys/printk.h> // Include the header for kernel-level formatted printing

void main(void)
{
    // Print a string to the console (automatically formatted for UART via prj.conf)
    printk("nRF54L15 UART logging started!\n");

    // Loop forever to keep the device powered and logging
    while (1) {
        // Put the thread to sleep for 1000ms (1 second) to save power/prevent flooding
        k_msleep(1000);
    }
}

Step 3: See Terminal Output

Build and flash your firmware onto the board. In your serial terminal, select the board’s virtual COM port and set the speed to 115200. You should immediately see:

Terminal showing nRF54L15 UART logging started output

If you don’t, verify:

Your terminal is connected to the correct COM port
Your terminal baud rate matches the firmware

Common Issues

You See Nothing

Verify the terminal baud rate matches the firmware
Check that your firmware actually opened the UART
(TI only) Confirm SysConfig assigned the UART pins
(Nordic only) Confirm CONFIG_UART_CONSOLE=y is in your prj.conf
Verify the board enumerated correctly
Try unplugging and reconnecting the USB cable

Output Looks Like Garbage Data

Terminal showing garbled characters from baud rate mismatch

Verify the terminal baud rate matches the firmware
Confirm terminal settings use 8 data bits, no parity, and 1 stop bit
Disable hardware flow control

Learning More

For further reading and examples, check out the following resources:

TI SimpleLink Log Examples: Explains how to set up the SimpleLink Log framework and host tools for viewing UART output on TI boards
Nordic Logging in nRF Connect SDK: Explains how the logger subsystem and UART backend works on Nordic boards
Hubble Community Guides: General embedded software fundamentals and best practices

Wrapping Up

When you configure UART correctly and capture your first printf log, you establish:

Firmware execution confirmation
A real-time debugging channel
A foundation for deeper diagnostics

Before you dive deeper into firmware development and debugging, always make sure you can print a simple message. That one line of output proves your development pipeline works end to end.

Once your logs flow reliably, you can move on to implementing BLE stacks, sensor drivers, or RTOS tasks with the peace of mind that your code works and can talk back to you.

Hubble Network’s satellites receive BLE signals from standard chipsets across entire continents—range solved at the infrastructure level. See how it works →