SoftwareDiagnostics Cluster

Cluster ID: 0x0034  |  Endpoint: Endpoint 0 (Root / Node level)  |  Role: Server (read-only + one reset command)

SoftwareDiagnostics exposes the runtime health status of device firmware — including thread stack usage, heap memory allocation, and software fault records. This is a diagnostics cluster in Matter designed for developers and operations personnel, helping understand the internal state of embedded devices without connecting a debugger.

When to Use

Device behaving abnormally after running for a while? Read heap memory attributes to check for memory leaks. Suspect a thread stack overflow? Check StackFreeMinimum in ThreadMetrics. Want to confirm firmware stability after an OTA upgrade? Monitor SoftwareFault events and watermark changes. This information is especially useful for remote diagnostics after mass production.

Feature Bitmap

The SoftwareDiagnostics Cluster declares optional device capabilities through FeatureMap (0xFFFC):

Bit 0
WTRMRK(Watermarks) Watermark tracking — supports CurrentHeapHighWatermark attribute and ResetWatermarks command, recording historical peak heap memory usage
Feature Meaning

FeatureMap = 0x01 (WTRMRK): Device tracks heap memory usage peaks, resettable via the ResetWatermarks command.
FeatureMap = 0x00 (no Feature): Only provides real-time heap memory and thread metrics, no historical peak records.

Attributes

All attributes are read-only. Heap memory attributes are optional, and ThreadMetrics is also optional. Click an attribute ID to jump to its detailed description.

ID Name Type Condition Description
0x00 ThreadMetrics list<ThreadMetricsStruct> Optional List of currently running threads and their stack usage
0x01 CurrentHeapFree uint64 Optional Current free heap bytes
0x02 CurrentHeapUsed uint64 Optional Current used heap bytes
0x03 CurrentHeapHighWatermark uint64 WTRMRK Historical peak heap usage (high watermark)

ThreadMetrics (Thread Metrics List)

Returns stack usage information for all currently running threads on the device. Each entry is a ThreadMetricsStruct containing thread ID, name, and stack usage statistics. This is a key data source for troubleshooting stack overflows.

ThreadMetricsStruct Structure

ID Field Type Required Description
0x00 Id uint64 Yes Unique thread identifier
0x01 Name string (max 8 characters) Optional Thread name (e.g., "Main", "BLE", "WiFi")
0x02 StackFreeCurrent uint32 Optional Current free stack bytes
0x03 StackFreeMinimum uint32 Optional Historical minimum of free stack bytes (stack usage watermark)
0x04 StackSize uint32 Optional Total thread stack size (bytes)
Stack Overflow Assessment

When StackFreeMinimum approaches 0, it means the thread has nearly exhausted its stack space, indicating a stack overflow risk. It is generally recommended to maintain a safety margin of StackFreeMinimum / StackSize > 10%. If below this threshold, consider increasing the thread's stack allocation or optimizing its call depth.

CurrentHeapFree (Free Heap Bytes)

Number of bytes currently available for allocation in the device heap. On resource-constrained embedded devices (e.g., ESP32 series), a continuously decreasing value may indicate a memory leak.

CurrentHeapUsed (Used Heap Bytes)

Number of bytes currently allocated in the device heap. Complementary to CurrentHeapFree — their sum approximates the total heap size (with possible differences due to fragmentation and management overhead).

CurrentHeapHighWatermark (Heap Usage High Watermark)

The maximum value CurrentHeapUsed has reached since the last ResetWatermarks command or device startup. This attribute requires WTRMRK Feature support.

The high watermark is an important indicator for assessing device memory headroom — it reflects "how much memory was used in the worst case," not a snapshot at a single moment. Even if the current CurrentHeapUsed looks normal, the watermark may reveal intermittent memory spikes.

Commands

SoftwareDiagnostics has only one command, requiring WTRMRK Feature support.

ID Name Condition Description
0x00 ResetWatermarks WTRMRK Reset heap usage high watermark and thread stack minimum free values

ResetWatermarks — Reset Watermarks (0x00)

Resets CurrentHeapHighWatermark to the current CurrentHeapUsed value, and simultaneously resets all threads' StackFreeMinimum to their current StackFreeCurrent values. This command does not accept any parameters.

When to Use

Typical usage: Send a ResetWatermarks after an OTA upgrade, then observe the high watermark after the new firmware runs for a period, to assess whether the new version has memory usage regression. Also useful for investigating memory impact of specific operations — reset, perform the operation, then read the watermark.

Request example:

{
  "invokeRequests": [{
    "commandPath": {
      "endpointId": 0,
      "clusterId": "0x0034",
      "commandId": "0x00"       // ResetWatermarks
    },
    "commandFields": {}         // No parameters
  }]
}

Events

When a software fault is detected during device operation, a SoftwareFault event is reported. This event is optionally supported.

ID Name Priority Description
0x00 SoftwareFault Info Triggered when a software fault is detected

SoftwareFault — Software Fault Event (0x00)

This event is reported when device firmware detects a software anomaly (such as unhandled exceptions, assertion failures, watchdog triggers, etc.). The event data carries fault thread information and optional fault scene records.

FieldIDTypeDescription
Id 0x00 uint64 Thread ID when the fault occurred
Name 0x01 string (max 8 characters) Fault thread name (optional)
FaultRecording 0x02 octstr (max 1024 bytes) Fault scene data, format defined by manufacturer (optional)
Purpose of FaultRecording

FaultRecording is a vendor-defined binary data blob that may contain register snapshots, call stack traces, crash addresses, and other debug information. The format varies by chip platform and requires the vendor's decoding tools. The app typically only needs to upload the raw data to the cloud for backend service parsing.

Event report example:

{
  "eventReports": [{
    "eventData": {
      "path": {
        "endpointId": 0,
        "clusterId": "0x0034",
        "eventId": "0x00"       // SoftwareFault
      },
      "eventNumber": 7,
      "priority": "INFO",
      "data": {
        "0": 42,                // Id = 42 (fault thread ID)
        "1": "BLE",             // Name = "BLE" (fault thread name)
        "2": "RkVUQ0g6IDB4..."  // FaultRecording (Base64-encoded fault scene data)
      }
    }
  }]
}

Example Data

Reading a SoftwareDiagnostics Cluster's attributes from an ESP32 device:

{
  // --- Attributes ---
  "0x0": [                       // ThreadMetrics (thread metrics list)
    {
      "0": 1,                    // Id = 1
      "1": "Main",               // Name = "Main"
      "2": 2048,                 // StackFreeCurrent = 2048 bytes
      "3": 1024,                 // StackFreeMinimum = 1024 bytes
      "4": 8192                  // StackSize = 8192 bytes
    },
    {
      "0": 2,                    // Id = 2
      "1": "BLE",                // Name = "BLE"
      "2": 4096,                 // StackFreeCurrent = 4096 bytes
      "3": 2048,                 // StackFreeMinimum = 2048 bytes
      "4": 8192                  // StackSize = 8192 bytes
    }
  ],
  "0x1": 65536,                  // CurrentHeapFree = 64 KB
  "0x2": 131072,                 // CurrentHeapUsed = 128 KB
  "0x3": 196608                  // CurrentHeapHighWatermark = 192 KB (requires WTRMRK Feature)
}

Common Scenarios

Scenario 1: Memory Leak Monitoring

Device becomes sluggish and behaves abnormally after long-running operation, suspected memory leak.

  1. Periodically read CurrentHeapFree and CurrentHeapUsed (e.g., hourly)
  2. Record to a time-series database or logs, plot memory trend graphs
  3. If CurrentHeapFree continuously decreases without recovering, a memory leak can be confirmed
  4. Combine with ThreadMetrics to investigate abnormal stack usage in specific threads
  5. After fixing via OTA, reset watermarks to observe the new version's performance
Scenario 2: Thread Stack Health Check

Device occasionally crashes and reboots, suspected insufficient thread stack space causing overflow.

  1. Read the ThreadMetrics list, focusing on each thread's StackFreeMinimum
  2. Calculate stack utilization: (StackSize - StackFreeMinimum) / StackSize
  3. Threads with utilization above 90% are at risk of stack overflow and need attention
  4. Compare the gap between StackFreeCurrent and StackFreeMinimum — a larger gap indicates more volatile stack usage
  5. Adjust the corresponding thread's stack allocation in firmware, then verify again after OTA
Scenario 3: Post-OTA Watermark Comparison

After firmware upgrade, need to assess whether the new version's memory performance has regressed. Requires WTRMRK Feature support.

  1. After OTA completion, device reboots and watermarks are automatically reset
  2. Let the device run normally for a period (recommended 24-48 hours, covering various usage scenarios)
  3. Read CurrentHeapHighWatermark and compare with the old version's records
  4. If the new version's watermark is significantly higher than the old version, the new code has introduced additional memory overhead
  5. You can also manually send ResetWatermarks, perform a specific operation, and precisely measure that operation's peak memory usage