This ECU Reset Service ID tutorial specially made for automotive engineers who are working on the UDS protocol diagnostic system and want to learn about how an Automotive vehicle ECU can be reset. This topic will help you to know how a single ECU or a vehicle is getting reset if there is any malfunction that is not recovering automatically before doing any diagnostic of a vehicle.
I hope most of the people will be knowing what is reset if not please search any question or any doubt in my search engine to clear it and then go through this tutorial. If you are thinking that I already know the reset then why I will go through this topic? No, you are wrong. You might be knowing reset in a micro-controller and which is having standard reset.
But in automotive ECUs it is different and defined in ISO-14229 standard document how the reset should be done in an ECU and when what type of ECU reset you should do so that the proper ECU service maintenance will get done. Let’s go discuss all these ECUs resets to understand from basic to Deep. Still, if you have any query kindly go through our forum link to ask your query. PiEmbSysTech always supports you and your passion to make it successful.
What is ECU Reset?
The function of the ECU Reset Service Identifier (0x11) is to reset the ECU/Server in a different format according to the problem requirement. The objective of ECU reset is to recover the malfunctioned ECU from its non-working condition or hanged state or from any non-working condition but it should be able to communicate with the external diagnostic computer.
Basically, if any problem occurs in a vehicle and you don’t know the main root cause, then you must try this reset method. If the same problem you are facing then you need to go to the service station where the service engineer will do the diagnostic using their diagnostic computer.
Even if they will also try by using different reset method if it is not happening then they will go for an extended diagnostic session with some other UDS services which you can learn in other tutorials. In an ECU, the reset is very common and it can be done in a different way as per the ECU problem situation. It is a very important service in the UDS protocol. After a successful reset, the server shall return to the default session.
How does ECU Reset works?
The ECU Reset Service Identifier (0x11) is used by the client to request a server reset. To reset any ECU you need to connect your computer to the vehicle OBD-II port in the service station. As a developer or tester in the ECU development phase, they might be using any diagnostic tool, or Vector Can-analyzer or canoe tool. The reset means to clear your settings or change your settings.
This service requests the server to effectively perform a server reset based on the content of the reset type parameter value embedded in the ECU Reset request message. And the reset request will be received by a single ECU or all the ECU nothing but the total vehicle reset. If you know the fault is happening with which ECU then you can directly reset this ECU using ECU physical addressing or else if you don’t know the particular ECU you can reset total vehicle or all the ECU simultaneously.
The ECU Reset positive response message shall be sent before the reset is executed in the server to inform the client. After a successful ECU/server reset the server shall activate the default Session. That means there are different ECU resets and mostly they support extended diagnostic sessions. Once the server will accept the request message with reset type as sub-function from the client, it will reset all the data, parameters, and temporary memories as per the type of reset and it will refresh with start from main() of program.
Since after reset or ECU restart the ECU will start with default session, for any kind of ECU reset, first the ECU or server will send the response message to the client, then it will reset, and then automatically the ECU will jump to default session to start the ECU from the origin with a refresh. Let’s go discuss with different ECU reset types.
What are the types of ECU reset?
As we have discussed the ECU Reset Service Identifier (0x11) is a service Identifier in UDS protocol. The sub-function parameter reset Type is used by the ECU Reset request message to describe how the server has to perform the reset and all the different ECU reset types are defined in sub-functions which are shown in below table for your better understanding as per ISO-14229 standard.
| SBF | SBF Name | Description |
|---|---|---|
| 0x01 | Hard Reset | This is Equivalent to power reset |
| 0x02 | key Off On Reset | It is Equivalent to Ignition On-Off-on |
| 0x03 | Soft Reset | It is Equivalent to watch-dog reset of a micro-controller |
| 0x04 | Enable Rapid Power Shut Down | It is nothing but the deep sleep mode |
| 0x05 | Disable Rapid Power Shut Down | to reverse back from deep sleep mode to ECU run state |
| 0x06 – 0x3F | ISO SAE Reserved | This range of values is reserved by this document for future definition. |
| 0x40 – 0x5F | vehicle Manufacturer Specific (OEM) | This range of values is reserved for vehicle manufacturer specific use. |
| 0x60 – 0x7E | System Supplier Specific | This range of values is reserved for system supplier specific use. |
| 0x07 | ISO SAE Reserved | This value is reserved by this document for future definition. |
Hard Reset (0x01):
The hard reset is one type of reset in the ECU Reset Service Identifier (0x11) where the tester can request this to reset the ECU to re-initialize the core hardware components of the system. But now the question is what is hard reset? If I will tell simply, then I can say just remove the battery (power supply) from the ECU and connect the ECU again with the battery.
Then think what will happen if you are removing the battery from the hardware immediately when the main application software is running in the processor. Obviously, at running time, all the data are like as: DID, DTC, and all the important data’s which needs to be stored in the permanent memory or you can say it is Non Volatile Memory for future need and diagnostic purposes will be deleted without storing into the Non Volatile Memory.
But if the Hard reset request received by the ECU at the time of any memory operation, then first it should complete it, and then it will do the hard reset. That is the main difference between direct power removal and hard reset. So mostly the OEM’s are not preferred this reset in the ECU, but sometimes it required to do for the hanging and diagnostic and also for re-initialization of volatile and non-volatile memory.
For Example: How to request a reset message from a client to server?
A client sends a request message to server to reset an ECU:
Client –> Server:
| PCI (B7) | Request SID (B6) | SBF ID (B5) | NULL (B4) | NULL (B3) | NULL (B2) | NULL (B1) | NULL (B0) |
|---|---|---|---|---|---|---|---|
| 0x02 | 0x11 | 0x01 | xx | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x02: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 2 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport Protocol.
- 0x11: is the Reset request service Identifier which should be sent by the client to the server for a reset.
- 0x01: The next byte of data is sub-function for hard reset is 0x01 for a hard reset.
- xx: Other bytes are null.
| PCI (B7) | +Ve Response SID (B6) | SBF ID (B5) | NULL (B4) | NULL (B3) | NULL (B2) | NULL (B1) | NULL (B0) |
|---|---|---|---|---|---|---|---|
| 0x02 | 0x51 | 0x01 | xx | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x02: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 2 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x51: is the Positive Response service Identifier which should be sent by the server to Client for successfully reset done.
- 0x01: Next byte of data is sub-function for hard reset is 0x01 for a hard reset.
- xx: Other bytes are null.
| PCI (B7) | -Ve Response SID (B6) | Reset SID (B5) | NRC (B4) | NULL (B3) | NULL (B2) | NULL (B1) | NULL (B0) |
|---|---|---|---|---|---|---|---|
| 0x03 | 0x7F | 11 | 12/13/22 | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x03: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 3 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x7F: is the Negative Response service Identifier which should be sent by the server to the client for the failure of reset for any reason.
- 0x11: is the Response service Identifier which should be sent by the server to Client here to know the negative response error happened for which Service Identifier.
- 0x12/13/22: These are the Negative response error codes which define the cause of reset failure in that ECU.
- xx: Other bytes are null.
Key Off-On Reset (0x02):
The Key Off-On Reset is nothing but the ignition Off-On process of a vehicle in the ECU Reset Service Identifier (0x11). If I can say this is a proper sleep wake-up process of the processor/microcontroller. When you will do the ignition off, then your engine and all the ECU’s will not get the power down immediately, first, it will go to the boot mode and store all the data’s in the permanent memory (NVM) of the processor and then it will de-init all the programs, and it will get the power down without losing any important data. If again you will turn on the vehicle then it will follow the same reverse process and run the application. You can say that this is the proper reset for the ECU.
Ex: How to do a Key-Off-On reset for an ECU?
Request: Client –> Server: 02 11 02
Positive Response: Server–> Client: 02 51 02
Negative Response: Server–> Client: 03 7F 11 NRC (12/13/22)
| PCI (B7) | Request SID (B6) | SBF (B5) | xx (B4) | xx (B3) | xx (B2) | xx (B1) | xx (B0) |
|---|---|---|---|---|---|---|---|
| 0x02 | 0x11 | 0x02 | xx | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x02: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 2 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x11: is the Reset request service Identifier which should be sent by the client to the server for a reset.
- 0x02: The next byte of data is sub-function for hard Key-Off-On is 0x02 for a hard reset.
- xx: Other bytes are null.
| PCI (B7) | 0x51 (B6) | 0x02 (B5) | NULL (B4) | NULL (B3) | NULL (B2) | NULL (B1) | NULL (B0) |
|---|---|---|---|---|---|---|---|
| 0x02 | 0x11 | 0x02 | xx | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x02: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 2 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x51: is the Positive Response service Identifier which should be sent by the server to Client for successfully reset done.
- 0x02: The next byte of data is sub-function for hard reset is 0x02 for a hard reset.
- xx: Other bytes are null.
| PCI | -Ve Response SID | SID | NRC | NULL | NULL | NULL | NULL |
|---|---|---|---|---|---|---|---|
| 0x03 | 0x7F | 0x11 | 12/13/22 | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x03: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 3 which defines the length of data byte sent by client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x7F: is the Negative Response service Identifier which should be sent by server to client for failure of reset for any reason.
- 0x11: is the Response service Identifier which should be sent by server to Client here to know the negative response error happened for which Service Identifier.
- 0x12/13/22: These are the Negative response error codes which defines the cause of reset failure in that ECU.
- xx: Other bytes are null.
Soft Reset (0x03)
The Soft reset is nothing but the restart of your main application software means your stack pointer of the microcontroller will point to the address of the main(). You can say as WatchDog reset like if any hang or lock will occur in your application software for which it will stop the execution, then the watchdog will reset the controller, and again it will start from the main function. This is a very common reset service sub-function in ECU Reset Service Identifier (0x11) which is using in most of the functionality to restart the application software.
Ex: How to do a soft reset for an ECU?
Request: Client –> Server: 02 11 03
Positive Response: Server–> Client: 02 51 03
Negative Response: Server–> Client: 03 7F 11 NRC (12/13/22)
| PCI (B7) | Request SID (B6) | SBF (B5) | NULL (B4) | NULL (B3) | NULL (B2) | NULL (B1) | NULL (B0) |
|---|---|---|---|---|---|---|---|
| 0x02 | 0x11 | 0x03 | xx | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x02: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 2 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x11: is the Reset request service Identifier which should be sent by the client to the server for a reset.
- 0x03: The next byte of data is sub-function for hard Key-Off-On is 0x03 for a hard reset.
- xx: Other bytes are null.
| PCI (B7) | +Ve Response SID (B6) | SBF ID (B5) | NULL (B4) | NULL (B3) | NULL (B2) | NULL (B1) | NULL (B0) |
|---|---|---|---|---|---|---|---|
| 0x02 | 0x51 | 0x03 | xx | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x02: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 2 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x51: is the Positive Response service Identifier which should be sent by the server to Client for successfully reset done.
- 0x03: The next byte of data is sub-function for hard reset is 0x03 for a hard reset.
- xx: Other bytes are null.
| PCI | -Ve Response SID | SID | NRC | NULL | NULL | NULL | NULL |
|---|---|---|---|---|---|---|---|
| 0x02 | 0x7F | 0x11 | 12/13/22 | xx | xx | xx | xx |
In the above 8- byte of CAN data frame table,
- 0x03: this Protocol Control Information byte is holding two information with LSB nibble and MSB nibble. LSB Nibble is 3 which defines the length of data byte sent by the client. MSB Nibble is 0 which defines the single frame in CAN Transport protocol.
- 0x7F: is the Negative Response service Identifier which should be sent by the server to the client for the failure of reset for any reason.
- 0x11: is the Response service Identifier which should be sent by the server to Client here to know the negative response error happened for which Service Identifier.
- 0x12/13/22: These are the Negative response error codes which define the cause of reset failure in that ECU.
- xx: Other bytes are null.
Enable Rapid Power Shut Down (0x04):
The server shall execute the function immediately after “key/ignition” is switched off. While the server executes the power down function, it shall transition either directly or after a defined stand-by time to sleep mode. If the client requires a response message and the server is already prepared to execute the “rapid power shut down” function, the server shall send the positive response message prior to the start of the “rapid power shut down” function. The next occurrence of a “key on” or “ignition on” signal terminates the “rapid power shut down” function. This service is rarely used in the vehicle and most of the OEM doesn’t support it in ECU Reset Service Identifier (0x11) in production.
Ex: How to enable rapid power shut down for an ECU?
Request: Client –> Server: 02 11 04
Positive Response: Server–> Client: 02 51 04
Negative Response: Server–> Client: 03 7F 11 NRC (12/13/22)
Disable Rapid Power Shut Down (0x05):
This value requests the server to disable the previously enabled “rapid power shut down” function.
Ex: Request: Client –>Server
| PCI | Request SID | SBF | xx | xx | xx | xx | xx |
|---|---|---|---|---|---|---|---|
| 02 | 11 | 05 | 00 | 00 | 00 | 00 | 00 |
Response: Server –>Client:
Positive Response:
| PCI | +Ve Response SID | SBIF ID | NULL | NULL | NULL | NULL | NULL |
|---|---|---|---|---|---|---|---|
| 02 | 51 | 05 | 00 | 00 | 00 | 00 | 00 |
Where, 02–> PCI = 0x0 & DLC = 0x2,
Negative Response:
| PCI | -Ve Response SID | Reset SID | NRC | NULL | NULL | NULL | NULL |
|---|---|---|---|---|---|---|---|
| 02 | 7F | 12/13/22/33 | 00 | 00 | 00 | 00 | 00 |
Where, 02–> PCI = 0x0 & DLC = 0x6.
