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

[kiev]

From looking at the FSM it seems that the EV-ECU holds the DTC codes. It is not clear to me if the MUT talks directly to the OBC to get the trouble codes, or if it is the EVECU that is passing thru the codes that were sent from the OBC.

Here are some results from Paul's attempt to query the OBC and MCU using his version of the MUT software and the Tactrix Openport as VCI. i have added some notes after the ;

I did a test. It says communication error when I try and read DTC's from the OBC. Maybe my version of MUT doesn't support that.

OBC  ; the CANid appears to be 0x766, asking for freeze frame data
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 87 0 0 0 0 0  ; SM$02 Pid $1A FRNO $87
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0  ; FRNO $9C
Fltr: 5 ID: 0x766 Len: 8 Data: 0x3 7F 1A 11 FF FF FF FF  ; Response

MCU   ; possible response from address 0x7E0 ?
Fltr: ? ID: 0x18DA15F1 Len: 8 Data: 0x3 22 F1 90 0 0 0 0 ; this is a standard 29-bit Address per SAE sending a 3-byte request to ECU at address $15, 0x22 may be a code related to negative responses called out in specs,  xF1 90 ?
Fltr: 5 ID: 0x7E0 Len: 8 Data: 0x2 1A 90 0 0 0 0 0 ; Response

 

[coulomb]

From looking at the FSM it seems that the EV-ECU holds the DTC codes. It is not clear to me if the MUT talks directly to the OBC to get the trouble codes, or if it is the EVECU that is passing thru the codes that were sent from the OBC.

This post showed requests for DTCs going to and coming from the BMS, so not all DTC information comes from the EV-ECU.

OBC ; the CANid appears to be 0x766, asking for freeze frame data
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 87 0 0 0 0 0 ; SM$02 Pid $1A FRNO $87
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0 ; FRNO $9C
Fltr: 5 ID: 0x766 Len: 8 Data: 0x3 7F 1A 11 FF FF FF FF ; Response

I agree that this looks like the ECU at $765/6 does not support these PIDs.

If this is truly the OBC ECU, then it looks like the OBC posts things like battery voltage and current on $389, yet responds to OBD2 commands on $765/$766. It's quite possible that the gateway is translating the IDs on one CAN bus to different IDs on the OBD2 CAN bus. It may well also be translating the message contents. [ Edit Aug 2023: I no longer believe that there are separate CAN buses, so address and data translation is not possible. ]

MCU ; possible response from address 0x7E0 ?
Fltr: ? ID: 0x18DA15F1 Len: 8 Data: 0x3 22 F1 90 0 0 0 0 ; this is a standard 29-bit Address per SAE sending a 3-byte request to ECU at address $15, 0x22 may be a code related to negative responses called out in specs, xF1 90 ?
Fltr: 5 ID: 0x7E0 Len: 8 Data: 0x2 1A 90 0 0 0 0 0 ; Response

Interesting. It looks to me that the 22 F1 90 sent to 18DA15F1 was translated by a gateway ECU (probably EV-ECU) into a command sent to $7E0 (in a standard vehicle, this is ECU0, which might well be the gateway). This command is 1A 90, which we have seen before sent to $751, and $752 responded with the VIN number. So I wonder why in this case it got sent to $7E0.

It looks like the response, if any, didn't make it through filter 5. Is ID $785 in that filter? I believe that a standard vehicle responds to CAN ID $7E0 on ID $788.

 

[kiev]

Piev has discovered a Volume 3 of the J1979 , December 2022, written to cover Zero Emissions Vehicles, ZEV. There is also a new emissions OBD system defined in J1979-2, called OBDonUDS (Unified Diagnostic Services). The old system is referred as J1979-1. In addition there is Diagnostics over IP, which i'm fairly sure none of this would apply to mievs.

Not sure if these standard/regulated protocols were used in our cars from 2012, but here are some excerpts:
6.6 SAE J1979-3 Diagnostic Service Requirements
6.6.1 Protocol Detection
The following ZEV propulsion systems protocol check (SAE J1979-3) is performed in conjunction with existing ISO 15765-4 (SAE J1979-1) and ISO 14229-1 (SAE J1979-2) protocol checks.
The ZEV propulsion systems protocol check confirmation is done by:
1. First, perform a functional request of DID 0xF810 on DoCAN using the ISO 14229-1 protocol. If one or more positive responses are made, then the vehicle is confirmed to be regulated DoCAN (ISO 14229-2) protocol compliant.
a. After a positive response to DID 0xF810, perform a physical request of DID 0xF41C to determine the regulated ZEV market (for example (Heavy Duty ZEV = 0x1B).
2. Then, if no positive responses from step one are received, then further confirmation is accomplished by:
a. Perform the DoIP activation line process to determine which DoIP option the vehicle Ethernet line supports.
b. Once determined, perform functional request of DID 0xF810 on DoIP using the ISO 13400-2 protocol. If one or more positive responses are made, then the vehicle is confirmed to be regulated DoIP (ISO 13400-2) protocol compliant.
c. After a positive response to DID 0xF810, perform a physical request of DID 0xF41C to determine the regulated ZEV market (for example, Heavy Duty ZEV = 0x1B).
Notes:
1. The tool will stop further protocol determination checks when it gets a first positive response from the vehicle’s ZEV propulsion system.
2. This specification requires that all ZEV ECU Servers must support the same datalink, which is specified as either DoCAN (ISO 14229-1) or DoIP (ISO 13400-1).
3. A ZEV propulsion system compliant vehicle shall not acknowledge support of ZEVonUDS using a mix of communications using both DoCAN and DoIP protocols. The vehicle shall only respond to DID 0xF810 on the DoCAN (ISO 14229-2) protocol or the DoIP (ISO 13400-2) protocol. After vehicle identification, the tool will only seek information from a vehicle either on the DoCAN or the DoIP protocols. Furthermore, once the tool establishes communication to the vehicle using ZEVonUDS, the supported services on other protocols becomes outside the scope of this document.
4. If multiple vehicles are available on a subnet, the tool shall ensure each server is paired to the appropriate vehicle on the network. Each DoIP server shall have a VIN in the Vehicle Identification response that accurately represents the responding vehicle. Refer to ISO 13400-2 for guidance.

Section 8
8. ADDRESSING SCHEME
ECUs are capable of being addressed by either functional address (broadcast) or physical address (point to point).
The ECUs are required to support all requests by functional and physical addressing. Exceptions are defined in 8.3.
8.1 Functional Addressing (DoCAN)
Functional addressing is used for three main use cases:
8.1.1 Protocol Identification
The Client sends a functionally addressed service $22 $F810 request and builds a list of all ECUs responding to that request.
8.1.2 Identify the vehicle
The Client sends a functionally addressed service $22 $F802 request to get the VIN from the vehicle.
8.1.3 ClearDTCs
The Client sends a functionally addressed service $14 $FFFF33 request to clear all DTCs in the vehicle.
P2Reload ensures that the Client will get all functional responses but they may not be received within P2Client=50ms. (the P2's relate to signal Timing)

 

[kiev]

Comparison of old and new (UDS) Service Modes, may apply to newer EVs

 

[coulomb]

Here are some results from Paul's attempt to query the OBC and MCU using his version of the MUT software and the Tactrix Openport as VCI. i have added some notes after the ;

I did a test. It says communication error when I try and read DTC's from the OBC. Maybe my version of MUT doesn't support that.

OBC ; the CANid appears to be 0x766, asking for freeze frame data
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 87 0 0 0 0 0 ; SM$02 Pid $1A FRNO $87
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0 ; FRNO $9C
Fltr: 5 ID: 0x766 Len: 8 Data: 0x3 7F 1A 11 FF FF FF FF ; Response

What evidence is there that the OBC is at 0x765 (OBD commands) and 0x766 (OBD responses)?

I had another play yesterday and it seems that you have to talk direct to the ECU (e.g. at 0x761 for the BMU), not 0x7E0. Though I see that I forgot to try 0x7DF, sigh. So if we got the CAN ID for the OBC wrong, that would explain the lack of success.

 

[piev]

What evidence is there that the OBC is at 0x765 (OBD commands) and 0x766 (OBD responses)?

The evidence is that when I click the radio button in MUT3 SW labels OBC it sends the command to 0x765. And the response is from 0x766. When I click the EV ECU button it sends it to 0x751.

 

[coulomb]

The evidence is that when I click the radio button in MUT3 SW labels OBC it sends the command to 0x765.

Ok, that's pretty good evidence, thanks.

And the response is from 0x766.

What responses have you seen in 0x766?

 

[piev]

What responses have you seen in 0x766?

None, it gives me a comm error

 

[coulomb]

From looking at the FSM it seems that the EV-ECU holds the DTC codes. It is not clear to me if the MUT talks directly to the OBC to get the trouble codes, or if it is the EVECU that is passing thru the codes that were sent from the OBC.

This post showed requests for DTCs going to and coming from the BMS, so not all DTC information comes from the EV-ECU.

OBC ; the CANid appears to be 0x766, asking for freeze frame data
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 87 0 0 0 0 0 ; SM$02 Pid $1A FRNO $87
Fltr: 5 ID: 0x765 Len: 8 Data: 0x2 1A 9C 0 0 0 0 0 ; FRNO $9C
Fltr: 5 ID: 0x766 Len: 8 Data: 0x3 7F 1A 11 FF FF FF FF ; Response

I agree that this looks like the ECU at $765/6 does not support these PIDs.

If this is truly the OBC ECU, then it looks like the OBC posts things like battery voltage and current on $389, yet responds to OBD2 commands on $765/$766. It's quite possible that the gateway is translating the IDs on one CAN bus to different IDs on the OBD2 CAN bus. It may well also be translating the message contents. [ Edit Aug 2023: I no longer believe that there are separate CAN buses, so address and data translation is not possible. ] [ Edit Sep 2023: I read elsewhere that from 2015 onwards, the charrger and BMU etc are on a separate CAN bus from the rest of the car and the OBD-II connector. ]

MCU ; possible response from address 0x7E0 ?
Fltr: ? ID: 0x18DA15F1 Len: 8 Data: 0x3 22 F1 90 0 0 0 0 ; this is a standard 29-bit Address per SAE sending a 3-byte request to ECU at address $15, 0x22 may be a code related to negative responses called out in specs, xF1 90 ?
Fltr: 5 ID: 0x7E0 Len: 8 Data: 0x2 1A 90 0 0 0 0 0 ; Response

Interesting. It looks to me that the 22 F1 90 sent to 18DA15F1 was translated by a gateway ECU (probably EV-ECU) into a command sent to $7E0 (in a standard vehicle, this is ECU0, which might well be the gateway). This command is 1A 90, which we have seen before sent to $751, and $752 responded with the VIN number. So I wonder why in this case it got sent to $7E0.

It looks like the response, if any, didn't make it through filter 5. Is ID $785 in that filter? I believe that a standard vehicle responds to CAN ID $7E0 on ID $788.