Unlocking UDS 0x0F: Report Mirror Memory DTC in 0x19 Diagnostic Framework

Hello, vehicle diagnostics enthusiasts! In this blog post, Report Mirror Memory DTC by Status Mask (0x0F) in UDS. I will introduce you to one of the lesser-known yet powerful sub-func

tions in the UDS (Unified Diagnostic Services) protocol: Report Mirror Memory DTC by Status Mask (0x0F). This function allows you to retrieve Diagnostic Trouble Codes (DTCs) stored in the mirror memory, which remains intact even after a memory clear operation. Mirror memory acts as a backup record, helping you analyze fault history when standard DTC memory is reset. In this post, I’ll walk you through what this sub-function is, how it works, and how it differs from the regular DTC status checks. You’ll also learn when and why it’s used in real-world automotive diagnostics. Whether you’re a diagnostics engineer, ECU programmer, or a learner, this guide will sharpen your understanding of fault tracing using UDS. Let’s dive into the details!

Introduction to Report Mirror Memory DTC by Status Mask(0x0F) in UDS 0x19 Service

Welcome to another deep dive into the UDS (Unified Diagnostic Services) protocol! In this blog post, we’ll explore the Report Mirror Memory DTC by Status Mask (0x0F) sub-function under service 0x19. This powerful diagnostic feature allows clients to retrieve Diagnostic Trouble Codes (DTCs) from a special memory area called the mirror memory. Unlike standard DTC memory, mirror memory retains fault information even if the main memory is cleared. This makes it extremely useful for analyzing persistent or historical issues. We’ll cover how this sub-function works, why it’s used, and how to interpret its response. Whether you’re a diagnostics engineer, developer, or learner, this guide will enhance your understanding of UDS diagnostics.

What is Report Mirror Memory DTC by Status Mask (0x0F) in UDS 0x19 Service?

The Report Mirror Memory DTC by Status Mask (0x0F) is a sub-function in the UDS (Unified Diagnostic Services) protocol, specifically under Service 0x19. This sub-function plays a crucial role in automotive diagnostics, as it allows diagnostic tools to retrieve specific Diagnostic Trouble Codes (DTCs) from a vehicle’s DTC mirror memory based on a defined status mask. It is part of the UDS protocol used for troubleshooting issues in ECUs (Electronic Control Units) in vehicles.

How Report Mirror Memory DTC by Status Mask (0x0F) Works in UDS Protocol 0x19 Service?

Here’s a breakdown of how it works:

1. DTC Mirror Memory:
   • DTCs are typically stored in the ECU’s normal error memory, but in some situations, this memory can be erased (e.g., when a diagnostic tool clears the codes after repairs). However, there is a secondary storage area called the DTC mirror memory. This mirror memory holds a backup of the error codes that can be used if the normal memory gets cleared.
   • The DTC mirror memory cannot be erased using the ClearDiagnosticInformation (0x14) service, making it a reliable secondary memory to reference for DTCs that may have been cleared in the primary memory.
2. Status Mask:
   • The status mask defines which types of DTCs (e.g., confirmed, pending, etc.) should be reported. By using this status mask, a diagnostic tool can request only the DTCs that meet certain criteria.
   • This allows the tool to filter out irrelevant DTCs and focus on specific types (such as active or confirmed DTCs) depending on the diagnostic needs.
3. Functionality:
   • When a diagnostic client sends a request with the sub-function set to 0x0F (Report Mirror Memory DTC by Status Mask), it instructs the server (the ECU) to retrieve DTCs from the mirror memory.
   • The server then checks the status mask in the request and returns the DTCs that match the defined criteria.
4. Response:
   • If there are DTCs stored in the mirror memory that match the status mask, the server will send them back as part of the response.
   • If no matching DTCs are found, the server will simply not send any error codes back in the response. This helps to keep the communication relevant and efficient.
5. Importance in Diagnostics:
   • This function is particularly important for situations where the normal error memory has been cleared (e.g., after a reset or service), and it is crucial to retrieve the backup error codes from the mirror memory to ensure no diagnostic data is lost.
   • It is also useful in situations where the diagnostic tool needs to ensure that only active or confirmed DTCs are being analyzed, filtering out any obsolete or pending codes.
6. Example Use Case:
   • A technician may use the 0x0F sub-function to retrieve active or confirmed DTCs from the mirror memory after a diagnostic scan tool has cleared the primary error codes in the ECU. This allows the technician to ensure they still have access to relevant error codes before moving forward with repairs or analysis.

Why do we need Report Mirror Memory DTC by Status Mask (0x0F) in UDS 0x19 Service?

The Report Mirror Memory DTC by Status Mask (0x0F) sub-function in the UDS 0x19 Service serves several essential purposes in automotive diagnostics. This function enables more efficient and accurate fault detection by providing access to error codes that may otherwise be inaccessible after certain system operations. Here are the key reasons why we need this functionality:

1. Access to Backup Error Data after Memory Clears

• Issue: The primary DTC memory in the ECU can be cleared through diagnostic operations like the ClearDiagnosticInformation (0x14) service. When this happens, the stored error codes are erased, potentially losing important diagnostic information.
• Why it’s Needed: The DTC mirror memory serves as a backup for these error codes. The Report Mirror Memory DTC by Status Mask (0x0F) function ensures that even after the primary DTC memory has been cleared, diagnostic tools can retrieve critical error codes from the mirror memory. This guarantees that no valuable diagnostic data is lost during the reset or clearing process.

2. Focused Diagnostics with Status Mask Filtering

• Issue: In large and complex vehicle systems, error codes can accumulate over time, including pending, confirmed, and historical DTCs. This can make it difficult for technicians to quickly focus on the most relevant error codes, especially during troubleshooting.
• Why it’s Needed: The status mask allows a diagnostic tool to specify which types of DTCs should be reported, such as active or confirmed codes. This filtering ensures that only the most relevant DTCs are returned, reducing unnecessary noise in the data and enabling technicians to focus on critical issues.

3. Redundancy for Critical Error Information

• Issue: Some error codes may have been temporarily cleared or reset but may still be relevant for future diagnostics. This situation can occur when an error is logged but not immediately addressed, or when the diagnostic tool or ECU is reset.
• Why it’s Needed: By having a mirror memory, the system ensures that critical error information is preserved even if the primary DTC memory is cleared. This redundancy allows technicians to access the full history of confirmed faults, ensuring that all potential issues are detected and addressed.

4. Enhanced Fault Detection after ECU Resets

• Issue: In many cases, the ECU might undergo resets or memory clearing due to software updates, power cycles, or user interventions. This can result in the loss of critical fault information, especially if the error memory was cleared unintentionally or too early in the diagnostic process.
• Why it’s Needed: The mirror memory acts as an additional storage that is not erased by standard memory clearing operations. This means that technicians can still retrieve valuable diagnostic data from the mirror memory, even after an ECU reset or memory clearing. It’s essential for thorough and complete diagnostic procedures.

5. Efficient Troubleshooting

• Issue: Technicians often need to track down persistent issues that are not immediately resolved after an ECU reset. If error codes are cleared and not properly backed up, it may delay or complicate troubleshooting.
• Why it’s Needed: The ability to retrieve the mirror memory DTCs ensures that technicians can always access the most up-to-date information, even after resets. This enhances the overall efficiency of troubleshooting, as no critical error data is missed, and persistent issues can be identified more quickly.

6. Support for Complex Diagnostic Scenarios

• Issue: Some diagnostics involve analyzing complex error patterns that span across multiple diagnostic sessions. If error codes are cleared during the process, it may prevent a complete picture of the fault from being formed.
• Why it’s Needed: The mirror memory provides a non-volatile backup, which can be especially useful for complex scenarios where multiple faults have been recorded over time. It ensures that no error code is lost, allowing for a more comprehensive and accurate diagnosis.

7. Increased System Reliability

• Issue: Without a backup mechanism like the DTC mirror memory, there’s a risk of losing critical diagnostic data due to system resets or memory erasure. This could compromise the diagnostic accuracy and the repair process.
• Why it’s Needed: By storing DTCs in the mirror memory, the system provides a higher level of reliability. The mirror memory acts as a safeguard, ensuring that error codes are not lost and that the diagnostic process is more resilient and dependable.

Understanding Report Mirror Memory DTC by Status Mask (0x0F) in UDS Protocol

The 0x0F sub-function, known as ReportMirrorMemoryDTCByStatusMask, is used to retrieve Diagnostic Trouble Codes (DTCs) from a special memory area called the DTC mirror memory within the ECU. This command functions similarly to the reportDTCByStatusMask sub-function; however, the key difference lies in where the data is pulled from.

Instead of accessing the regular error memory, this request targets the mirror memory, which is an optional diagnostic storage area that serves as a backup of the standard DTC memory. This mirrored memory is designed to retain DTC information even when the normal memory is cleared such as after executing a ClearDiagnosticInformation (0x14) request.

When this service is invoked, the server checks the DTCs stored in its mirror memory against the status mask provided by the client. Only those DTCs that match the specified status will be returned. This feature is especially valuable in cases where diagnostic records need to be preserved or recovered after a memory reset. By using this sub-function, engineers and diagnostic tools gain access to fault history that might otherwise be lost, allowing for more robust and fail-safe troubleshooting processes.

Syntax of Report Mirror Memory DTC by Status Mask (SBFID-0x0F) of SID-0x19

Request Message Definition – Sub-Function = Report Mirror Memory DTC by Status Mask

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type =                             Report Mirror Memory DTC by Status Mask ]	0x0F
#3	DTC Status Mask	0x00 – 0xFF

SBFID (0x0F) Request Message Data-Parameter of SID (0x19)

DTC Status Mask:

The DTCStatusMask contains eight bits defining DTC statuses. In the request message, it allows the client to request DTC information for DTCs whose status matches the mask. A match occurs if any bit in the DTC’s status is ‘1’ and the corresponding bit in the DTCStatusMask is also ‘1’. Unsupported bits in the mask are ignored by the server.

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-function = Report Mirror Memory DTC by Status Mask

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
# 2	Report Type = [                               Report Mirror Memory DTC by Status Mask ]	0x0F
#3	DTC Status Availability Mask	0x00 – 0xFF
#4 #5 #6 #7 #8 #9 #10 #11 : #n-3 #n-2 #n-1 #n	DTC And Status Record[] = [                                           DTC High Byte#1                                                 DTC Middle Byte#1                                                 DTC Low Byte#1                                                      status Of DTC#1                                                 DTC High Byte#2                                                 DTC Middle Byte#2                                                   DTC Low Byte#2                                                      status OfDTC#2                                                                   :                                                      DTC High Byte#m                                                      DTC Middle Byte#m                                                  DTC Low Byte#m                                                      status Of DTC#m	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
C1: This parameter is only present if DTC information is available to be reported. C2: This parameter is only present if reportType = reportSupportedDTCs, reportDTCByStatusMask, reportMirrorMemoryDTCByStatusMask, reportEmissionsOBDDTCByStatusMask, reportDTCWithPermanentStatus and more than one DTC information is available to be reported.

SBFID (0x0F) Response Message Data-Parameter of SID (0x19)

reportType: This parameter reflects bits 6 – 0 of the sub-function parameter from the client’s request message.

DTCStatusAvailabilityMask: A byte where the bits are defined the same as the statusOfDTC, representing the status bits supported by the server. Bits not supported by the server will be set to ‘0’. Each supported bit (indicated by a value of ‘1’) will be implemented for every DTC supported by the server.

DTCAndStatusRecord: This parameter record includes one or more groupings of DTCHighByte, DTCMiddleByte, DTCLowByte, and statusOfDTC, based on the following formats:

Supported DTC Formats:

• ISO_14229-1_DTCFormat
• SAE_J2012-DA_DTCFormat_00
• SAE_J1939-73_DTCFormat
• SAE_J2012-DA_DTCFormat_04
• ISO_11992-4_DTCFormat

• DTCHighByte, DTCMiddleByte, DTCLowByte: Together represent a unique identification number for a specific diagnostic trouble code.
  • DTCHighByte and DTCMiddleByte: Represent the circuit/system being diagnosed.
  • DTCLowByte: Indicates the type of fault (e.g., sensor open circuit, sensor shorted to ground).

Formats Supported:

• SAE_J2012-DA_DTCFormat_04
• SAE_J2012-DA_DTCFormat_00
• ISO_14229-1_DTCFormat
• SAE_J1939-73_DTCFormat
• ISO11992-4DTCFormat

Syntax of 0x19 SID Negative Response Message

Response Message Definition – Sub-Function = Report Mirror Memory DTC by Status Mask

Data byte	Parameter Name	Byte Value
#1	Read DTC Information -Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x19
#3	Negative Response Code [ byte#1 ]	NRC

Example of Report Mirror Memory DTC by Status Mask (0x0F) in UDS 0x19 Service

Here are the Examples of Report Mirror Memory DTC by Status Mask (0x0F) in UDS 0x19 Service:

// Below example shows how to use the UDS commands over the CAN data field as per the DoCAN
// Example for Positive Response for SID-0x19
Request: Client --> Server
02 19 0F
Positive Response: Server --> Client
14 59 0F FF 12 34 56 26 AC D0 09 06 F1 90 02
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 0F Negative Response: Server --> Client
03 7F 19 13

UDS over CAN – Example for Service 0x19, Sub-function 0x0F (Report Mirror Memory DTC by Status Mask)

The UDS (Unified Diagnostic Services) protocol is widely used in automotive diagnostics, allowing diagnostic tools to communicate with the ECUs (Electronic Control Units) via the CAN network. In this example, we focus on Service ID 0x19, which is used for ReadDTCInformation, specifically sub-function 0x0F, known as Report Mirror Memory DTC by Status Mask.

Let’s break down the request and response messages step-by-step:

✅ Positive Response Example

📤 Request from Client to Server:

02 19 0F

• 02 → Number of data bytes that follow in the CAN data frame (2 bytes: 19 0F).
• 19 → Service ID (SID) for ReadDTCInformation.
• 0F → Sub-function ID for Report Mirror Memory DTC by Status Mask.

This request asks the ECU to return all DTCs in the mirror memory that match a certain status mask (by default, the status mask may be FF if not extended with an additional byte). Mirror memory is a backup of DTCs that isn’t cleared by standard memory erasing.

📥 Positive Response from Server to Client:

14 59 0F FF 12 34 56 26 AC D0 09 06 F1 90 02

Let’s decode this step-by-step:

• 14: PCI – indicating a First Frame of a longer message (20 bytes total).
• 59: Positive response code (0x19 + 0x40 = 0x59).
• 0F: Echo of the sub-function.
• FF: Snapshot Record Number (example: FF = 255 in decimal).
• 12 34 56: DTC code (hexadecimal).
• 26 AC D0 09 06 F1 90 02: Snapshot data (parameters recorded when the DTC was triggered).

The server returns a snapshot record for DTC 0x123456, captured under specific conditions. The rest of the bytes represent values for parameters like engine speed, throttle, coolant temp, etc., depending on OEM mapping.

❌ Negative Response Example

📤 Request from Client to Server:

03 19 0F

• 03 → Total data bytes following (3 bytes: 19 0F, plus possibly a status mask).
• 19 → Service ID.
• 0F → Sub-function (Report Mirror Memory DTC by Status Mask).

📥 Negative Response from Server:

03 7F 19 13

Let’s decode this:

• 03 → Total number of bytes following (3 bytes: 7F 19 13).
• 7F → Negative Response Service ID.
• 19 → Echo of the original requested service ID (ReadDTCInformation).
• 13 → Negative Response Code (NRC) → “13” means “Invalid Format”.

This means the server rejected the request because it was not formatted correctly. Possible reasons include:

• Incorrect number of bytes sent.
• Missing required parameters like the status mask.
• Unsupported sub-function or invalid combination of flags.

Summary Table:

Direction	CAN Data	Meaning
Client → Server	02 19 0F	Request to report DTCs from mirror memory
Server → Client ✅	07 59 0F FF 12 34 56 26	Positive response with one matching DTC
Client → Server	03 19 0F	Request with incorrect length or format
Server → Client ❌	03 7F 19 13	Negative response: “Invalid Format” (NRC 0x13)

Using service 0x19 with sub-function 0x0F plays an important role in retrieving DTCs that remain stored even after the main memory is cleared. This helps technicians keep track of critical faults that might otherwise go unnoticed. By accessing the mirror memory, they can review confirmed issues that were previously recorded. To get accurate results and avoid negative responses, it’s essential to include a valid status mask when sending the request.