UDS Request Upload (0x35) Service Explained: Format, Use Cases, and Implementation Guide

Hello, automotive diagnostics enthusiasts! In this blog post, I’ll introduce you to UDS Request Upload (0x35) Service – one of the important services in the UDS protocol

– the Request Upload (0x35) service. This service plays a crucial role when retrieving data from a control unit’s memory, especially during ECU diagnostics and reprogramming. It allows a client to request the uploading of memory content from a specific address, making it a vital tool for engineers and developers. Understanding this service helps in designing secure and efficient diagnostic workflows. In this post, we’ll break down the message format, real-world use cases, and typical implementation steps. You’ll also learn when and why to use this service in practice. By the end, you’ll be confident in using 0x35 as part of your UDS toolkit – let’s get started!

Introduction to Request Upload (0x35) Service in UDS Protocol

The Request Upload (0x35) service in the Unified Diagnostic Services (UDS) protocol is designed to allow a diagnostic tester to retrieve data from a control unit’s memory. This service is particularly useful in scenarios where memory data such as firmware or calibration values needs to be extracted for analysis, backup, or verification purposes. By specifying the address and length of the data to be read, the tester can initiate a structured upload process that complies with memory access and security conditions defined by the ECU. Request Upload serves as a foundational service for reverse engineering, validation, and ECU development workflows. Understanding its format, constraints, and proper usage is essential for implementing effective diagnostic communication strategies in automotive systems.

What is Request Upload (0x35) Service in UDS Protocol?

The Request Upload (0x35) service in the UDS (Unified Diagnostic Services) protocol is used to initiate the transfer of data from a control unit’s memory to an external diagnostic tester. This service allows the tester (client) to specify the memory address and size of the data it wants to upload, without actually transferring the data in this step. Instead, the 0x35 service sets up the parameters for the data upload, which is then carried out using the Transfer Data (0x36) service.

It is typically used in applications like retrieving firmware, calibration data, or ECU memory content for analysis or backup purposes. The service ensures that memory access is structured, controlled, and secure often requiring appropriate security levels to be unlocked beforehand.

Note: This service does not use a sub-function

Why do we need Request Upload (0x35) Service in UDS Protocol?

Here are the key reasons why we need the Request Upload (0x35) Service in the UDS Protocol, explained clearly and concisely:

1. Data Extraction from ECU

The Request Upload (0x35) service is essential for extracting data from an ECU’s memory. It allows diagnostic tools to retrieve specific memory contents, such as firmware, calibration, or configuration data, which is important for troubleshooting or software updates. This service initiates the memory read operation by specifying the address and data size to be uploaded. Without this functionality, accessing and transferring data for diagnostic purposes would be far more complex and disorganized.

2. Backup of Calibration and Firmware Data

One of the main uses of the Request Upload service is to backup calibration and firmware data stored in an ECU. Before making any changes, such as updates or reprogramming the ECU, it’s crucial to have a copy of its current state. This service allows diagnostic equipment to access and save this important data, minimizing the risk of data loss during operations. This step is essential for restoring the ECU’s original settings if needed, ensuring minimal downtime in critical applications.

3. Analysis and Debugging

Request Upload enables engineers to analyze and debug ECU memory contents. By retrieving specific data, such as error codes, firmware versions, or configuration settings, they can diagnose issues more accurately. This service is key during the development phase when testing software on ECUs or when diagnosing and debugging issues in existing vehicles. By enabling easy access to memory content, it speeds up troubleshooting and enhances the efficiency of the debugging process.

4. Supports Modular Data Transfer

Rather than transferring large volumes of data in a single step, the Request Upload service sets up the groundwork for transferring data incrementally. This modular approach allows for better control and reliability during data transfer, reducing the chances of errors or system overload. Once the request is made, the Transfer Data (0x36) service can be used to upload data in manageable chunks. This structured process optimizes the transfer of large files, especially when dealing with large firmware images or calibration tables.

5. Enables Read Access Control

The Request Upload service plays a vital role in ensuring secure access to sensitive ECU memory areas. By utilizing UDS security mechanisms, this service restricts access to specific memory regions based on security levels and authorization credentials. Only authorized users or diagnostic tools with the correct security access can initiate the data upload process, helping protect sensitive vehicle or system data from unauthorized access. This ensures that critical memory content, such as proprietary firmware, is protected from tampering or theft.

6. Supports Firmware and Software Updates

The Request Upload (0x35) service is instrumental when performing firmware or software updates on ECUs. Before an update, the diagnostic tool needs to retrieve the current firmware or software version from the ECU’s memory. This ensures that any updates are done properly and allows the system to revert to the previous version if the update fails. By extracting the data before modifying it, engineers can safeguard against issues during the update process, ensuring a smooth and safe upgrade.

7. Facilitates Reverse Engineering and Validation

The Request Upload service is valuable for reverse engineering and validating the functionality of ECU systems. Researchers and engineers can use this service to analyze the internal workings of an ECU by extracting critical memory content. This allows them to inspect software versions, configuration settings, and other key parameters to ensure compliance with standards, verify performance, and identify potential vulnerabilities. It is particularly useful in industries where ECU security and performance need to be thoroughly tested and validated.

Syntax of 0x35 SID Request Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Request Upload Request SID	0x74
#2	Data Format Identifier	0x00 – 0xFF
#3	Address And Length Format Identifier	0x00 – 0xFF
#4 : #(m-1)+4	Memory Address[] = [                                        byte#1 (MSB)                                                 :                                        byte#m ]	0x00 – 0xFF : 0x00 – 0xFF
#n-(k-1) : #n	Memory Size[] = [                                   byte#1 (MSB)                                            :                                   byte#k ]	0x00 – 0xFF : 0x00 – 0xFF
C1: The inclusion of this parameter is determined by the address length information parameter of the address And Length Format Identifier. C2: Whether this parameter is present or not depends on the memory size length information of the address And Length Format Identifier.

Request Message Data-Parameter

dataFormatIdentifier

• This one-byte data-parameter encodes two methods:
  • High nibble: Specifies the compressionMethod.
  • Low nibble: Specifies the encryptingMethod.

A value of 0x00 means neither method is used. Other values are manufacturer-specific.

addressAndLengthFormatIdentifier

• This one-byte parameter has:
  • Bits 7-4: Length (in bytes) of the memorySize parameter.
  • Bits 3-0: Length (in bytes) of the memoryAddress parameter.

memoryAddress

The memoryAddress parameter specifies the start address in server memory from which data is retrieved. The number of bytes for this address is defined by the low nibble of the addressAndLengthFormatIdentifier. The least significant byte is always included, with more significant bytes potentially used as a memory identifier, especially in cases like dual-processor systems or memory with overlap. Usage details are defined by the vehicle manufacturer or system supplier.

memorySize

This parameter helps the server verify the total amount of data transferred during the TransferData service against the memory size. The size in bytes is defined by the high nibble of the addressAndLengthFormatIdentifier. For compressed data, whether the size is for compressed or uncompressed data is vehicle manufacturer specific.

Syntax of 0x35 SID Positive Response Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Request Upload +Ve Response SID	0x75
#2	Length Format Identifier	0x00 – 0xF0
#3 : #n	Max Number Of Block Length = [                                                           byte#1 (MSB)                                                                :                                                           byte#m ]	0x00 – 0xFF : 0x00 – 0xFF

Response Message Data-Parameter

lengthFormatIdentifier

• This one-byte parameter has nibbles encoded as follows:
  • Bits 7 – 4: Length (in bytes) of the maxNumberOfBlockLength parameter.
  • Bits 3 – 0: Reserved and set to 0x0.

It follows the format of the addressAndLengthFormatIdentifier from the request message, with the lower nibble set to 0x0.

maxNumberOfBlockLength

This parameter informs the client of the maximum data bytes to include in each TransferData positive response from the server. It reflects the total message length, including the service identifier and data parameters. This helps the client adjust to the server’s send buffer size. The client must accept responses of the specified length, though the server may send shorter responses. The last response in a block may be less than maxNumberOfBlockLength.

Syntax of 0x35 SID Negative Response Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Request Upload –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x35
#3	Negative Response Code = [ byte#1 ]	NRC

Supported Negative Response Codes (NRCs) of 0x35 SID in UDS Protocol

NRC	Parameter Name	Description
0x13	Incorrect Message Length Or Invalid Format	This Negative Response Code (NRC) shall be sent if the length of the message is incorrect.
0x22	Conditions Not Correct	This NRC is returned if the request Upload criteria are not met, such as when a server receives a request while a previous request Upload is still ongoing.
0x31	Request Out Of Range	This NRC is returned if: • The specified data Format Identifier is invalid. • The specified address And Length Format Identifier is invalid. • The specified memory Address or memory Size is invalid.
0x33	Security Access Denied	This NRC is returned if the server is secure (for servers that support the Security Access service) and a request for this service is received.
0x70	Upload Download Not Accepted	This NRC indicates that uploading to a server’s memory cannot be completed due to fault conditions.

Example of Request Upload (0x35) Service in UDS Protocol

Here are the Examples of Request Upload (0x35) Service in UDS Protocol:

Example of Request Upload (0x35) SID Request and Positive Response Frame Format

Request Frame Format:

PCI Length	SID	Data Format Identifier	Address & Length Format Identifier	Memory Address field			Memory size field
07	35	11	33	60	20	10	FF

Positive Response Frame Format:

PCI Length	Response SID	Length format Identifier	Max number of block Length
03	75	20	00	81

Example of Request Upload (0x35) SID Request and Negative Response Frame Format

Request Frame Format:

PCI Length	SID	Data Format Identifier	Address & Length Format Identifier	Memory Address field			Memory size field
07	34	11	30	FF	00	00	FF

Negative Response Frame Format:

PCI Length	Response SID	Request SID	NRC
03	7F	35	13

Advantages of Request Upload (0x35) Service in UDS Protocol

These are the Advantages of Request Upload (0x35) Service in UDS Protocol:

1. Efficient Memory Access: Request Upload enables precise and efficient access to specific ECU memory locations. Instead of reading the entire memory, technicians can retrieve only the required data blocks, saving time and reducing system load. This is especially useful during diagnostics or calibration checks. It helps streamline the memory read process and makes it more manageable, especially when dealing with high-memory ECUs. By optimizing memory access, it ensures faster operations and minimal processing overhead. This leads to better performance of diagnostic tools and reduces ECU communication traffic. In automotive workshops, such efficiency improves workflow and reduces turnaround time.
2. Supports Modular Transfer: The service works in combination with Transfer Data (0x36), allowing for data to be uploaded in segments rather than all at once. This segmented or modular transfer ensures reliability, especially for large memory blocks. It minimizes the risk of data corruption during transmission and makes it easier to identify errors if they occur. Uploading in chunks also enables retry mechanisms for failed segments. This design is especially beneficial when network bandwidth or ECU response times are limited. It promotes smoother communication between the tester and ECU. Overall, modular transfer enhances both stability and performance.
3. Useful for Backup Creation: Request Upload is a valuable tool for creating backups of important ECU data, including firmware, calibration parameters, and configuration settings. Before performing updates or modifications, technicians can safely store the current memory content. This acts as a recovery point in case of failures during the flashing or reprogramming process. It is crucial in safety-critical systems where configuration integrity is vital. Having a reliable backup prevents irreversible damage or data loss. This service, therefore, supports best practices in ECU management and helps maintain operational continuity.
4. Enhances Debugging Process: During ECU development or troubleshooting, engineers often need to analyze memory contents to understand system behavior. The Request Upload service enables easy access to these memory areas, making debugging faster and more effective. It allows examination of variable values, buffer contents, and error logs directly from the ECU. This direct memory insight is critical for pinpointing issues in complex systems. Developers can monitor runtime behavior without intrusive methods. The result is a quicker diagnostic loop and faster issue resolution. It plays a vital role in embedded systems development and maintenance.
5. Strengthens Diagnostic Capabilities: This service enhances the depth and precision of diagnostic operations. It provides access to internal ECU memory, which often stores valuable data like error states, system counters, and software flags. By reading this data, diagnostic tools can provide more accurate insights into the vehicle’s condition. Technicians can verify software versions, compare configuration parameters, and even audit memory contents. This improves diagnostic confidence and reduces reliance on guesswork. The ability to read memory also supports predictive maintenance and smarter decision-making. Overall, it upgrades the diagnostic experience to a professional level.
6. Ensures Secure Data Handling: Request Upload respects UDS security mechanisms, which restrict access based on session levels and security keys. Only authorized tools or users can access critical memory regions, ensuring sensitive ECU data is protected. This is essential for cybersecurity in modern vehicles where ECUs control critical functions. The service avoids unauthorized tampering or reading of intellectual property like firmware. Compliance with security protocols keeps vehicle systems safe from malicious access. It also aligns with automotive standards like ISO 26262 and AUTOSAR. Secure handling builds trust in diagnostic operations and tool usage.
7. Improves Flashing Workflow: Before writing new firmware to an ECU, it’s important to verify the existing software version and configuration. Request Upload enables this by allowing testers to read and confirm current memory contents. It ensures compatibility and prevents accidental overwrites of critical data. By reading first, flashing tools can log or validate the memory structure. This results in safer and more accurate firmware updates. It also supports rollback mechanisms by storing the original firmware before flashing. Such workflow enhancements are vital in large-scale or remote ECU update scenarios.
8. Facilitates Validation and Testing: Testing teams rely on memory access to validate software behavior, confirm calibration settings, or run conformance tests. Request Upload supports these tasks by providing easy access to runtime memory areas. It allows testers to capture snapshots of ECU state during test cycles. These snapshots can then be analyzed to check for standard compliance or performance metrics. It’s especially useful in test automation setups where large memory datasets need to be reviewed. The service supports both functional and non-functional testing efforts. It plays a key role in delivering high-quality automotive software.
9. Saves Development Time: Developers benefit greatly from the ability to access ECU memory directly. Instead of building custom logging tools, they can use standard UDS-based tools to retrieve memory content. This reduces development overhead and accelerates testing. It enables quick verification of variables, memory tables, and configuration registers. Faster feedback loops mean faster bug resolution and more productive debugging sessions. It also allows memory comparison across ECU builds or development stages. By using Request Upload, engineering teams can streamline their workflow and focus more on feature development than infrastructure setup.
10. Provides Flexibility Across ECUs: UDS is a standardized protocol, so the Request Upload service behaves consistently across various ECUs and OEM platforms. This means tools developed for one ECU can be adapted easily to others with minimal changes. It reduces tool development costs and improves scalability. Diagnostic teams can apply the same service logic to multiple projects or models. This flexibility makes it easier to maintain uniformity in testing, validation, and support. It’s a great asset for companies managing multiple vehicle platforms or outsourced engineering projects.

Disadvantages of Request Upload (0x35) Service in UDS Protocol

These are the Disadvantages of Request Upload (0x35) Service in UDS Protocol:

1. Limited by Access Permissions: Request Upload is bound by session-level and security access rights, which can restrict its use in certain ECUs. If the correct security key isn’t provided or the ECU is not in the proper diagnostic session, the request is denied. This makes it difficult for unauthorized or low-level tools to use the service, which can slow down diagnosis or testing. It also increases dependency on OEM-specific knowledge or tools. Without proper access, even essential diagnostic operations may be blocked, reducing overall flexibility. While this enhances security, it limits universal accessibility for developers or testers.
2. Risk of Misuse and Data Exposure: Since this service can read sensitive data directly from ECU memory, there’s a risk that malicious actors could misuse it. Improper use might expose proprietary calibration data, firmware logic, or system identifiers. If memory access is not carefully controlled, it could lead to data leaks or reverse engineering. This poses a cybersecurity concern in connected vehicle environments. The service must be tightly integrated with security layers to prevent misuse. For developers, balancing usability with protection becomes a significant challenge.
3. Can Increase Network Traffic: Large memory reads through Request Upload can generate substantial communication traffic on the vehicle’s CAN or Ethernet bus. This may cause delays or interfere with other real-time communication on the network. In high-demand diagnostic scenarios, it can reduce network performance. Improper segmentation or unoptimized read lengths can further worsen traffic congestion. This is especially problematic in multi-ECU systems where bandwidth is shared. To prevent issues, engineers must carefully manage the timing and volume of data uploads.
4. Not Suitable for Real-Time Systems: Request Upload is not typically optimized for high-speed or real-time systems where response timing is critical. Reading large memory blocks can take time and affect system responsiveness. In safety-critical applications, even small delays may lead to performance degradation or timeouts. Real-time systems may require custom diagnostic approaches that avoid prolonged memory reads. Therefore, reliance on this service in such environments must be carefully evaluated. It limits its application in certain vehicle domains like ADAS or powertrain control.
5. Limited Support Across Tools: Not all diagnostic tools or third-party software support the Request Upload service out-of-the-box. Some may require configuration or scripting to use this service correctly. This limits its ease of use in plug-and-play diagnostic scenarios. If the tool doesn’t support memory segmentation properly, it may lead to upload failures or data corruption. It also increases the learning curve for new users. Consistency in tool support is crucial for seamless diagnostics, and lack of it creates fragmentation in workflows.
6. Complexity in Data Interpretation: The data retrieved using Request Upload is often in raw binary or hexadecimal form, requiring additional processing or decoding. This can be challenging for technicians who are not familiar with ECU memory maps or calibration structures. Without proper tools or documentation, the uploaded data may appear meaningless. This creates a barrier for efficient diagnosis and can slow down workflows. It requires experienced personnel or sophisticated software to make sense of the results. For beginners, interpreting raw memory is often a daunting task.
7. Dependence on Memory Map Accuracy: Successful use of the Request Upload service depends on precise knowledge of the ECU’s memory layout. Any mismatch in memory addresses, block lengths, or segmentation logic can result in incorrect or failed data retrieval. Errors in memory map interpretation can lead to reading uninitialized areas or protected zones. This can cause system instability or misleading results. Engineers must be extra cautious and well-informed to avoid mistakes. Keeping memory maps updated across software versions also becomes a recurring challenge.
8. Time-Consuming for Large Data: Even though modular transfer helps, reading large data blocks still takes time, especially over slower communication protocols like CAN. Uploading large calibration files or firmware snapshots can take minutes, affecting workshop efficiency. In production lines or during OTA (over-the-air) operations, time is a critical factor. Longer read times also increase the chance of communication errors or retries. This makes the service less suitable for high-speed applications unless optimized with faster transport protocols.
9. May Require Custom Implementation: Some ECUs implement the 0x35 service in OEM-specific ways, meaning developers must write custom scripts or adjust standard tools. This limits reusability of existing workflows and increases development effort. Diagnostic applications might need tuning based on OEM memory structures, address formats, and data types. These variations make it difficult to maintain a one-size-fits-all solution. For organizations managing multiple OEM platforms, it introduces complexity and maintenance overhead.
10. Potential for Misdiagnosis: If misused or misunderstood, the service can lead to misinterpretation of memory data, causing wrong diagnostic conclusions. For example, reading from an outdated or irrelevant memory region might show incorrect calibration settings or invalid software status. Technicians might waste time troubleshooting non-existent issues. Such errors can impact customer satisfaction and increase operational costs. Ensuring correct use of memory addresses and validation of uploaded data is critical to avoid this.

Future Development and Enhancement of Request Upload (0x35) Service in UDS Protocol

Following are the Future Development and Enhancement of Request Upload (0x35) Service in UDS Protocol:

1. Integration with Cybersecurity Standards: Future versions of the Request Upload service will likely be more closely integrated with modern automotive cybersecurity standards like ISO/SAE 21434. Enhanced authentication and encrypted memory reads can reduce the risk of unauthorized access, making the service safer for use in connected and autonomous vehicles.
2. Support for Faster Transport Protocols: To overcome delays associated with large data uploads, upcoming improvements may include native support for high-speed transport protocols such as DoIP (Diagnostics over IP) or CAN FD. This would allow faster data transmission and better performance during diagnostics or firmware retrieval.
3. Dynamic Memory Map Access: Future enhancements could allow ECUs to dynamically share memory map details through diagnostic sessions. This would help technicians and tools access valid memory regions more easily, reducing guesswork and the risk of accessing invalid or protected areas.
4. Smart Data Interpretation Support: Upcoming diagnostic tools may include built-in decoders for commonly accessed memory structures, providing more meaningful and human-readable data from memory dumps. This could drastically improve usability for technicians who don’t specialize in low-level binary data interpretation.
5. Automated Segmentation and Retry Logic: Future diagnostic stacks might handle memory segmentation and retry mechanisms automatically, without requiring manual script adjustments. This would enhance reliability in low-quality communication environments and reduce development time.
6. Remote Diagnostic Support: As remote diagnostics become more common, the 0x35 service may be enhanced to work securely over the internet using cloud-integrated ECUs and OEM platforms. This would allow remote upload of memory for diagnostics, reducing the need for physical workshop visits.
7. Improved Error Handling and Feedback: Enhancements may include more detailed negative response codes and diagnostic feedback in case of failure. This would help engineers identify exactly why a memory upload failed whether due to permissions, memory issues, or segmentation errors streamlining the debugging process.
8. Role-Based Access Management: Instead of a flat security model, future implementations might introduce role-based access levels where different users (e.g., OEMs, dealers, testers) get different upload permissions. This fine-grained access control would enhance both flexibility and security.
9. Integration with Digital Twins: As digital twin technology evolves, Request Upload could be used to pull live memory states into simulation platforms for real-time analysis. This would enable more advanced ECU testing and diagnostics without needing to replicate hardware faults manually.
10. Standardized OEM Extensions: Many OEMs implement custom variants of the 0x35 service. In the future, there may be a push toward standardizing these extensions across the industry. This would make tools more interoperable and reduce the need for OEM-specific adaptations, benefiting the entire diagnostics ecosystem.