Logs View

The Logs dock collects the log messages the target reports, while the debugger is connected. It is the first place to look when a command is refused, a service is missing, or a view stays empty.

By default the dock sits in the bottom dock area, tabbed with the Timeline.

What Is Shown

Entries arrive from the emulator’s logging service, so the Logs view reflects what the emulator reports, not what the GUI does internally. Messages appear as they are produced while a connection is open.

The table has five columns:

Timestamp

The time the message was produced, as reported by the target.

Category

The logging category the message belongs to.

Source

The object or subsystem that produced the message.

Severity

One of FATAL, ERROR, WARNING, INFO, TRACE, or DEBUG.

Message

The log text.

The last column stretches to fill the dock, so long messages stay readable when the dock is widened.

External user-defined models that use the temu_log*() API automatically forward their messages to the logging service and appear in this view. Output written directly to stdout or stderr bypasses the logging system and will not appear in the table.
Serial console output from the software under test appears in dedicated terminal tabs instead, see Serial Terminals.
The log level severity configured in .temu scripts or via the CLI log-level command applies emulator-side; messages filtered out by the emulator will not reach the Logs view.

Working with the Table

  • Click a column header to sort by that column, and click again to reverse the order. Timestamps sort numerically rather than as text, so the ordering follows the target’s clock.

  • Sorting is applied when you request it. New entries are appended as they arrive rather than continuously re-sorting the table underneath you, so a sorted view stays stable while you read it.

  • Selecting a row selects the whole entry, which makes it easier to follow a single message across the columns.

  • The table is read-only.

Using the Logs While Debugging

  • Filter your attention by sorting on Severity and reading the ERROR and FATAL rows first.

  • Sort on Source to isolate one device or subsystem when several models are logging at once.

  • Compare the Timestamp column with the simulated time shown in the status bar to place a message relative to the point where execution stopped.