CAN Buss, MUT, and SAE J2534 Pass-Through Programming of ECUs

kiev · May 10, 2023

This SAE specification document covers what is necessary to reprogram ECUs on vehicles such that aftermarket service and repairs can be made on cars from 2004. There is a second part to cover cars from before then also.
[Link to an online pdf available since it was incorporated into Federal Law: law resource copy

Possibly this is how the MUT3 works, but it is not explicitly revealed in the factory service manual.

In the FSM, in order to replace cells or a pack, then a reset command must be issued to restore the full 50Ah capacity and range.

If replacing the pack with larger capacity cells (upgrade pack), then it seems that the capacity value of the cells, stored in memory somewhere and available for display as a data list item, needs to be reprogrammed.

Hopefully we can work on this to figure out how to do it, and keep these whimsical jelly beans running with a bigger pack.

kiev · May 20, 2023

Index placeholder.
1. Link to SAE 2534: http://www.tiecar.net/downloads/SAE_J2534_2002.pdf

kiev · May 20, 2023

Section 6. Pass-Thru System Requirements
6.1
PC Requirements—Generic PC running a Win32 Operating System (e.g., Windows 95/Windows 98/Windows NT/Windows Millennium Edition, Windows 2000, Windows XP, ...). The PC should be capable of connection to the Internet.

There seems to be about 5 versions of this standard since 2002, and there is a section to open the requirements to other Operating Systems than windoze.

kiev · Jun 25, 2023

Some general overview and historical references.

CAN (Controller Area Network) Buss History (Bosch) and Overview at Wikepidea: https://en.wikipedia.org/wiki/CAN_bus

OBD-II (On-board Diagnostics Two): Since 1996 the OBD-II specification is made mandatory for all cars sold in the United States. Also since 2008 all cars sold in the United States are required to use the ISO 15765-4 signaling standard protocol (a particular variant of the Controller Area Network (CAN) bus). See the wiki page for more.

OBD-II PIDs (Parameter Identifiers): SAE standard J1979 defines many OBD-II PIDs. All on-road vehicles and trucks sold in North America are required to support a subset of these codes, primarily for state mandated emissions inspections. Manufacturers also define additional PIDs specific to their vehicles. A listing of the standard pids and the Service Modes is on the pids wike page.

kiev · Jun 25, 2023

Placeholder for $tandard$.

The SAE and ISO have developed standards and specifications for every aspect of the process for doing OBD. Of course they aren't doing all this for free so it costs $$$ to get copies of their stuff. Fortunately the library of congress has copies for any that are included as part of US Federal Law or Regulations.

kiev · Jun 25, 2023

Placeholder for ISO specs.

kiev · Jun 25, 2023

PH for SAE.

kiev · Jun 25, 2023

PH for findings.

Puddnig's thread about his code on gifthub to use blueteeth to read BMU data:

https://myimiev.com/forum/viewtopic.php?p=37099#p37099

[edit: link after the forum update]
https://myimiev.com/threads/software-to-read-bmu-monitoring-data.4129/#post-46228

kiev · Jun 25, 2023

Some interesting new PIDs or CANIDs [783,784,785] seen while using the MUT. Piev (Paul) was doing a "read DTCs" while capturing the OBD traffic and we can see something that the MUT is doing...

khouse@kennys-MacBook-Pro Downloads % grep -e'0x784' -e'0x785' -n DTC_Read.txt
Grouped the 784 and 785 according to similar time stamp:
21224:18:41:04.845 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 87 0 0 0 0 0
21229:18:41:04.892 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 78 FF FF FF FF

21247:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 FF 0 4 10 0 0 34
21251:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 36 37 30 41 36 37 33
21255:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x23 0 0 FF FF FF FF FF
ASCII characters seen in the previous 3 lines: 4670A673 this looks like a mitsubishi part number? It is a part number-- for the 2012 the ABS pump module!
https://www.partrequest.com/auto-parts-detail/2012-mitsubishi-i-miev-abs-pump-module-0-265-951-83-254577887733

21285:18:41:05.033 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0
21289:18:41:05.033 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 12 FF FF FF FF

21320:18:41:05.126 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x4 18 0 FF 0 0 0 0
21326:18:41:05.173 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 18 78 FF FF FF FF

21431:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 14 58 6 D1 4 20 D1
21434:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 5 20 D1 1B 20 D1 0
21438:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 20 D1 9 20 D1 8 20

21510:18:41:05.680 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 4 0 0 0 0
21514:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 4 20 21
21517:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21548:18:41:05.805 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 5 0 0 0 0
21550:18:41:05.805 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 5 20 21
21554:18:41:05.852 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21588:18:41:05.945 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 1B 0 0 0 0
21591:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 1B 20 21
21592:18:41:05.945 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21595:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21630:18:41:06.039 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 0 0 0 0 0
21636:18:41:06.086 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21670:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 9 20 21
21673:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21703:18:41:06.273 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 8 0 0 0 0
21707:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 8 20 21
21708:18:41:06.273 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21710:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 FF FF FF

783
18:41:11.752 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x23 20 20 0 0 0 0 0
18:41:11.845 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x5 58 1 D1 16 60 0 0

coulomb · Jul 9, 2023

I had a quick look at the J2534 standard, as it sounded like it might be what I was looking for, which was a way of reaching out from the OBDII connector to other CAN buses, like the one that the On Board Charger is connected to. In particular, I'd like to fish out the OBC diagnostic code without having to pay hundreds of AU$ for an iCarsoft i909 or similar. [ Edit: I no longer believe that the i909 can do this. Sigh. ] Alas, it's not for that.

The "pass through device" seems to refer to the hardware between a PC and a vehicle, so a MUT-3 is such a thing. The J2534 standard seem to describe an API (Application Programming Interface) for a DLL or other library that the vehicle or pass-through device manufacturer provides. This library is intended to be called by a PC program that understands completely what the ECU needs. The standard talks about sending and receiving "messages", which can have pretty much any meaning, apart from a dozen or so bytes at the front that are defined. These messages can be up to just over 4 KiB of data, so these could be flash blocks or parts thereof, or anything at all. There is a function for getting the pass-through device to put a programming voltage onto a specific OBD-II pin. I would image that most ECUs would generate any flash programming voltage needed, or indeed the chip itself likely can generate its own.

So: there appears to be no standardisation of the actual data.
[ Edit: This appears to be because I wasn't looking at the right standard; see next page. ]

coulomb · Jul 9, 2023

[ Edit: Most of the below is wrong, see following posts.
It now looks like 784 messages are TO the BMU, 785 messages are FROM the BMU.
It also looks now that responses starting with 0x10 have 4 data bytes, not 3 as with the MG.
See my massively amended interpretation here. ]

kiev said:
Some interesting new PIDs or CANIDs [783,784,785] seen while using the MUT.

My understanding is that PIDs and CAN IDs are different things; more below.

Piev (Paul) was doing a "read DTCs" while capturing the OBD traffic and we can see something that the MUT is doing...

Excellent! This is what I hope to be doing soon. Here are my guesses for what some of this means, based in part on playing with raw ELM327 commands to my MG ZS EV (not available in America), mainly in this post.

21224:18:41:04.845 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 87 0 0 0 0 0

784 may not be associated with returning PID data. It seems to be common to always use 8 data bytes in the CAN data, and waste the first data byte by using it for the length of useful data (in this case 2). [ Edit: It looks like this might be a service byte, which often but not always corresponds with the length of the data after that point. ] So the data here is 1A 87, very likely representing 0x1A87 or 6791 in decimal. Note how the last 5 bytes are all 0s; unused bytes seem to be 0s, FFs, or occasionally 55s or CCs. However, since Paul was doing a "read DTCs", it seems possible that this 0x1A87 represents the last 4 characters of trouble code P1A87 ("CMU06 module temperature sensor abnormal").
[ Edit: As below, 1A 87 seems to be asking the BMU for hardware information. Paul has decoded this now. ]

21229:18:41:04.892 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 78 FF FF FF FF

By contrast, 0x785 does appear to be a PID response CAN Id, possibly for an ECU with a primary address of 0x785 - 8 = 0x77D. But since the first byte is 3 and there are 3 non-zero, non-FF bytes following, this packet may actually be normal data, not related to a PID. However, it could also be related to a trouble code like P1A78 ("CMU03 battery cell voltage sensor abnormal").
Or, it could be that 7F indicates that the ECU doesn't recognise the request, and 1A is the service code. But then the last byte should be 0x31, according to the standard.
Maybe it indicates that trouble code P1A78 is not asserted.

21247:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 FF 0 4 10 0 0 34
21251:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 36 37 30 41 36 37 33
21255:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x23 0 0 FF FF FF FF FF

I would normally expect a sequence of packets like this starting with 0x21, 0x22... to be preceded by a packet starting with 0x10, and there are such examples later on. Perhaps the 0x10 packet got filtered out somehow.

Generally, 0x21 at the start of the packet means "extended data continuation frame 1". Note the third frame with only two nulls as real data; this seems to terminate an ASCII string (in this case "4670A673").

ASCII characters seen in the previous 3 lines: 4670A673 this looks like a Mitsubishi part number? It is a part number-- for the 2012 the ABS pump module!

That sounds reasonable, and helpful. Though I wonder if it's related to a BMS trouble code.

21285:18:41:05.033 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0
21289:18:41:05.033 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 12 FF FF FF FF

21320:18:41:05.126 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x4 18 0 FF 0 0 0 0
21326:18:41:05.173 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 18 78 FF FF FF FF

Strange how 784 data can be 2 bytes or 4. The 4 byte packet doesn't seem to be DTC related.
P1A9C seems to be related to renumbering CMUs (per this page), which doesn't seem to fit this data.
Again, the 7F <service code> 78 may indicate request not recognised. Though the first 785 packet above does not end in 78, so that seems to rule out the idea that Mitsubishi use 0x78 instead of the standard 0x31.

21431:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 14 58 6 D1 4 20 D1
21434:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 5 20 D1 1B 20 D1 0
21438:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 20 D1 9 20 D1 8 20

This is formatted like MG PID response data. 0x10 means this is the first frame of a multi-frame response. 0x14 (decimal 20) means 20 bytes of real data after this one. 0x58 is the "custom service". It would appear in data going to the ECU, either as 0x58 or as 0x18 (0x40 is sometimes added to the service code (see Wikipedia OBDII PIDs)). The next 2 bytes are a copy of the PID (Parameter IDentifier), which is just a code indicating what data is requested or provided. In this case, it's 0x06D1, although it's suspicious that 0x0yD1 (y is a varying hex digit) is common in the actual data. Then there is 3 bytes of data in this frame (04 20 D1), then 7 bytes in the next frame, and 7 in the last frame. That adds up to 3+7+7 = 17 bytes of data, plus the service code and PID (1+2), a total of 20 bytes, as given in the first frame. It just happens that there are no unused data bytes in this data set.
[ Edit: The first D1 is actually the first byte of the data. ]

I can't guess what this data represents. 0x20 followed by 0xD1 is very common in this particular response data.

21510:18:41:05.680 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 4 0 0 0 0

A single frame response. Doesn't look like a PID response.

21514:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 4 20 21
21517:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

This looks like a 2-frame PID response, 12-3 = 9 bytes of data, service code 0x57, PID 0x1D1.

21548:18:41:05.805 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 5 0 0 0 0

Doesn't look like a PID response.

21550:18:41:05.805 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 5 20 21
21554:18:41:05.852 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

PID response, 12-3=9 bytes data, identical data except for the first byte being one higher. This first byte may be a sequencing byte.

21588:18:41:05.945 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 1B 0 0 0 0

3 bytes, does not look like PID response.

21591:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 1B 20 21
21592:18:41:05.945 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21595:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

A two-frame PID response, identical to two previous ones apart from the first byte, with a 784 packet interspersed. That 784 packet doesn't seem to fit the usual pattern, unless 0x30 is another framing code. Maybe it means "nothing to report, all is well",
[ Edit: as follows, 30 0 ... 0 is a flow control message. ]

21630:18:41:06.039 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 0 0 0 0 0

21636:18:41:06.086 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

This continuation frame seems to be missing its first frame. Identical data to earlier second frames.

21670:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 9 20 21
21673:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

Another two-frame response with the same data, again except for the first byte. This time the first byte isn't just a little more than the last time, i.e. this disproves the sequence idea, unless a lot of data is missing.

21703:18:41:06.273 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 8 0 0 0 0

Again, only the last byte of this data is changing.

21707:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 8 20 21
21708:18:41:06.273 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21710:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 FF FF FF

Another two-frame response, also with the 784 packet between frames.

783
18:41:11.752 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x23 20 20 0 0 0 0 0
18:41:11.845 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x5 58 1 D1 16 60 0 0

These don't appear to be a PID response.

kiev · Jul 9, 2023

It's great that you have investigated the MG and can see the similar data frame structures.

The SAE J1979 defines 9 or 10 Service Modes that can be queried by the diagnostic test equipment. Each mode has Parameter IDs that can be requested, and these PIDs also have Frame Numbers for specific functions.

i think it is not necessary to have a MUT and VCI to perform 'diagnostic' scans, but it does help. The basic Hayes AT Modem commands can be entered thru an ELM device from a terminal window to establish communication, and then the Service Mode, PID and Frame can be sent from the command line. Brute force method.

But Paul has made some great progress on discovering the SM, Pids, and Frames that the MUT is sending, here is an example:

Code:

Service Mode x02 data request SIDRQ [SAE J1979-Request Freeze Frame Data]
Parameter ID (PID) 0x21 [Appendix A of SAE J1979DA]
Frame # (FRNO) 0x01,02,03..

022101 – All Battery Data
022102 – Cell Voltage
022103 – Cell Temperature
022104 - Cell Balancer
022105 - Special Function tests
022106 - Odometer
022111 - Build Date AC/DC power/Total Ah
022113 – Number of Cells

Parameter 0x1A 
021A87 – BMU Hardware Info
021A90 – VIN Number
021A9C -BMU Software Info

Parameters 0x31, 0x33
023105 – Check Leak Sensor
023303 – Cell Numbering

SIDRQ Service Mode 0x03 [J1979 Obtain DTCs]
Parameter 0x17
03171AC6 – Freeze Frame data
0317D161 – DTC’s

SIDRQ Service Mode 0x04 [J1979 ....] 
041800FF – BMU DTC’s
0430130701 & 03301301 – Actuator test of Bat Cooling PWM
0430140701 - Bat Balance Unit


MUT notes listing data and decoding what the commands do:
When Mut initiates by DTV button command is issued
0x7E0 02 1A 90
Response:
0x18DA15F1 03 22 F1 90 is issued
0x751 02 1A 90 
0x752 10 13 5A 90 4A 41 33 32 
0x751 30 
0x752 21 31 35 48 31 31 43 55 
0x752 22 30 33 31 33 37 39 0 
Vin Number JA3215H11CU0313790

Select BMU Functions
0x761 02 1A 87  must mean get BMU hardware info
Response:
0x762 10 16 5A 87 04 85 00 04
0x761 30 00 00 00 00 00 00 00
0x762 21 FF 00 02 BF 10 3A 39
0x762 22 34 39 39 44 30 32 39
0x762 23 20 20 00 00 00 00 00 
ECU Origin		04
Supplier ID 		85
ECU ID			00
ECU Diagnostic Version	04
Hardware Version	0002
Software Version	BF103A
Hardware Part Number	9499D029
Space Space

0x761 02 1A 9C  Get BMU software info
0x762 10 15 5A 9C 01 04 85 00
0x761 30 00 00 00 00 00 00 00
0x762 21 04 FF BF 10 3A 39 34
0x762 22 39 39 44 30 32 39 30
0x762 23 30 20 00 00 00 00 00
Number of Model	01
ECU Origin		04
Supplier ID 		85
ECU ID			00
ECU Diagnostic Version	04
Software Version	BF103A
Software Part Number	9499D02900

Not sure what I did to get these file says DTC's
Also not sure how to interpret DTC data
0x751 02 1A 87
0x751 30 00 00 00 00 00 00 00
0x752 23 D0 81 20 AD 01 00 2B
0x752 80 00 00 00 00 00 00 00
0x751 03 17 D1 61 
0x752 2A 07 D0 80 78 27 10 4B
0x752 2B 02 80 00 00 00 00 00 
Did another check DTC's but from BMU menu
Below is the values the MUT reported but I can't seem to correlate them 
to the data
0x761 04 18 00 FF
0x762 10 0E 58 04 1A C6 20 D9
0x761 30 00 00 00 00 00 00 00
0x762 21 26 20 D0 73 20 1A A7
0x762 22 20 4A 01 01 5E 01 5D
Codes it gave me were 
U1926 ECU V-Can Error
U1073 Buss off
P1AA7 Ev-ECU Can timeout
clicked Freeze Frame data on this screen
0x761 03 17 1A C6
0x762 10 0C 57 01 1A C6 20 22
0x761 30 00 00 00 00 00 00 00
0x762 21 15 00 00 00 00 14 A7

Odometer reading 		55840 Km	
Ignition cycle   		2
Elapsed time 			2403 minutes
Triggering Mem. of FFD	U1926 1/1 block
Actuator test of Bat Cooling PWM
0x761 04 30 13 07 01
0x761 03 30 13 01
0x761 30 00 00 00 00 00 00 00
Bat Balance Unit
0x761 04 30 14 07 01
0x761 03 30 14 01
Check Leak sensor output
0x761 02 31 05
0x761 02 21 01
0x761 30 00 00 00 00 00 00 00 
Cell Balancer 
0x761 02 21 04
0x761 30 00 00 00 00 00 00 00
Cell numbering
0x761 02 33 03
Special Function tests
0x761 02 21 05
0x762 04 61 05 FF 0F 00 FA 00
0x761 02 21 01 
0x762 10 2E 61 01 89 91 01 79
0x761 30 00 00 00 00 00 00 00
0x762 21 30 01 75 04 0D A8 AD
0x762 22 02 4A 01 01 5E 01 5D
0x762 23 01 2B 00 F9 00 FA 00
0x762 24 0F 0F 01 C7 01 21 A1
0x762 25 FE 00 00 01 74 74 7A
0x762 26 64 00 04 00 00 00 00

The 761 and 762 CANids seem to be the Request and Reply for the BMU ecu.
Not sure what ecu is meant by the 751 and 752 CIDs.

The designation of ECU CANids for the miev does not follow that required in the J1979, but then again an EV doesn't have regulated engine emissions.

kiev · Jul 9, 2023

Some DTC snooping:

Code:

GET DTC (command from MUT)
Fltr: 5 ID: 0x761 Len: 8 Data: 0x4 18 0 FF 0 0 0 0 
Fltr: 5 ID: 0x762 Len: 8 Data: 0x10 B 58 3 1A 4B 60 1A 
Fltr: 5 ID: 0x761 Len: 8 Data: 0x30 0 0 0 0 0 0 0 
Fltr: 5 ID: 0x762 Len: 8 Data: 0x21 58 60 1A C6 20 39 34 
CODES WERE
P1A4B   Each Cell Volt Diff (Hi side)
P1A58   CMU07 Cell Volt low
P1AC6   Cell volt low BMU

Apparently not ASCII 

May have to take pack out and check connection to CMU 07 H
Periodically reads 0.
Car shuts down and I have to restart it.
At least we know the Codes are readable in hex
Not sure about the P

ERASE DTC

Fltr: 5 ID: 0x761 Len: 8 Data: 0x3 14 FF 0 0 0 0 0 
Fltr: 5 ID: 0x762 Len: 8 Data: 0x3 54 FF 0 C6 20 FE 34 
Fltr: 5 ID: 0x761 Len: 8 Data: 0x4 18 0 FF 0 0 0 0 
Fltr: 5 ID: 0x762 Len: 8 Data: 0x2 58 0 0 C6 20 FE 34

There are Flow Control Frames sent to request more time or slow down the reply to allow processing, for example:
ID: 0x761 Len: 8 Data: 0x30 0 0 0 0 0 0 0

coulomb · Jul 9, 2023

kiev said:
Some DTC snooping:

Excellent results, thanks!

Not sure about the P

I think that the P is inherent from what ECU responds with the trouble code. Anything battery or Powertrain related would start with P, so that includes all codes from the BMU and on-board charger. [ Edit: see next post, DTCs are lightly encoded. ]

coulomb · Jul 10, 2023

coulomb said:
Not sure about the P

Click to expand...

I think that the P is inherent from what ECU responds with the trouble code. Anything battery or Powertrain related would start with P, so that includes all codes from the BMU and on-board charger.

Oops, looks like it's the top two bits:

From section 6.3.1 of https://suzuki-club.ru/attachments/75537/?temp_hash=3cc10ac7ead6c32b55fe1c1bd0e462bc .

So two bytes per trouble code.

coulomb · Jul 10, 2023

Did another check DTC's but from BMU menu
Below is the values the MUT reported but I can't seem to correlate them
to the data
0x761 04 18 00 FF
0x762 10 0E 58 04 1A C6 20 D9
0x761 30 00 00 00 00 00 00 00
0x762 21 26 20 D0 73 20 1A A7
0x762 22 20 4A 01 01 5E 01 5D
Codes it gave me were
U1926 ECU V-Can Error
U1073 Buss off
P1AA7 Ev-ECU Can timeout

I parse as follows:

Code:

0x761 04 18 00 FF              # Request DTCs (Service ID $18) from the BMU (0x761)
0x762 10 0E 58 04 1A C6 20 D9  # $0E - 2 = 12 bytes of data, =4 DTCs
# 58 = service ID + $40 (successful) 04 = real PID??
# 1AC6 20: P1AC6 asserted (don't know why it wasn't visible)
# Flags of $20 seems to be most common: ordinary trouble code asserted?
0x761 30 00 00 00 00 00 00 00   # Flow control, ignore
0x762 21 26 20 D0 73 20 1A A7
# First byte of data this frame is 26, but D9 is left over from the above
# D926 20: D9 has 2 MSBs set, so this is a network or U code: U1926, as appears (ECU V-Can error)
# D073 20: U1073 as appears (Bus off)
0x762 22 20 4A 01 01 5E 01 5D
# 1AA7 (from previous frame) 20: P1AA7 as appears (Ev-ECU Can timeout)
The 4A .. 5D are unused bytes, should have been zeroed or set to FF

coulomb · Jul 10, 2023

kiev said:
Some interesting new PIDs or CANIDs [783,784,785] seen while using the MUT. Piev (Paul) was doing a "read DTCs" while capturing the OBD traffic and we can see something that the MUT is doing...

My massively changed interpretation of this initial data, given the later findings:

Code:

# = Mike's comments
21224:18:41:04.845 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 87 0 0 0 0 0		# To BMU: get hardware info?
21229:18:41:04.892 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 78 FF FF FF FF	# 7F is likely "semi-NAK" to service 1A with response code 78
											# Response code $78 = RequestCorrectlyReceived-ResponsePending
# Data missing? Or could be continuation of the above
21247:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 FF 0 4 10 0 0 34
21251:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 36 37 30 41 36 37 33
21255:18:41:04.939 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x23 0 0 FF FF FF FF FF
ASCII characters seen in the previous 3 lines: 
4670A673 this looks like a Mitsubishi part number?
It is a part number-- for the 2012 the ABS pump module!
https://www.partrequest.com/auto-parts- ... 4577887733
# Hardware version 0004
# Software version 100000
# Hardware part number 4670A673 - weird that it's not a 9499 number

21285:18:41:05.033 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0		# Get software info?
21289:18:41:05.033 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 1A 12 FF FF FF FF	# RC $12: subFunctionNotSupported-InvalidFormat

21320:18:41:05.126 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x4 18 0 FF 0 0 0 0		# Parameter 18 might be request DTCs
21326:18:41:05.173 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x3 7F 18 78 FF FF FF FF	# Response pending
21431:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 14 58 6 D1 4 20 D1		# $14 = 20-2 = 18 bytes 58 = param + $40 06 = real service?
21434:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 5 20 D1 1B 20 D1 0
21438:18:41:05.476 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x22 20 D1 9 20 D1 8 20
# DTCs seem to be 3 bytes here: lightly encoded DTC then a flags byte
# So network (=U) codes U1104 flags 20 U1105 20 U111B 20 U1100 20 U1109 20 U1108 20

21510:18:41:05.680 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 4 0 0 0 0		# $17 = Freeze frame data on DTC screen?
											# Maybe the D1 04 means freeze frame data for U1104?
21514:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 4 20 21		# $0C-2 = 10 bytes, 57 = param+$40, 01 = real service?
											# D104 20 = U1104? Steering related
21517:18:41:05.711 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF	# No idea really FF is unused

21548:18:41:05.805 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 5 0 0 0 0		# More freeze frame requesting?
21550:18:41:05.805 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 5 20 21		# Same  response as above, except
21554:18:41:05.852 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF	#  for 04-05 in request and response

21588:18:41:05.945 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 1B 0 0 0 0		# As above, except 04 -> 1B
21591:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 1B 20 21
21592:18:41:05.945 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21595:18:41:05.945 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21630:18:41:06.039 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 0 0 0 0 0		# As above with 04 -> 00
# First frame missing / out of order?
21636:18:41:06.086 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21670:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 9 20 21		# Part of as above with 04 -> 09?
21673:18:41:06.179 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 3A 64 FF

21703:18:41:06.273 -> Fltr: 4 ID: 0x784 Len: 8 Data: 0x3 17 D1 8 0 0 0 0		# As above with 04 -> 08
21707:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x10 C 57 1 D1 8 20 21
21708:18:41:06.273 -> Fltr: 5 ID: 0x784 Len: 8 Data: 0x30 0 0 0 0 0 0 0
21710:18:41:06.273 -> Fltr: 4 ID: 0x785 Len: 8 Data: 0x21 EF FF FF 29 FF FF FF	# except last 2 bytes different

783
18:41:11.752 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x23 20 20 0 0 0 0 0			# Don't know what to make of this; data missing?
18:41:11.845 -> Fltr: 5 ID: 0x783 Len: 8 Data: 0x5 58 1 D1 16 60 0 0			# $5-2 = 3 bytes real data

coulomb · Jul 12, 2023

I'm thinking that service ID 0x17 may be the way to extract the all-important On Board Charger internal diagnostic code (e.g. 01 = Output voltage abnormal, listed in this post).

In this post Paul was presumably choosing some sort of "freeze frame" or "data list" option after obtaining the list of trouble codes.

He first sent a 04 18 ... command to query the trouble codes, and it returned a list of trouble codes with a one-byte status for each ($20 in every case).

Then there was a 03 17 Dx xx... (last 3 hex digit varies) for each of the trouble codes that were returned by the $18 command. In each case, 10 bytes were returned. The first three of these bytes are the encoded DTC (two bytes) and the one byte status returned by the $18 command. All the responses were identical (apart from the encoded trouble code), except for the very last response (D1 08 representing U1108) where the last two bytes were FF FF instead of 3A 64 for all the others.

When you read up on freeze frame data, the answer is usually framed about internal combustion engines (sigh). For EVs, when you query say the BMS or OBC, presumably you get data related to the battery or charging.

So when I get a P1A12 ("On board charger abnormal stop"), I'm thinking that an 03 17 1A 12 command would in effect say "Give me freeze frame data (i.e. more detail) on the P1A12 trouble code", and that could well include the internal diagnostic code that I've been chasing. The only question is which CAN ID (i.e. which ECU) do I send this command to? OK, the second question would be where in the many bytes of freeze frame data is the internal diagnostic code, if it's even present, but hopefully it will be easy enough to spot. I don't mind trying all possibilities. Plus I can compare the results between a working charger and a faulty one.

Kiev or Piev, any clues on the OBC PID? I know it reports data on 0x389, but that doesn't mean that it will respond to commands on that CAN ID, or even as I slightly suspect the one before (0x388).

I had no success today replicating your queries using the Serial Bluetooth Terminal program. But I'm very rusty on sending those commands, and I suspect I just needed to add the length byte before the sub-function ID (like 1A 9C). [ Edit: On further reading, I see that the ELM327 in an OBD2 dongle will add the length byte automatically. ]

kiev · Jul 12, 2023

For the gasoline cars the spec indicates that there is a top level Service Mode Request $01 with Parameter ID (PID) $00 that can be sent to a standard CANid $7??, this is a request for the Addresses of all the ECUs on the buss.
The response for this is supposed to be the available ecu Addresses (and there is a standard list of those as well).

i don't know if this would work with the miev or what the top level CANid might be to request, because the "standard Addresses" don't seem to ever be used for electric cars (miev and PHEV Outlander); and likely the MG also uses nonstandard ecu addresses?

coulomb · Jul 12, 2023

kiev said:
there is a top level Service Mode Request $01 with Parameter ID (PID) $00 that can be sent to a standard CANid $7??, this is a request for the Addresses of all the ECUs on the bus.

Ah, that would probably be $7DF, mentioned in the ELM327 datasheet. Worth a try, at the very least. Thanks!

Edit: I've just noticed that the MG ZS EV does use $7DF as a broadcast address. Service/PID 22F183 returns a sort of ID string for each ECU, and 22F194 returns a firmware version number.

CAN Buss, MUT, and SAE J2534 Pass-Through Programming of ECUs

Help Support Mitsubishi i-MiEV Forum:

Moderator

Moderator

Moderator

Moderator

Moderator

Moderator

Moderator

Moderator

Moderator

Well-known member

Well-known member

Moderator

Moderator

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Moderator

Well-known member

Similar threads

Join the conversation!

Join today and get all the highlights of this community direct to your inbox. It's FREE!