Mode 7 is similar to Mode 3, in that it does not take any PIDs, and reports on DTCs. They are so similar, in fact, that they share the same subroutines to generate responses to requests. However, while Mode 3 responds by reporting active DTCs, Mode 7 reports pending DTCs - that is, problems that have been detected but have not yet risen to the level of severity of an active DTC.
Another key difference between the two is that they support a slightly different set of DTCs. When I first listed the DTCs in the Mode 3 post, I thought that Mode 3 could report all of them. However, upon closer inspection, it turns out that only a subset of them will ever show up in a Mode 3 response. Similarly, the Mode 7 DTCs are a subset of the Mode 3 DTCs.
Rather than re-list the DTCs that are associated with Mode 7, I'll just list the numbers. You can refer to the previous Mode 3 post for more info.
Mode 7 DTCs
P0011, P0012, P0031, P0032, P0037, P0038, P0101, P0106, P0111, P0116, P0121, P0125, P0126, P0128, P0131, P0132, P0133, P0134, P0138, P0140, P0171, P0172, P0300, P0301, P0302, P0303, P0304, P0401, P0402, P0420, P0421, P0442, P0451, P0443, P0452, P0453, P0455, P0461, P0462, P0463, P0464, P0480, P0500, P0506, P0507, P0550, P0703, P0704, P0706, P0715, P0725, P0741, P0742, P0751, P0752, P0756, P0757, P0850, P1450, P1496, P1497, P1498, P1499, P1512, P1518, P1569, P1570
Mode 3 DTCs
(the above list), plus: P0010, P0102, P0103, P0107, P0108, P0112, P0113, P0117, P0118, P0122, P0123, P0222, P0223, P0327, P0328, P0335, P0340, P0505, P0720, P0743, P0753, P0758, P1562, P1601
Finally, there are a few other modes that report DTCs, and have their own subset of DTCs. More on these later. Up next: Mode 8.
I've been reverse-engineering ECUs since 2001. This blog is to share what I've learned about Honda and Mazda ECUs and to provide you with tips and advice if you would like to hack your own ECU.
Tuesday, February 22, 2011
Sunday, February 20, 2011
NB Miata - OBD Mode 6, part 1
There is some interest in Mode 6 because the information it provides can sometimes give "early warning" of problems, and also because it tends to be poorly documented (unless you pay for access to the information). Here's what I've been able to piece together from looking at the code. Although I prefer not to post before I think I fully understand a mode, in this case I decided to just write up what I've found so far, because it may be a while before I figure it out completely. Until then, perhaps this partial explanation may prove useful to someone.
Mode 6 supports the following TIDs (the request should only be the mode and the TID, with no other data bytes, which means a total request length of 6 bytes when you include the header and checksum byte):
00 - TIDs supported 01-20 (they are: 01, 02, 03, 04, 05, 06, 11, and 20)
20 - TIDs supported 21-40 (they are: 21, 22, 31, 32, and 40)
40 - TIDs supported 41-60 (only 41)
01 - for component ID (CID) 11, the test value stored at 10F56 needs to be less than 422
02 - for CID 11, the test value stored at 10D46 needs to be less than 62
03 - for CID 11, the test value stored at 10D4A needs to be less than 50
04 - for CIDs 01 and 02, the test value stored at 10970 needs to be greater than zero
05 - for CID 01, the test value stored at 10972 needs to be greater than zero
06 - for CID 01, the test value stored at 10974 needs to be greater than zero
11 - for CID 11, the test value stored at 10F5A needs to be greater than 40
21 - for CID 00, the test value stored at 10F6A needs to be less than the limit value stored at 10F6E
22 - for CID 00, the test value stored at 10F6C needs to be less than the limit value stored at 10F70
31 - for CID 00, the test value stored at 10F72 needs to be less than the limit value stored at 10F74
32 - for CID 00, the test value stored at 10F76 needs to be greater than the limit value stored at 10978
41 - for CID 00, the test value stored at 10F5C needs to be less than the limit value stored at 10F5E and greater than the limit store at 10F60
I got a little help by comparing the format of the reply message that the code puts together to the ISO 15031-5 spec. However, I don't yet know what each test value represents. I also don't know what components CIDs 0, 1, 2 and 11 refer to. I don't even know what the limit values are in some cases (although you could determine this pretty easily by simply plugging a scantool into the car and sending the appropriate Mode 6 requests). If anyone has this information and would like to share, please post a comment. I should eventually be able to figure it out on my own from looking at the code, but I would definitely appreciate it if someone could save me the time by telling me what the above tests are all about.
Next time, Mode 7, which is very similar to Mode 3.
Mode 6 supports the following TIDs (the request should only be the mode and the TID, with no other data bytes, which means a total request length of 6 bytes when you include the header and checksum byte):
00 - TIDs supported 01-20 (they are: 01, 02, 03, 04, 05, 06, 11, and 20)
20 - TIDs supported 21-40 (they are: 21, 22, 31, 32, and 40)
40 - TIDs supported 41-60 (only 41)
01 - for component ID (CID) 11, the test value stored at 10F56 needs to be less than 422
02 - for CID 11, the test value stored at 10D46 needs to be less than 62
03 - for CID 11, the test value stored at 10D4A needs to be less than 50
04 - for CIDs 01 and 02, the test value stored at 10970 needs to be greater than zero
05 - for CID 01, the test value stored at 10972 needs to be greater than zero
06 - for CID 01, the test value stored at 10974 needs to be greater than zero
11 - for CID 11, the test value stored at 10F5A needs to be greater than 40
21 - for CID 00, the test value stored at 10F6A needs to be less than the limit value stored at 10F6E
22 - for CID 00, the test value stored at 10F6C needs to be less than the limit value stored at 10F70
31 - for CID 00, the test value stored at 10F72 needs to be less than the limit value stored at 10F74
32 - for CID 00, the test value stored at 10F76 needs to be greater than the limit value stored at 10978
41 - for CID 00, the test value stored at 10F5C needs to be less than the limit value stored at 10F5E and greater than the limit store at 10F60
I got a little help by comparing the format of the reply message that the code puts together to the ISO 15031-5 spec. However, I don't yet know what each test value represents. I also don't know what components CIDs 0, 1, 2 and 11 refer to. I don't even know what the limit values are in some cases (although you could determine this pretty easily by simply plugging a scantool into the car and sending the appropriate Mode 6 requests). If anyone has this information and would like to share, please post a comment. I should eventually be able to figure it out on my own from looking at the code, but I would definitely appreciate it if someone could save me the time by telling me what the above tests are all about.
Next time, Mode 7, which is very similar to Mode 3.
Thursday, February 17, 2011
NB Miata - OBD Mode 5
If you thought Mode 4 was simple, Mode 5 is, in some ways, even simpler. At least a Mode 4 request causes something to happen. Mode 5 requests only return information, and that information never changes!
Mode 5 is meant to return information that is used for oxygen sensor monitoring. In the NB, only the following TIDs are supported:
Next up, Mode 6.
Mode 5 is meant to return information that is used for oxygen sensor monitoring. In the NB, only the following TIDs are supported:
- 00xx - this is the TIDs supported TID. It must be two bytes, but the second byte can be anything. The reply tells you that only TIDs 1 and 2 are supported
- 0101 - returns the rich-to-lean threshold voltage for O2 sensor 1
- 0102 - returns the rich-to-lean threshold voltage for O2 sensor 2
- 0201 - returns the lean-to-rich threshold voltage for O2 sensor 1
- 0202 - returns the lean-to-rich threshold voltage for O2 sensor 2
Next up, Mode 6.
Saturday, February 5, 2011
NB Miata - OBD Mode 4
This is a very simple mode. There are no PIDs. A mode 4 message tells the ECU to clear all DTCs.
Under the hood, the way it works is as follows. There are a slew of subroutines that periodically monitor the car's health and set DTCs as necessary. If you send a mode 4 message (with no PID - if you send a PID, it won't work), the ECU sets a bit (108E7, bit 2) to let these subroutines know that they should clear their associated DTCs. At the same time this bit is set, a countdown timer at 1094E is set to 30. When it counts down to zero, the "clear DTCs" bit is cleared, and the system returns to normal operation. I haven't yet worked out how long the ECU takes to countdown from 30 to 0.
Last time I said that I would post some details on the immobilizer system. I have been working on it, a lot, and have learned a lot, too, but I don't feel like I have enough of the big picture to share yet. So, maybe next time. Otherwise, the next post will be on OBD Mode 5.
Under the hood, the way it works is as follows. There are a slew of subroutines that periodically monitor the car's health and set DTCs as necessary. If you send a mode 4 message (with no PID - if you send a PID, it won't work), the ECU sets a bit (108E7, bit 2) to let these subroutines know that they should clear their associated DTCs. At the same time this bit is set, a countdown timer at 1094E is set to 30. When it counts down to zero, the "clear DTCs" bit is cleared, and the system returns to normal operation. I haven't yet worked out how long the ECU takes to countdown from 30 to 0.
Last time I said that I would post some details on the immobilizer system. I have been working on it, a lot, and have learned a lot, too, but I don't feel like I have enough of the big picture to share yet. So, maybe next time. Otherwise, the next post will be on OBD Mode 5.
Subscribe to:
Posts (Atom)