The Logging Trap

You just finished writing a precise timing loop for your latest project. To verify it works, you add a few printf statements to track its execution. Suddenly, the firmware stops working. The timing drifts, the radio disconnects, or the system crashes. You just fell into the logging trap.

This problem happens frequently for firmware developers working with the Texas Instruments CC2340 series and Nordic Semiconductor 54 L series development boards. These platforms are designed to run high-speed tasks like Bluetooth Low Energy (BLE) and sensor polling, but printf logs can ruin those functions in unpredictable ways.

In this guide, you’ll learn exactly what causes the logging trap and how to avoid it with techniques like deferred logging.

The Hidden Cost of a printf Log

printf logging is slow. When your code reaches a printf statement, your microcontroller stops its current task to push characters through the serial port via UART. At a standard baud rate of 115,200, sending a 40-character string takes about 3.5 milliseconds.

For embedded systems, 3.5 milliseconds is a long time. If your firmware needs to respond to a sensor every millisecond, this delay, also known as UART latency, becomes a significant roadblock. Your microcontroller spends a considerable amount of time waiting for the UART hardware, creating a blind spot when it can’t react to external hardware events.

On the TI CC2340R5, this delay can cause the SimpleLink Log framework to overflow its internal buffers. On the Nordic nRF54L15, slow logging can cause the timing-sensitive BLE stack to miss a connection window, leading to unexpected connection drops.

Nordic nRF54L15 Example

To see the impact of the logging trap on the Nordic nRF54L15 board, you can compare a standard printk call with the LOG_INF macro. While both methods use UART, printk has the expected UART latency, while LOG_INF does not. printk is blocking, meaning it forces your microcontroller to wait until the UART hardware sends every character to your PC before it can continue running the main task. LOG_INF is Nordic’s implementation of deferred logging, in which your microcontroller only copies the log message into a small buffer before returning to the main task instantly. Your firmware only sends the LOG_INF log to your PC when the microcontroller is idle.

To get started, in your prj.conf file, enable the Zephyr system logger in both regular and deferred mode:

CONFIG_LOG=y
CONFIG_LOG_MODE_DEFERRED=y

Add the following code to your main application file to measure the CPU cycles spent on each call. The deferred logger returns almost immediately, while the standard logger creates a massive timing gap.

#include <zephyr/kernel.h>
#include <zephyr/logging/log.h>

LOG_MODULE_REGISTER(timing_demo);

void compare_logging_impact(void)
{
    uint32_t start, end;

    // 1. Immediate Logging (Blocking)
    start = k_cycle_get_32();
    printk("This is a blocking printk call that waits for the UART hardware\n");
    end = k_cycle_get_32();
    uint32_t printk_cycles = end - start;

    // 2. Deferred Logging (Non-blocking)
    start = k_cycle_get_32();
    LOG_INF("This is a deferred log that copies data to a buffer and returns");
    end = k_cycle_get_32();
    uint32_t log_inf_cycles = end - start;

    // Print the results
    printk("\n--- Timing Results ---\n");
    printk("printk cycles: %u\n", printk_cycles);
    printk("LOG_INF cycles: %u\n", log_inf_cycles);
}

When running your firmware, you should see results like below. The printk logger delays your microcontroller for more than 3 times the number of cycles than the deferred logger.

Terminal output showing printk cycles vs LOG_INF cycles, with printk taking 3x more cycles

Better Ways to Debug Timing

If you need to verify your firmware’s timing in a better way, here are some other options you can try instead of logging.

  1. Toggle a GPIO pin. Not only is it a great way to prove your firmware is running, but it also takes only a few nanoseconds. You can see the exact timing on an oscilloscope without slowing down your microcontroller.
  2. Use a logic analyzer. A logic analyzer captures digital signals in real time, providing a much more accurate picture of your firmware execution than logging.
  3. Use Real Time Transfer (RTT). RTT is much faster than UART, which reduces the observer effect on your code.

Wrapping Up

Logging is a tool, but it doesn’t come without its costs. Every printf you add consumes CPU cycles and adds delays. Therefore, it’s important to use logs with caution when working with time-sensitive processes on your TI CC2340R5 and Nordic nRF54L15 boards.

To avoid the logging trap, use deferred logging for non-urgent messages. If you need to verify timing, switch to GPIO toggling, logic analyzers, or RTT to monitor performance without distorting your program’s behavior. With these techniques, you can make your firmware more predictable and your debugging more effective.

Ready to connect your devices anywhere on Earth? Get started with Hubble Network for free →