Knowledge Base
Last Updated: 2026-07-30
How to Diagnose UDS NRC 0x31 Request Out Of Range
NRC 0x31 usually means the ECU received a service request whose parameters or preconditions did not fit the allowed range.
Evidence Summary
Interpret the retained observation before assigning a diagnostic conclusion.
Observed
Concrete NRC 0x31 reject with nearby session and security transitions
Supported interpretation
Only the retained, approved observation is supported.
Not established
Not determined by NRC 0x31 alone; session, security, payload structure, and ECU-state preconditions remain candidates to verify.
Recommended next check
Bind the first 0x7F / 0x31 response to the immediately preceding request and re-check session/security preconditions before touching payload structure.
Visual Evidence
These panels are reviewed, public-safe, role-based event summaries. They are not raw packet captures or screenshots.
Wireshark Evidence Window: RequestDownload Reject
Generated from the redacted sample for EVID-NRC31-PAS-DOWNLOAD-01.
Evidence reference: EVID-NRC31-PAS-DOWNLOAD-01
Derived from: original frame window 1099-1132
Normalized by: DiagAgent
Original packet count: 1,424
Wireshark Evidence Window: Direct Routine Reject
Generated from the redacted sample for EVID-NRC31-ROUTINE-ADC-01.
Evidence reference: EVID-NRC31-ROUTINE-ADC-01
Derived from: original frame window 95-111
Normalized by: DiagAgent
Original packet count: 130
Wireshark Evidence Window: Vehicle Data Chain
Generated from the redacted sample for EVID-NRC31-VEHICLE-DATA-01.
Evidence reference: EVID-NRC31-VEHICLE-DATA-01
Derived from: original frame window 2774-2794
Normalized by: DiagAgent
Original packet count: sample window extracted from a larger vehicle-data chain
Analyzer Summary Screenshot
Generated from the redacted teaching windows used by the NRC 31 page.
Evidence reference: EVID-NRC31-PAS-DOWNLOAD-01 + EVID-NRC31-ROUTINE-ADC-01 + EVID-NRC31-VEHICLE-DATA-01
Derived from: EVID-NRC31-PAS-DOWNLOAD-01 + EVID-NRC31-ROUTINE-ADC-01 + EVID-NRC31-VEHICLE-DATA-01
Normalized by: DiagAgent
Original packet count: 1,424 + 130 + larger vehicle-data chain
Timeline
Read this as a role-based swimlane: it shows observed request/response order, not an unproven causal chain.
Observed: Concrete NRC 0x31 reject with nearby session and security transitions
Not established: Not determined by NRC 0x31 alone; session, security, payload structure, and ECU-state preconditions remain candidates to verify.
Next check: Bind the first 0x7F / 0x31 response to the immediately preceding request and re-check session/security preconditions before touching payload structure.
Tester
Gateway / ECU
Evidence boundary
Setup and security requests run first
Nearby NRC 0x78 states appear
Rejected request enters the final window
NRC 0x31 terminates the branch
Priority FAQ
What does UDS NRC 0x31 mean?
It means the ECU rejected the request because the parameter set, sub-function, data identifier, or precondition fell outside the accepted range.
When This Article Applies
Best when coding or calibration fails but the diagnostic tool hides the exact rejected payload.
Capture-Backed Evidence
Each example identifies whether it is a controlled simulator observation or a redacted field-evidence window. The evidence record bounds what the sequence can and cannot establish.
PAS flashing capture with a concrete 0x34 -> 0x31 reject
PAS flashing case with RequestDownload rejected by NRC 0x31
Evidence reference: EVID-NRC31-PAS-DOWNLOAD-01
Node roles in this case
- tester: the flashing client
- target ECU: the ECU that rejects RequestDownload
A DoIP capture where the request chain narrows to a single RequestDownload rejection instead of a vague workshop symptom.
Evidence signals
- ISO 13400-2 v2 transport is confirmed across 1,424 packets.
- A single target ECU returns SID 0x34 / NRC 0x31 at +416.131 s.
- The same target ECU shows NRC 0x78 on SID 0x27 and SID 0x2E immediately before the 0x31 reject, which makes session and security preconditions important candidates to check.
Timeline
- +349.739 s: the target ECU emits SID 0x19 / NRC 0x78.
- +415.073 s: the same target ECU emits SID 0x27 / NRC 0x78 during the security-related phase.
- +416.031 s: the same target ECU emits SID 0x2E / NRC 0x78, then +416.131 s rejects SID 0x34 with NRC 0x31.
This is the kind of capture that lets the KB explain that NRC 31 is rarely useful in isolation. The preceding request chain is the actual evidence.
A compact routine-control style request is rejected directly with NRC 0x31
ADC extraction case with direct SID 0x31 rejection
Evidence reference: EVID-NRC31-ROUTINE-ADC-01
Node roles in this case
- tester: the diagnostic client
- target ECU: the ECU that rejects the routine-style request
A short v2 DoIP capture where the useful teaching value comes from how little ambiguity is left in the final rejection window.
Evidence signals
- The capture is only 130 packets long and isolates one actionable anomaly category.
- The tester issues SID 0x31 at +9.567 s and the target ECU returns SID 0x7F / NRC 0x31 at +9.578 s.
- Unlike the larger flashing case, this example shows that NRC 31 can also appear in a compact routine-style exchange with almost no surrounding noise.
Timeline
- +9.429 s to +9.455 s: final keep-alive traffic clears and the session remains open.
- +9.567 s: the tester sends SID 0x31 to the target ECU.
- +9.578 s: the target ECU rejects that request with NRC 0x31.
This gives the KB a second NRC 31 pattern: not a long precondition chain, but a short direct reject that is easier for readers to recognize in the wild.
Packet Evidence
These packet-level checkpoints are the smallest proof units behind the article narrative.
Frame window A
target ECU -> tester
SID 0x27 and SID 0x2E nearby pending states appear before the final reject.
This makes a precondition-chain review appropriate; it does not identify which precondition failed.
Frame +416.131 s
target ECU -> tester
SID 0x34 is rejected with NRC 0x31.
This is the decisive terminal response in the larger flashing case.
Frame +9.578 s
target ECU -> tester
A compact routine-style request is directly rejected with NRC 0x31.
This proves NRC 31 can also appear without a long noisy lead-in.
Analyzer Conclusion
This is the condensed engineering verdict the analyzer would put in front of the operator.
Summary judgment
the capture narrows to a concrete SID / NRC 31 rejection rather than a generic coding-failed symptom.
Likely fault direction
verify session, security, and parameter preconditions before treating the reject as a payload-only problem.
Top action
anchor the first 0x7F / 0x31 response to the immediately preceding request and inspect the lead-in chain.
False Positives
These are cases where the tool symptom can point in the wrong direction unless the packet timeline is checked.
Symptom: The workshop tool reports only 'download failed' or 'coding failed'.
Packet truth: The packet trace identifies the exact rejected SID and shows whether nearby pending or setup requests were already struggling.
Risk: Engineers may debug the wrong stage because the UI label collapses several protocol steps into one symptom.
Symptom: NRC 31 is treated as proof of a malformed final payload only.
Packet truth: One evidence case shows a longer precondition chain, while another shows a direct compact reject.
Risk: The operator may overfit one failure pattern and miss the ECU-state branch.
Decision Tree
Use this order in real troubleshooting so packet evidence narrows the branch before repair effort expands.
- 1. Find the first 0x7F / 0x31 response and bind it to the immediately preceding request SID.
- 2. Check whether nearby session, security, or pending states suggest a precondition chain before the reject.
- 3. Decide whether the case looks like a compact direct reject or a longer staged failure path.
- 4. Only after that split should you inspect payload structure, DID choice, or routine parameters in detail.
Common Misreads
These are the interpretation traps that real packet evidence helps avoid.
- Treating NRC 31 as a standalone coding failure hides whether the real cause was session, security, payload structure, or ECU state.
- If a 0x31 is preceded by 0x78 on nearby setup requests, inspect the longer precondition chain before assigning a cause to the rejected request.
- A tool-level label like 'download failed' is weaker evidence than the exact SID and ECU address that returned 0x31.
Common Trigger Conditions
The request can fail because the parameter block is malformed, a coding precondition is missing, or the selected data identifier is not valid for the ECU state.
In OEM workflows this often appears during coding or calibration operations when the operator only sees a tool-level error and not the exact request payload.
What to Trace in the Capture
Look for the service identifier that immediately precedes the 0x7F negative response and confirm whether the failing sub-function or parameter block was sent correctly.
The important part is not just spotting NRC 31, but reconstructing the request chain that made the ECU reject it.
High-Value Questions to Answer
Was the ECU already in the right diagnostic session, security level, or environmental condition before the rejected request was sent?
Did the tool send the wrong data identifier, sub-function, or payload length even though the workshop symptom only showed a generic coding failure?
What the Analyzer Helps Surface
A structured timeline makes it easier to connect the negative response to the exact request packet, not just to the user-visible operation label in the diagnostic tool.
That matters when several writes, reads, or routine control calls happen close together during coding or flashing.
More Frequently Asked Questions
How do I find the request that triggered NRC 31?
Trace the 0x7F negative response backward to the immediately preceding service and inspect the exact request payload, not just the tool label.
Related Diagnostic Guides
Use nearby guides to move from protocol filtering to root-cause troubleshooting without leaving the knowledge base.