Different Types Of NRCs (Negative Response) In UDS

Hello guys, welcome back to our blog. Here in this article, we will discuss different types of NRCs in the Unified Diagnostic Protocol and a brief explanation of each NRC.

Ask questions if you have any electrical, electronics, or computer science doubts. You can also catch me on Instagram – CS Electrical & Electronics

Also, read:

Types Of NRCs (Negative Response) In UDS

The Unified Diagnostic Services (UDS) protocol is essential in automotive diagnostics, providing a standardized framework for communication between diagnostic testers and Electronic Control Units (ECUs). One key feature of UDS is its ability to signal errors in processing requests through Negative Response Codes (NRCs). These codes identify the specific reason a diagnostic request may fail, helping technicians quickly address issues. NRCs improve efficiency by giving precise feedback on problems such as incorrect requests, unsupported services, or security access failures.

NRCs serve as a vital part of effective troubleshooting, allowing testers to navigate potential problems and streamline the repair or diagnostic process. Each code corresponds to a unique issue, making it easier to pinpoint errors and apply targeted solutions. Understanding NRCs is valuable for anyone working with automotive diagnostic systems, as they ensure smooth communication, proper protocol adherence, and enhanced diagnostic precision.

01. 0x10 – General Reject

The General Reject code is a fallback response issued by the server when it cannot process a diagnostic request, but there is no specific NRC to describe the error. This code indicates a general failure without any further information, which can be due to various unspecified reasons. It is used when the server encounters an unexpected condition or when other, more precise NRCs do not apply.

This code can be frustrating to troubleshoot, as it lacks specific details. Technicians receiving a General Reject code often have to investigate other aspects of the request and the system to identify the root cause, such as checking the message format, required conditions, or ECU status. It’s a prompt for further diagnostics to resolve the underlying issue effectively.

02. x11 – Service Not Supported

This NRC is returned when the ECU does not support the service requested by the tester, often because the service ID in the message is not recognized. It typically occurs when the tester sends a request for a feature that the ECU was not programmed to handle, such as advanced diagnostics on a simpler ECU model.

Service Not Supported can result from mismatched tester-ECU configurations, as different ECUs have different capabilities based on vehicle specifications and software versions. This response alerts the technician to double-check compatibility and ensures only appropriate requests are made.

03. 0x12 – Sub-function Not Supported

The Sub-function Not Supported code is returned when the requested sub-function within a service is unavailable. While the ECU may recognize the main service ID, it cannot process certain specific options or sub-functions within it, often due to hardware limitations or firmware configurations.

This response guides technicians to verify the sub-functions available for a specific service, ensuring they are compatible with the ECU. In practice, it helps avoid sending commands the ECU cannot execute, maintaining effective and relevant communication.

04. 0x13 – Incorrect Message Length or Invalid Format

This NRC is triggered when the diagnostic request’s message length or format does not comply with the UDS protocol standards. Requests have specific requirements for how data is structured and sized, so any deviation leads to this response.

Incorrect Message Length or Invalid Format is particularly useful in catching errors early, allowing technicians to review and correct the message structure. Ensuring properly formatted messages improves data integrity and helps avoid misunderstandings between the tester and the ECU.

05. 0x14 – Response Too Long

When the server cannot fit the response within the expected frame size or number of frames, it issues the Response Too Long NRC. This typically happens with requests that generate large amounts of data, exceeding the transmission capacity.

This code alerts technicians to either limit the data requested or use an alternative method for larger data transfers, such as segmenting the data into smaller requests. This is crucial in situations where large data retrievals could otherwise cause communication bottlenecks.

06. 0x21 – Busy – Repeat Request

This code is sent when the server is busy processing a previous request or other tasks, preventing it from handling new requests immediately. The tester is advised to wait and repeat the request after some time.

Busy – Repeat Request serves as a signal to prevent system overloads by queuing requests more efficiently. By waiting for a less busy time to resend the request, technicians can avoid unnecessary errors and interruptions in the diagnostic process.

07. 0x22 – Conditions Not Correct

One of the most commonly encountered NRCs, Conditions Not Correct is returned when the conditions necessary for a service are unmet. For example, a service might require the vehicle to be stationary, or the engine to be off, before execution.

This code ensures safety and accuracy in diagnostics by only allowing requests when appropriate conditions are met. Technicians benefit by receiving clear instructions on prerequisites, which helps prevent potential issues from non-compliant requests.

08. 0x24 – Request Sequence Error

This NRC appears if a specific request sequence is required for proper execution, and the tester sends a request out of order. Many diagnostic procedures involve multiple steps, which need to be followed in the correct sequence.

Request Sequence Error ensures that the necessary steps are not skipped, safeguarding the integrity of complex diagnostic or reprogramming procedures. By maintaining strict sequencing, this code helps achieve the desired outcomes without unintended consequences.

09. 0x31 – Request Out of Range

The Request Out of Range code is returned when the parameters in the request exceed the allowable range for the ECU. This can occur if the tester requests data beyond the ECU’s supported memory addresses or if a parameter exceeds system limits.

This code guides technicians to stay within acceptable ranges and request only what the ECU can support, preventing overloading or errors in memory handling. Adjusting parameters within valid ranges is critical for efficient and reliable diagnostics.

10. 0x33 – Security Access Denied

Security Access Denied is returned when a request requires specific security access, and that access has not been correctly unlocked. Many services, especially those involving critical system functions, require secure authentication before execution.

This code informs the tester that security measures are in place, emphasizing the need for correct credentials. It prevents unauthorized access to sensitive functions, maintaining ECU security and data integrity.

11. 0x35 – Invalid Key

When an incorrect security key is provided in response to a security challenge, the server returns the Invalid Key NRC. Security challenges require a correct response and any mismatch results in this code.

This response alerts technicians to reattempt security access with the correct key, ensuring that only authenticated access is granted to restricted services. It adds an extra layer of security against unauthorized system manipulation.

12. 0x36 – Exceed Number of Attempts

This NRC occurs when the tester exceeds the allowed number of incorrect security key attempts. Each attempt is logged, and after a certain threshold, the ECU will refuse further attempts temporarily.

Exceeding the Number of Attempts helps protect against brute-force attacks by limiting repeated attempts to unlock security. It’s an effective way to enforce security by adding consequences for excessive incorrect entries.

13. 0x37 – Required Time Delay Not Expired

This code indicates that the required time delay between consecutive requests has not been met. Many services in UDS require a waiting period before resending specific requests to prevent system overloads.

By enforcing time delays, Required Time Delay Not Expired prevents excessive request frequency, which could strain ECU resources. Technicians are reminded to allow sufficient time intervals for reliable and efficient communication.

14. 0x70 – Upload/Download Not Accepted

This NRC is returned when an ECU does not accept a data upload or download request. This can be due to unsupported transfer protocols or certain conditions that must be met for data transfer.

Upload/Download Not Accepted alerts the technician that the current operation is unsupported or restricted, ensuring that only approved data transactions take place. It’s an essential control to safeguard the integrity of ECU data.

15. 0x72 – General Programming Failure

This code signals a general failure in programming operations, often encountered during ECU firmware updates or reprogramming. Errors here can arise from incomplete programming files, power interruptions, or hardware incompatibilities.

General Programming Failure helps technicians identify issues in programming or re-flashing processes, emphasizing the need for accurate programming conditions. It safeguards the ECU from incomplete or faulty programming, ensuring system stability.

16. 0x81 – rpmTooHigh

The “rpmTooHigh” response code indicates that the engine’s RPM is above a pre-set threshold, which prevents certain diagnostic functions from executing for safety and system stability. This is commonly used when high RPM could interfere with sensitive tests or cause system overload.

By enforcing this limit, the system safeguards critical components, ensuring diagnostic operations only proceed when RPM levels are safe. This minimizes potential damage from tests that could overload or stress engine components under high RPM conditions.

17. 0x82 – rpmTooLow

The “rpmTooLow” code shows that the engine RPM is below the minimum requirement for performing the requested service. This prevents diagnostic or calibration functions that depend on a certain RPM range for accurate results.

This ensures the effectiveness of the requested operation, as functions like emissions testing or component calibration might require a stable, minimum RPM to execute properly. It also prevents erroneous data collection or inaccurate test results due to insufficient RPM.

18. 0x83 – engineIsRunning

This response code signals that the engine is running, making it unsuitable to conduct certain tests, especially actuator tests, that require the engine to be off for accurate results or safety.

This condition enforces a safer environment for testing by ensuring that only tests compatible with an active engine can proceed, reducing the risk of unintended operational disruptions or hazards from actuator tests executed during engine activity.

19. 0x84 – engineIsNotRunning

The “engineIsNotRunning” response is sent when a test requires the engine to be running, such as fuel system diagnostics that only operate correctly with active fuel flow.

This code ensures accuracy in diagnostic operations that depend on engine activity. Without the engine running, certain parameters may be inactive, and the data gathered could be incomplete or inaccurate, resulting in ineffective diagnostics.

20. 0x85 – engineRunTimeTooLow

The “engineRunTimeTooLow” response code indicates that the engine hasn’t been running long enough to achieve the stable state required for certain tests. Some diagnostics need the engine to be at operating temperature or have consistent run time for accurate readings.

This code ensures that components reach the necessary operating conditions for reliable diagnostics, preventing tests that would otherwise produce invalid data due to an inadequately prepared engine state.

21. 0x86 – temperatureTooHigh

This code indicates that the system temperature exceeds the allowable limit, making it unsafe to proceed with the requested operation. Overheating can lead to incorrect readings or hardware damage.

This response protects the system from further thermal stress, especially for tests or calibrations that could increase component temperatures. It allows the system to cool down to an acceptable range before testing continues, ensuring both safety and data integrity.

22. 0x87 – temperatureTooLow

The “temperatureTooLow” response restricts tests that require a minimum system temperature. Cold temperatures can impact sensor readings and cause inaccuracies in functions like emissions testing, which relies on a stable operating temperature.

By setting this threshold, the system ensures conditions are optimal for testing, minimizing the likelihood of inaccurate results due to insufficient warming, especially in cold-weather start-up scenarios.

23. 0x88 – vehicleSpeedTooHigh

When vehicle speed exceeds a pre-determined maximum, this response code halts certain diagnostic operations. High speed could destabilize certain components during testing or interfere with precise measurements.

This safeguard ensures diagnostics are performed only at manageable speeds to maintain system accuracy and driver safety. It’s essential for tests that involve braking or steering inputs, which could become dangerous at high speeds.

24. 0x89 – vehicleSpeedTooLow

The “vehicleSpeedTooLow” code stops tests requiring a minimum vehicle speed to ensure accurate and relevant data collection. For example, dynamic tests might need a certain speed to engage sensors properly.

This ensures the requested operation has the necessary conditions to function accurately, avoiding incomplete or inaccurate data from tests executed at an insufficient speed.

25. 0x8A – throttle/PedalTooHigh

This response code shows that the throttle or pedal position is above the pre-set maximum, preventing certain tests that require low or idle throttle conditions.

By maintaining control over the throttle position, this response prevents unintentional stress on components and ensures test accuracy. It’s particularly relevant for idle-state diagnostics or throttle sensitivity tests that demand low pedal engagement.

26. 0x8B – throttle/PedalTooLow

The “throttle/PedalTooLow” response prevents tests that rely on a minimum throttle or pedal position for accurate measurements, ensuring the test environment reflects realistic operational conditions.

This check is important in diagnostics requiring partial throttle engagement, such as fuel efficiency tests, ensuring measurements align with expected real-world conditions.

27. 0x8C – transmissionRangeNotInNeutral

This response code restricts tests that require the transmission to be in neutral. Some diagnostic operations depend on a disengaged drive train to avoid load on the transmission.

This ensures safety and accuracy in tests conducted with no vehicle propulsion, reducing risks in operations that shouldn’t be carried out with an active gear engagement.

28. 0x8D – transmissionRangeNotInGear

The “transmissionRangeNotInGear” code is used when a test or function requires the vehicle to be in gear, such as certain load-bearing diagnostics.

By enforcing this requirement, the system ensures that relevant tests can only proceed under appropriate gearing conditions, ensuring test consistency and operational relevance for specific diagnostics.

29. 0x8F – brakeSwitch(es)NotClosed

This response code ensures that the brake pedal is engaged for safety-critical diagnostics, as some tests require the vehicle to be stationary with brakes applied.

By enforcing brake engagement, the system minimizes safety risks associated with unintended vehicle movement, crucial for tests that engage drivetrain components or involve actuator calibration.

30. 0x90 – shifterLeverNotInPark

The “shifterLeverNotInPark” code stops diagnostics requiring the vehicle to be stationary in a safe position. For some tests, it’s critical to prevent accidental movement by enforcing the Park position.

This condition enhances safety, especially in systems that could accidentally engage propulsion, by ensuring the vehicle remains immobile during testing.

31. 0x91 – torqueConverterClutchLocked

This code indicates that the torque converter clutch is locked, which can interfere with certain diagnostics that depend on a free-rotating transmission state.

By preventing tests under this condition, the system ensures diagnostics that require torque converter freedom can run accurately without drivetrain constraints, especially in transmission analysis.

32. 0x92 – voltageTooHigh

The “voltageTooHigh” response protects the ECU and other components from damage when voltage exceeds safe limits, halting operations that could worsen the over-voltage condition.

This response ensures system protection and voltage stability, preventing overload or component failure by enforcing a voltage range appropriate for diagnostics and regular operation.

33. 0x93 – voltageTooLow

This code indicates that the voltage is below the minimum threshold, which may lead to incomplete tests or inaccurate results, especially for functions reliant on stable power.

By enforcing a minimum voltage requirement, the system ensures data integrity and test completion, as insufficient power could lead to test interruptions or unreliable measurements.

In the UDS protocol, condition-specific response codes are vital for maintaining the integrity, safety, and accuracy of diagnostic operations in automotive systems. Each code serves a unique purpose, signaling whether specific operating conditions—like RPM levels, temperature, vehicle speed, or throttle positions—meet the required thresholds to ensure valid test results and prevent potential risks or equipment damage.

These codes safeguard both vehicle and operator by enforcing parameters that limit diagnostic functions to safe and controlled conditions. By adhering to these parameters, the system effectively manages diagnostic processes, ensuring they only proceed under optimal conditions, enhancing the reliability of diagnostics, and protecting sensitive components. These codes underscore the importance of context-aware diagnostics, where environmental and operational states are taken into account to deliver precise, reliable, and secure automotive maintenance and troubleshooting.

This was about “Different Types Of NRCs (Negative Response) In UDS“. Thank you for reading.

Also, read:

About The Author

Chetan Shidling

Automotive | Technical Blogger | Engineer | Content Creator

See author's posts

Share Now