Runtime Map

A map of what your firmware actually did: every task, interrupt and instrumented object that appears in the recording is a node, and every recorded interaction between two of them (a queue send, a semaphore take, a mutex acquire, a notification) is a link. Traffic animates along the links as the cursor moves, failures are marked where they happened, and pending queue items sit on the object as dots.

The map only draws what was recorded. Nothing is inferred from source code, and a missing link means no recorded operation, not proof that the code path cannot run.

Reading the map

• Node colour says what kind of thing it is: blue for tasks and interrupts, green for queues and buffers, purple for synchronization objects, user traces and other instrumentation, grey for activity with no known task context.
• Links carry one colour per operation kind. A moving dot on a link is a recorded event near the cursor; dot travel is illustrative, the event time is measured.
• Red crosses mark failed operations and timeouts at the affected object; an amber ring marks mutex contention. Both cues last 600 ms around the event.
• Stacked dots with a count beside a queue or notification are its pending items at the cursor (the backpressure display).
• The status strip at the bottom counts nodes, links and operations in the mapped range, unknown-context activity and capture integrity markers.

The map follows the shared cursor: scrub the Timeline and the traffic, pending counts and inspector all move to that moment. Shift-sweep the Timeline to limit the map to a selected interval.

Layouts

Choose a layout from the gear menu in the panel header. Every layout shows the same nodes and links; only the arrangement changes.

Levels in Centered and Hierarchy are connection distance, not ownership or call order; arrows keep the recorded direction.

Linear: follow a few objects

Click object names in the Objects list (or type in the search box) to add them as roots. The roots stay in the left column; every object with a recorded connection to them lines up on the right, with in and out counts for the mapped range. Clear roots starts over.

Heat

Turn on Traffic heat in the gear menu to colour every link by how much traffic it carried. Colour is relative and logarithmic: blue is cold, red is the busiest path in the range.

Group by heat rearranges the rings so the busiest objects gather on one side of each band, with a coloured arc behind them. It is the fastest way to see where the work actually goes.

The heat bar along the bottom of the map controls what is shown:

• The range slider keeps only paths inside a heat band. Drag the left handle up to hide the quiet traffic and keep the hot paths.
• Reset returns to the full range.
• Group by heat is the same toggle as in the gear menu.
• The caption says what the heat covers (whole recording or selected time), the peak count, the time range, and whether trace gaps fall inside it.

Shift-sweep a range on the Timeline and the heat covers only that interval. Comparing a quiet window with a busy one is the quickest way to see which paths a burst actually used.

Heat totals do not depend on the playback cursor. A cold path means no observations in the interval, not proof that the firmware did no work; partial history and trace gaps are labelled.

Selecting and inspecting

Click a node to select it. The inspector on the right switches to that object: its kind, observation count and state at the cursor.

The inspector has four tabs:

Expand an event in the Activity list to pin it on the map; the event is outlined where it happened.

Filters

Issues only (the chip at the top left) keeps failures, timeouts and contention across every object and hides the rest of the traffic. It pauses your saved object rules while it is on.

For one object, add it on the Filters tab and pick a mode:

• Isolate hides all other traffic. Several Isolate rules combine.
• Highlight emphasizes the matches and keeps everything else visible.
• Off keeps the rule saved without applying it.

Tags narrow a rule to Failed, Contended, Waiting or Other activity. Contended means the mutex was held when requested; Waiting means an observed blocked wait. Neither alone means the operation failed. Filters change this view only, never the capture or an export.

Table

Table in the panel header shows the same data as rows: one per object (or per task and interrupt), with peers, operations, contended count, failed or timed-out count and the last activity. Expand a row for its connections. Sort by any column; search filters by name or kind.

Gear menu

Export map writes the current map as a .vamap file for sharing or for later comparison.

Replay

With a recording open, the capsule in the top bar shows REPLAY beside REC. Click it and the capsule turns into the replay controls:

Replay moves the shared cursor, so every cursor-linked view follows: the map, the Timeline, the charts and (with follow on) the Event Table. With a Timeline selection, replay stays inside it. Replay keeps running when the map is closed.