Logging

The application MCU and the modem produce separate logs with their own methods. Logs often refer to the Serial Modem application logging while the modem logs are referred to as modem traces in many places.

Application logging

Serial Modem outputs B0, MCUboot, and application logs over UART1 (VCOM1 on the nRF9151 DK) during boot. After the application is initialized, the log backend is disabled, and the UART is suspended. Use AT#XLOG=1 to enable application logs and resume the UART. This avoids UART power overhead when logs are not needed during normal operation. See Trace AT commands for the full command reference.

Note

The negative error codes that are visible in logs are errno codes defined in nrf_errno.h.

The default logging level for the Serial Modem is CONFIG_SM_LOG_LEVEL_INF. You can get more verbose logs by setting the CONFIG_SM_LOG_LEVEL_DBG Kconfig option.

TF-M logging must use the same UART as the application. For more details, see shared TF-M logging.

Enabling RTT logs

RTT logging is disabled by default. To switch from UART1 back to SEGGER RTT, add the following to your prj.conf:

# Disable UART logging
CONFIG_UART_CONSOLE=n
CONFIG_LOG_BACKEND_UART=n

# Enable Segger RTT
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
# Optional: increase the buffer so that boot logs are not lost before RTT Viewer connects.
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=2048

You can view the RTT logs with an RTT client such as J-Link RTT Viewer. See Testing and optimization for instructions.

Note

nRF9151 anomaly 36 locks the debug port when the application reaches a low power state (<3 uA current consumption). This takes place when DTR is deasserted and the RTT client, such as J-Link RTT Viewer, is not connected. Since the RTT backend relies on the debug port, the RTT client must be connected before the application enters a low power state to avoid this issue.

Note

Modem traces captured through UART are corrupted if application logs through RTT are simultaneously captured. When capturing modem traces through UART with the Cellular Monitor app and simultaneously capturing RTT logs, for example, with J-Link RTT Viewer, the modem trace misses packets, and captured packets might have incorrect information.

If you need to capture modem traces and RTT logs at the same time, enable HW flow control for modem trace UART. Otherwise, you can choose not to capture RTT logs. Having only RTT logs enabled does not cause this issue.

Shared UART log and trace backend

The Serial Modem application routes Zephyr application logs to UART1 (VCOM1 on the nRF9151 DK) by default. The baud rate of the shared UART is set to 1000000 to support the high data rate required for modem traces.

Configuration

Application log output over UART1 is included in the default build.

To also enable the modem trace backend (AT#XTRACE), build with the Kconfig overlay:

west build -p -b nrf9151dk/nrf9151/ns -- -DEXTRA_CONF_FILE="overlay-trace-backend-uart.conf"

After the application is initialized, the UART is suspended. Use AT#XLOG=1 to activate application logs and AT#XTRACE=1 to activate modem traces. See Trace AT commands for the full command reference.

Note

Attempting to enable one backend while the other is active returns ERROR. Always disable the active backend before enabling the other.

Note

When measuring power consumption, make sure both backends are disabled (AT#XLOG=0 and AT#XTRACE=0) so the UART stays suspended. An active trace or log backend adds approximately 700 uA overhead.

Collecting traces

To collect modem traces using the shared UART backend:

  1. Connect the Cellular Monitor app to UART1 (VCOM1 on the nRF9151 DK) at 1000000 baud rate.

  2. Enable modem trace collection:

    AT#XTRACE=1
    OK
    
  3. Activate the modem to start generating trace data:

    AT+CFUN=1
    OK
    
  4. Wait for the modem to register on the network and collect the traces in the Cellular Monitor app.

  5. When done, disable the modem trace backend:

    AT#XTRACE=0
    OK
    

You can analyze the captured trace file in the Cellular Monitor app to inspect AT commands, network events, and IP-level details. If the modem crashes and the crash dump collection was enabled, you can send the trace file to Nordic Semiconductor support for further analysis.

Modem traces through CMUX

The Serial Modem application supports collecting modem traces through the CMUX multiplexer. When enabled, modem traces are sent through a dedicated CMUX channel, allowing simultaneous AT commands, PPP data, and trace collection over the same serial port. The trace CMUX channel is the first channel after the AT command channel and the PPP channel.

Configuration

To use the CMUX trace backend, build the Serial Modem application with the trace backend configuration overlay in addition to the PPP and CMUX overlays:

west build -p -b nrf9151dk/nrf9151/ns -- -DEXTRA_CONF_FILE="overlay-ppp.conf;overlay-cmux.conf;overlay-trace-backend-cmux.conf"

For optimal throughput and to minimize trace data loss, configure the UART to run at maximum speed:

  1. Set the UART speed in your devicetree configuration (for example, 1000000 baud).

  2. Use the -b parameter with the script to match this speed (for example, -b 1000000).

Note

Some trace data will be dropped. The amount depends on the UART speed, ongoing modem operations, and the trace level set with AT%XMODEMTRACE.

Setting trace level

Configure the modem trace level using the AT%XMODEMTRACE command.

The modem trace subsystem automatically sends the AT%XMODEMTRACE=1,2 command at startup. This provides the most trace data and includes the crash dump collection. Depending on the drop rate you observe, you might need to select a different <set_id> to reduce the amount of trace data generated.

Collecting traces through CMUX on Linux

The sm_start_ppp.sh script for Linux host includes support for collecting modem traces. Use the -T flag to enable trace collection. Traces are saved to the /var/log/nrf91-modem-trace.bin file. The trace collection starts after the CMUX channel is established and continues until you stop the connection with the sm_stop_ppp.sh script.

The stop script automatically terminates trace collection and preserves the trace file for later analysis.

# Start PPP connection with trace collection with baud rate matching the devicetree setting
$ sudo scripts/sm_start_ppp.sh -b 1000000 -T
Trace file: /var/log/nrf91-modem-trace.bin
Connect and wait for PPP link...
PPP link started

# Check that the trace is being collected
$ ls -la /var/log/nrf91-modem-trace.bin
-rw-r--r-- 1 root root 3467306 Jan 16 12:13 /var/log/nrf91-modem-trace.bin

# Stop PPP connection (also stops trace collection)
$ sudo scripts/sm_stop_ppp.sh
Stopping PPP link...
Waiting for Shutdown script to complete...
Stopping trace collection...

You can open the /var/log/nrf91-modem-trace.bin file using the Cellular Monitor app for analysis. This allows you to see the AT commands, network, and IP-level details of the communication between the modem and the cellular network.

If the modem crashes and the crash dump collection was enabled, you can send the trace file to Nordic Semiconductor support for further analysis.