UDS Frames and NRC Codes

Micael Coutinho,Wed Nov 09 2022 • autosar bsw dcm

Analyzing the UDS frames and NRC in UDS responses allows us to learn more about the problems in our ECU. Learn about UDS frames and NRC's here

If you played around with UDS long enough, you know how frustrating it can be looking at a 0x7F message and not understanding what you did wrong. If not, maybe it would be beneficial for you to take a step back and check our article UDS Overview (opens in a new tab), where we explain what UDS is, why we need it and what are the commands you can perform to your ECU through it. Maybe the session is wrong? Maybe the PCI length is wrong? Did I get back to the default session due to a timeout? Learning about all NRC's (Negative Response Codes) and / or having a cheat sheet (which this article intends to create for you, so make sure to bookmark it for the next time your UDS adventures go wrong) with all NRC's can take the guess work out of UDS and make your life easier. Today, we dive deep into all the error codes and learn what really went wrong in your communication. But first, we'll also take a look at the possible UDS frames and their flow, so that our UDS understanding grows as a whole

Firstly, let's talk UDS frames. This is something we left out of the first part, but it's kind of important. As with any protocol, you may not need to know its internals, but being aware of the normal message flow and the parameters of UDS frames will only make you better as a developer. With that said, a UDS request contains the following structure:

UDS request structure { w: 492, h: 62 }

UDS request structure

Each parameter meaning is described below:

CAN-ID - Not actually part of the frame, but an important part of the request, as there are specific CAN-ID ranges to communicate via UDS. This is configured by the OEM's, and there can be more than 1 ID for UDS communication
PCI (Protocol Control Information) - control information required from the UDS requests, due to the use of CAN-TP (CAN Transport Layer) under UDS. If you have read our article CAN Protocol Overview (opens in a new tab), you already know about the limitations regarding CAN, that you cannot send more than 8 bytes in a message, unless you use CAN-TP. The important part to remember is that you can receive your response segmented into multiple CAN frames. We have not covered CAN-TP yet, but it's in our plans. The PCI size ranges from 1 to 3 bytes.
SID (Service ID) - the actual UDS command. It's specified in a single byte. We already covered all UDS commands in our first article regarding UDS, UDS Overview (opens in a new tab), so, if you're in need of a refresher, just go there.
Sub-function - Some UDS commands allow / require you to specify some extra information in order to, for example, suppress a positive response or the type of operation to be performed. Two UDS commands that need this are 0x11 (ECU Reset), where you need to specify the type of reset, and 0x31 (Routine Control).
Request Parameters - This is where the specifics of a request are placed. As an example, RDBI (Read Data By Identifier) requires two extra bytes, containing which is the identifier you want to read.

The responses are not so different. As you can see below, a positive response contains the SID + 0x40 as the first byte, followed by the sub-function and the relevant response data. As for the negative response, you receive the error SID (0x7F), the SID of the failed UDS request and the NRC, which will allow you to know further details about the error:

UDS response structure { w: 522, h: 222 }

UDS positive (top) and negative (bottom) response structure

The available NRC codes, which help you figure out what went wrong, are:

NRC	Name	Description
0x10	generalReject	Very general. Sent in case none of the other NRC's can describe the error
0x11	serviceNotSupported	ECU does not support the requested service
0x12	subFunctionNotSupported	Requested sub-function is not supported
0x13	incorrectMessageLengthOrInvalidFormat	Specified length of the message or fortmat is invalid
0x14	responseTooLong	The response length exceeds the limits specified by the underlying layer
0x21	busyRepeatRequest	ECU is busy to perform the required operation
0x22	conditionsNotCorrect	Pre-requisites to perform the UDS request are not valid, so the request cannot go through
0x24	requestSequenceError	When a certain sequence required for an UDS request is not complied with
0x31	requestOutOfRange	When a parameter value is outside the valid range
0x33	securityAccessDenied	Request denied due to the security measures established to perform the request by the ECU are not complied with
0x35	invalidKey	Security access denied due to invalid key
0x36	exceedNumberOfAttempts	Request will not be executed because there were more than N failed security access attempts
0x37	requiredTimeDelayNotExpired	Request denied because timeout after failed security access had not expired yet
0x70	uploadDownloadNotAccepted	Attempt to download / upload data rejected due to some issue
0x71	transferDataSuspended	Transfer of data aborted due to some issue
0x72	generalProgrammingFailure	Erasing or programming via UDS failed
0x73	wrongBlockSequenceCounter	Error detected in BS (Block Sequence) counter values by the ECU
0x78	ResponsePending	Request is valid, but ECU is not ready yet to process it
0x7E	subFunctionNotSupportedInActiveSession	Current session does not have permission to perform the request
0x81	rpmTooHigh	current RPM is too high to perform request
0x82	rpmTooLow	current RPM is too low to perform request
0x83	engineIsRunning	Request cannot be performed with engine running
0x84	engineIsNotRunning	Request cannot be performed with engine not running
0x85	engineRunTimeTooLow	Request cannot be performed because the engine has not been running for long enough
0x86	temperatureTooHigh	Temperature is too high to perform request
0x87	temperatureTooLow	Temperature is too low to perform request
0x88	vehicleSpeedTooHigh	Vehicle speed is too high to perform request
0x89	vehicleSpeedTooLow	Vehicle speed is too low to perform request
0x8A	PedalTooHigh	Throttle or pedal is in a position too high to perform request
0x8B	PedalTooLow	Throttle or pedal is in a position too low to perform request
0x8C	transmissionRangeNotInNeutral	Transmission is not in neutral
0x8D	transmissionRangeNotInGear	Transmission is not in gear
0x8F	brakeSwitchNotClosed	Brakes are not pressed
0x90	shifterLeverNotInPark	Shifter is not in park mode
0x91	torqueConverterClutchLocked	TCC (Torque Converter Clutch) is in a locked state
0x92	voltageTooHigh	Specific voltage in the ECU is too high to perform the request
0x93	voltageTooLow	Specific voltage in the ECU is too low to perform the request

Now, let's take a look at how the response is segmented. As explained earlier, when you use CAN-TP, you surpass the CAN limitation of 8 bytes, by implementing mechanisms to group multiple CAN frames into 1 response. An interaction between client (tester) and server (ECU / vehicle) can look like this:

UDS interaction { w: 352, h: 303 }

Possible UDS interaction between an ECU and a tester

As you can see by the illustration, there are 4 types of frames:

SF (Single Frame) - Contains the UDS request sent to the ECU.
FF (First Frame) - The ECU send this response with the initial part of the response and the total response length. This way, the tester app knows more messages are coming.
FC (Flow Control) - Gives the ECU some parameters that will define how the rest of the response will be sent to the tester. Most notably, there is the ST (Separation Time) Min parameter, which specifies the minimum time distance between each frame.
CF (Consecutive Frame) - Where the remainder of the response is sent by the ECU, according to the parameters specified in the FC frame.

As some closing thoughts, we hope this article can help you become more profficient with UDS. It's a very important protocol in the automotive world, an although it can look a bit complex and intimidating at first, when we bite the cookie chunk by chunk, as we try to do here on Autosar Today, everything becomes simpler. Happy diagnostics!

Author: Micael Coutinho (opens in a new tab)

References: