UDS Protocol 0x19 Service: Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) Explained

Hello, fellow automotive diagnostics enthusiasts! In this blog post, Report Mirror Memory DTC Ext Data Record ByDTC Number 0x10. I’ll introduce you to an important concept in t

he UDS protocol: Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) under Service 0x19. This sub-function allows retrieval of extended diagnostic data specifically from the mirror memory section, offering valuable snapshots of past system conditions linked to DTCs. Such mirror memory data is crucial for analyzing intermittent or historical faults more accurately. I’ll walk you through what this service does, how to format the request and interpret the response, and why mirror memory is so important in diagnostics. By the end of this post, you’ll have a solid understanding of using 0x10 to access in-depth fault records. Let’s get started!

Introduction to Report Mirror Memory DTC Extended Data Record by DTC Number (0x10): 0x19 Service in UDS Protocol

Welcome back, automotive diagnostics enthusiasts! In this article, we’ll take a closer look at the Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) service in the UDS protocol. This special service lets technicians access preserved fault data from the ECU’s mirror memory even after the DTC has been cleared. It plays a crucial role in investigating intermittent or past faults that may no longer be active. We’ll cover how the request and response messages are structured, and why mirror memory is so important for deep diagnostics. Whether you’re troubleshooting vehicles or designing diagnostic software, understanding 0x10 will give you an edge. Let’s get started and uncover the details!

What is Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) in 0x19 Service of the UDS Protocol?

The Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) is a sub-function of the 0x19 Service in the UDS Protocol. It is used to retrieve extended diagnostic data related to a specific Diagnostic Trouble Code (DTC) from the ECU’s mirror memory. Mirror memory typically stores a snapshot or backup of important diagnostic information, allowing technicians to access fault data even after events like power loss. This service is especially useful for analyzing faults that occurred in the past and helps in identifying the root causes more accurately. By using this sub-function, users can request specific extended data linked to a DTC, making diagnostics more thorough and reliable.

Why do we need Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) in 0x19 Service of the UDS Protocol?

The Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) in 0x19 Service of the UDS Protocol is essential for several reasons:

1. Access to Historical Diagnostic Data

Mirror memory plays a crucial role in storing diagnostic data even after a vehicle’s power is turned off or the ECU is reset. This data can include fault codes and other critical information that would otherwise be lost. When a fault occurs, the information is written to the memory, which is then accessible for later retrieval. This allows service technicians to analyze faults that happened before the most recent engine cycle, providing a more comprehensive view of vehicle issues. Having this historical data helps identify persistent or intermittent faults that would be difficult to diagnose otherwise.

2. Enhanced Fault Diagnosis

By retrieving extended data for specific Diagnostic Trouble Codes (DTCs), this UDS service offers valuable additional information beyond the basic fault code. For instance, it may include sensor readings, operational conditions, or timing data that were relevant at the time the fault occurred. This extra layer of data helps service technicians understand not just the “what” of a fault, but also the “how” and “why,” offering deeper insights into the vehicle’s behavior. This capability is crucial for accurately diagnosing problems that require more than just a generic fault code.

3. Backup for Data Integrity

One of the most important advantages of mirror memory is its ability to store data even during a power loss or reset. Without mirror memory, any diagnostic data would be erased once the vehicle’s power is cycled off or after an ECU reset. The mirror memory acts as a backup to preserve this vital information, ensuring that diagnostic data remains intact. This is especially important for vehicles experiencing sporadic faults that might only occur under specific conditions, as the mirror memory ensures that this data isn’t lost due to power interruptions.

4. Improved System Monitoring

The use of mirror memory extends the diagnostic capabilities of the UDS protocol, allowing for enhanced system monitoring. The stored data, especially the extended data from DTCs, enables a more complete analysis of how different components of the vehicle are functioning over time. Service technicians can use this data to observe patterns in the vehicle’s performance, identify long-term issues, or uncover hidden problems that aren’t immediately apparent during a single diagnostic session. This continuous monitoring capability helps catch issues early, often preventing more severe damage or costly repairs in the future.

5. Regulatory Compliance and Performance Standards

For automotive manufacturers and service providers, compliance with industry regulations and performance standards is essential. Detailed diagnostic reporting from services like the Report Mirror Memory DTC Extended Data Record ensures that all faults, both current and historical, are properly logged and made accessible for review. This can be particularly important for meeting regulatory requirements in various markets, where accurate fault reporting is a key part of the vehicle’s warranty or service history. By using this service, manufacturers can provide transparent, traceable diagnostic data that meets the standards set by regulatory bodies, enhancing both reliability and accountability.

6. Facilitates Remote Diagnostics and Maintenance

The ability to access mirror memory data remotely provides an invaluable tool for vehicle manufacturers and service centers. This capability can allow for off-site diagnostics, meaning that technicians can analyze the vehicle’s extended data without physically connecting to the vehicle. This remote diagnostic process helps reduce downtime, as technicians can quickly evaluate fault data and make decisions on whether the vehicle needs to be brought in for more detailed repairs. Additionally, it streamlines the process of fleet maintenance, where remote monitoring of multiple vehicles is possible, ensuring proactive maintenance and reducing the occurrence of unexpected failures.

7. Enhanced User Experience and Vehicle Reliability

For vehicle owners, the ability to access extended fault data stored in mirror memory contributes to a better overall user experience. By having a comprehensive understanding of their vehicle’s performance over time, owners can make more informed decisions about maintenance and repairs, ultimately leading to longer vehicle life and better reliability. Furthermore, when a vehicle has a service history that includes detailed diagnostic reports, the owner can be assured that the car is being maintained at a high standard, increasing trust and satisfaction in the vehicle’s performance. This helps in building long-term customer relationships and maintaining the reputation of the manufacturer or service provider.

Report Mirror Memory DTC Ext Data Record By DTC Number (0x10)

The reportMirrorMemoryDTCExtDataRecordByDTCNumber sub-function is handled the same way as reportDTCExtDataRecordByDTCNumber, but retrieves data from the DTC mirror memory. This mirror memory is an optional, non-erasable error storage that mirrors the normal DTC memory and is used if the primary memory is erased. The mirror memory cannot be cleared by the ClearDiagnosticInformation (0x14) service.

Syntax of Report Mirror Memory DTC Ext Data Record By DTC Number (SBFID-0x10) of SID-0x19

Request Message Definition – Sub-Function = Report Mirror Memory DTC Ext Data Record By DTC Number

Data byte	Parameter Name	Byte Value
#1	Read DTC Information Request SID	0x19
#2	sub-function = [ report Type = Report Mirror Memory DTC Ext Data Record By DTC Number ]	0x10
#3 #4 #5	DTC Mask Record[] = [                                        DTC High Byte                                        DTC Middle Byte                                        DTC Low Byte ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#6	DTC Ext Data Record Number	0x00 – 0xFF

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

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

DTCMaskRecord [DTCHighByte, DTCMiddleByte, DTCLowByte]

DTCMaskRecord is a 3-byte value representing a unique diagnostic trouble code (DTC) using DTCHighByte, DTCMiddleByte, and DTCLowByte. The DTC can be decoded in various ways:

• ISO 15031-6: Identified by DTCFormatIdentifier = SAE_J2012-DA_DTCFormat_00
• ISO 14229: Identified by DTCFormatIdentifier = ISO_14229-1_DTCFormat (manufacturer-defined)
• SAE J1939-73: Identified by DTCFormatIdentifier = SAE_J1939-73_DTCFormat
• ISO 11992-4: Identified by DTCFormatIdentifier = ISO_11992-4_DTCFormat
• ISO 27145-2: Identified by DTCFormatIdentifier = SAE_J2012-DA_WWH-OBD_DTCFormat

DTCExtDataRecordNumber

DTCExtDataRecordNumber is a 1-byte value indicating the specific DTCExtendedData record requested for a DTCMaskRecord via the reportDTCExtDataRecordByDTCNumber or reportDTCExtDataRecordByRecordNumber sub-function. For emissions-related servers (OBD-compliant ECUs), 0x00 is reserved for future OBD use.

• The DTCExtDataRecordNumber ranges are reserved as follows:
  • 0x00: Reserved by ISO/SAE.
  • 0x01 – 0x8F: Requests manufacturer-specific DTCExtendedData records.
  • 0x90 – 0xEF: Requests legislated OBD DTCExtendedData records.
  • 0xF0 – 0xFD: Reserved by ISO/SAE for future group reporting.
  • 0xFE: Requests all legislated OBD DTCExtendedData records in a single response.
  • 0xFF: Requests all stored DTCExtendedData records in a single response.

Syntax of 0x19 SID Positive Response Message

Response Message Definition – Sub-Function = Report Mirror Memory DTC Ext Data Record By DTC Number

Data byte	Parameter Name	Byte Value
#1	Read DTC Information +Ve Response SID	0x59
#2	Report Type = [      report Mirror Memory DTC Ext Data Record By DTC Number ]	0x10
#3 #4 #5 #6	DTC And Status Record[] = [                                                                                           DTC High Byte                                                       DTC Middle Byte                                                       DTC Low Byte                                                       Status Of DTC ]	0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF 0x00 – 0xFF
#7	DTC Ext Data Record Number#1	0x00 – 0xFD
#8 : #18+(p-1)	DTC Ext Data Record[]#1 = [                                                     extended Data#1 byte#1                                                                    :                                                     extendedData#1 byte#p ]	0x00 – 0xFF : 0x00 – 0xFF
:	:	:
#t	DTC Ext Data Record Number#x	0x00 – 0xFD
#t+1 : #t+1+(q-1)	DTC Ext Data Record[]#x = [                                                    extended Data#x byte#1                                                                          :                                                    extended Data#x byte#q ]	0x00 – 0xFF : 0x00 – 0xFF
 Here’s a concise version in English: C1: DTC Ext Data Record Number and the extended Data in the DTC Ext Data Record parameter are included if there’s at least one DTC Ext Data Record available for reporting. C2: DTC Ext Data Record Number and the extended Data in the DTC Ext Data Record parameter are included only when all records are requested (DTC Ext Data Record Number set to 0xFE or 0xFF), and more than one record is available for reporting.

SBFID (0x10) 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.

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). Definitions found in ISO 15031-6 [12].

Formats Supported:

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

DTCExtDataRecordNumber: This parameter is either the echo of the DTCExtDataRecordNumber specified by the client in the reportDTCExtDataRecordByDTCNumber or reportDTCExtDataRecordByRecordNumber request, or the actual DTCExtDataRecordNumber of a stored DTCExtendedData record.

DTCExtDataRecord: The DTCExtDataRecord is a server-specific block of information that may include extended status details related to a DTC. It contains DTC parameter values identified at the time of the request.

Syntax of 0x19 SID Negative Response Message

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 Extended Data Record by DTC Number (0x10) in 0x19 Service of the UDS Protocol

Here are the Examples of Report Mirror Memory DTC Extended Data Record by DTC Number (0x10) in 0x19 Service of the UDS Protocol:

// 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 10
Positive Response: Server --> Client
14 59 10 00 01 02 A1 A2 B0 BB 47 90 14 12 CC
// Example for Negative Response for SID-0x19
Request: Client --> Server
03 19 10
Negative Response: Server --> Client
03 7F 19 13

Understanding UDS Protocol Commands for Report Mirror Memory DTC Extended Data Record by DTC Number (0x10)

In UDS (Unified Diagnostic Services), communication between a client (tester/tool) and a server (ECU) happens over a network like CAN, following specific structures. Let’s break down the example commands you’ve provided for Service 0x19, Sub-function 0x10 – Report Mirror Memory DTC Extended Data Record by DTC Number.

Positive Response Example:

Request: Client → Server

02 19 10

• 02 → Number of bytes in the message (excluding PCI byte if applicable).
• 19 → Service Identifier (SID) for “ReadDTCInformation”.
• 10 → Sub-function Identifier (0x10) for “Report Mirror Memory DTC Extended Data Record by DTC Number”.

The client is requesting the ECU to provide the mirror memory extended data records for a specific DTC.

Positive Response: Server → Client

14 59 10 00 01 02 A1 A2 B0 BB 47 90 14 12 CC

• 14: Total number of bytes (indicates a multi-byte response)
• 59: Positive response SID for 0x19 (0x40 + 0x19 = 0x59)
• 10: Echoes the sub-function 0x10
• 00 01 02: DTC Status Availability Mask or number of DTCs
• A1 A2 B0: First DTC code (3 bytes)
• BB: Status byte for the DTC
• 47 90 14: Additional DTC info (depends on implementation)
• 12 CC: May include snapshot or extended data depending on configuration

The server returns one or more DTCs that match the requested status mask, along with relevant status and data.

What it means:

The server successfully accepted the request and confirms that the extended data record from the mirror memory will be provided or has been accessed.

Negative Response Example:

Request: Client → Server

03 19 10

• 03 → Number of bytes in the request.
• 19 → Service Identifier (SID) for “ReadDTCInformation”.
• 10 → Sub-function Identifier (0x10) for “Report Mirror Memory DTC Extended Data Record by DTC Number”.

Here, the client is again requesting the mirror memory extended data, but something might be wrong with the request (e.g., incorrect formatting or unsupported request).

Negative Response: Server → Client

03 7F 19 13

• 03 → Number of bytes in the response.
• 7F → Negative Response Service Identifier.
• 19 → Original Service ID (0x19) that caused the error.
• 13 → NRC (Negative Response Code) = 0x13, which means “Incorrect Message Length or Invalid Format”.

What it means:

The server rejected the request because the message format was wrong, or the length of the request did not match what is expected for this sub-function.

Summary:

Request Type	Client Message	Server Response	Meaning
Positive Response	02 19 10	02 59 10	Request accepted and processed successfully.
Negative Response	03 19 10	03 7F 19 13	Request rejected due to incorrect length/format.