JEEP HACKING CAN-C / CAN-IHS / UDS ! (Reverse Engineering)

[redracer]

$00??xx???xxxx – PS pressure in PSI

Oops...

I believe it's this one...
$00??xx??????

Tho, I'm not 100% sure it's psi. It does behave like it, but the numbers are way too low so the math is off. I have been watching the other to figure it out. The other thing that this could be is amp draw, which i did see as a live value on jscan.

Here is something I found on another forum about an earlier charger that had EHPS...

MODULE, Electro-Hydraulic Power Steering (EHPS)

• Diagnosis and Testing
  • C1587-16-POWER STEERING MOTOR INVERTER POWER SUPPLY - CIRCUIT VOLTAGE BELOW THRESHOLD
  • C1587-17-POWER STEERING MOTOR INVERTER POWER SUPPLY - CIRCUIT VOLTAGE ABOVE THRESHOLD
  • C15A4-00-POWER STEERING ASSIST INHIBITED-VEHICLE SPEED TOO HIGH
  • C211B-00-IGNITION RUN/START INPUT
  • C211B-11-IGNITION RUN/START INPUT - CIRCUIT SHORT TO GROUND
  • C211B-12-IGNITION RUN/START INPUT - CIRCUIT SHORT TO BATTERY
  • C2128-00-ECU RESET/RECOVERY OCCURED
  • C212A-84-SYSTEM VOLTAGE - SIGNAL BELOW ALLOWABLE RANGE
  • C212A-85-SYSTEM VOLTAGE - SIGNAL ABOVE ALLOWABLE RANGE
  • C2206-00-VEHICLE CONFIGURATION MISMATCH
  • C220D-00-ELECTRICAL POWERED HYDRAULIC STEERING MODULE INTERNAL
  • C2210-00-ECU OVERTEMPERATURE
  • C221F-00-ECU NOT INITIALIZED
  • U0002-00-CAN C BUS OFF PERFORMANCE
  • U0100-00-LOST COMMUNICATION WITH ECM/PCM
  • U0121-00-LOST COMMUNICATION WITH ANTI-LOCK BRAKE SYSTEM (ABS) CONTROL MODULE
  • U0126-00-LOST COMMUNICATION WITH STEERING ANGLE SENSOR
  • U0140-00-LOST COMMUNICATION WITH BCM
  • U0155-00-LOST COMMUNICATION WITH CLUSTER/(IC)
  • U0401-00-IMPLAUSIBLE DATA RECEIVED FROM ECM/PCM
  • U0415-00-IMPLAUSIBLE DATA RECEIVED FROM ABS
  • U0428-00-IMPLAUSIBLE DATA RECEIVED FROM STEERING ANGLE SENSOR MODULE
  • U1601-00-ECU APPLICATION SOFTWARE CODE 1 MISSING OR CORRUPTED
  • U160B-00-ECU BOOT SOFTWARE 1 MISSING OR CORRUPTED

1. NOTE:

   Always test for and repair Diagnostic Trouble Codes (DTCs) prior to replacement of the EHPS pump. The EHPS pump will not vary output if there are communication DTCs.

2. Record the flow meter reading (GPM) at idle with no steering wheel movement, and again while turning the wheel as fast as possible. The readings should be within specifications. If the readings are below specifications, replace the power steering pump.
   
   

   CAUTION:

   The following test procedure involves testing maximum pump pressure output and flow control valve operation. Do not leave valve closed for more than five seconds as the pump could be damaged.

3. Close valve fully three times and record highest pressure indicated each time. All three readings must be above specifications and within 345 kPa (50 psi) of each other.
   • Power steering pump pressures above specifications but not within 345 kPa (50 psi) of each other, replace pump.
   • Pressures within 345 kPa (50 psi) of each other but below specifications, replace pump.
4. 
   
   

   CAUTION:

   Do not force the pump to operate against the stops for more than 2 to 4 seconds at a time because, pump damage will result.

5. Completely open the valve on the Power Steering Analyzer. Turn the steering wheel to the extreme left until the stop in the steering gear is met, then turn the steering wheel to the right until the right stop is met. Record the highest indicated pressure at each position. Compare the recorded readings to the specifications. If the highest recorded output pressure reading against one stop is not within 345 kPa (50 psi) of the highest recorded reading at the other stop, the steering gear is leaking internally and must be replaced.

PUMP SPECIFICATION

SYSTEM	RELIEF PRESSURE ± 75	FLOW RATE (GPM)
EHPS	11721 kPa (1700 psi) at idle with no steering wheel rotation.	1.0 - 2.1 GPM at idle with no steering wheel rotation.
EHPS	11721 kPa (1700 psi) turning steering wheel to wheel stops.	Momentarily raises to between 1.5 - 2.5 GPM at idle with rapid steering wheel rotation.

Sponsored

 

[redracer]

RedRacer why did you switch to curses instead of tkinter?

I use curses for my testing framework, as it's easier for me to just throw stuff together.

I'm working on my tkinter for my nice and useable display that I will keep active in the jeep.

 

[jmccorm]

Oops...

I believe it's this one...
$00??xx??????

Tho, I'm not 100% sure it's psi. It does behave like it, but the numbers are way too low so the math is off. I have been watching the other to figure it out. The other thing that this could be is amp draw, which i did see as a live value on jscan.

If it isn't pressure (in kpa's?), then it could be flow rate (like gallons per minute)? I noticed the flow rate being mentioned in the document you provided. I think it may want to keep a constant pressure, and the variable would be the rate of flow?

So the items it mentioned were from a diagnostic self-test procedure. But I'm trying to see if I can figure out what things it might need when it's operating on a normal basis and what things it can't figure out on it's own. Here are some comments --

1. Voltage / Current: It may look to see what an overall system voltage is (we've found at least one voltage measurement on the CAN bus). But the rest of the voltage/current figures (for the pumps, for it's own module) should be something that it can figure out internally and not through an outside CAN bus message.

2. Vehicle Configuration: It may be looking at one of our configuration bitmap messages (unknown which one) to determine if it exists in a vehicle which is supposed to have an electronic power steering pump. If not, it may detect that it's in an invalid configuration.

3. It looks like it's wanting an ongoing stream of messages from these systems: PCM/ABS/STEERING WHEEL and it *might* be looking at least for some initial message from these systems: BCM/EVIC.

This might be a bit of a needle in a haystack unless he can figure out if/where/when the power steering pump flips a bit in it's regular message to signal that everything has gone from "just fine" to "error condition".

If that bit exists in the 0x128 message, and he can identify it, then he can start with the complete list of CAN1 (CAN-C) messages, and exclude message ID by message ID until the only ones he's left with are demonstrably required for it's continued operation. If a needed message disappears, then he'll know because he will have created a fault.

I think things are starting to look more hopeful here.

 

[jmccorm]

Robert --

I started with what you've done with message ID 0x128 and I delineated the boundaries of three new fields. Here's what it looks like now:

POWER STEERING PUMP​

​

$00xx???????????? – Fluid Temp in C​

$00??xx?????????? – Pressure? or... Flow Rate? Current?​

$00????xx???????? -- Unknown Variable 1​

$00??????xxxx???? -- Unknown Variable 2​

$00??????????xxxx -- Unknown Variable 3​

​

Unknown Variable 1 is almost static.​

Variables 2 and 3 will range up/down during a drive.​

There is no field for counter or checksum.​

I know (from personal experience) that the EVIC displays a message when the power steering system is offline. And (from my own experience plus another person's) I know that it can happen when there is noise on the CAN bus. The assumption is that the Electronic Power Steering Module detects a fault and shuts itself off. But then when the Power Steering Module shuts down, the driver is immediately notified of it.

That would suggest that the power steering module would either have to send a 0x128 message saying that there's a fault, or it could send a 0x128 message with invalid values, or it could send a completely different message ID that we haven't been told about, or the power steering module could simply stop sending messages altogether. Or there could be some out-of-band communications going on.

I think we're going to have to rely upon @Tristan to help us define a way that normal vs faulted behavior of the Electronic Power Steering Module can be detected via CAN bus messages. That's going to be the key to unlocking what it does and doesn't need to operate.

But it looks like we've got three new mystery variables that you might be able to help decode for us! It might be worth knowing that (if I understand the docs you provided correctly) the system pressure should be in the neighborhood of 11721 kPa (1700 psi). But that may just be a relationship that only exists during module testing.

 

[jmccorm]

U0121-00-LOST COMMUNICATION WITH ANTI-LOCK BRAKE SYSTEM (ABS) CONTROL MODULE

An open question to anyone --

Would you happen to know (or suspect) what relationship exists between the Electronic Power Steering Module and the ABS system? Why would the Power Steering Module regularly need to know something from the ABS system? And what?

 

[redracer]

To find hints about the mystery values, I will post a screenshot of the jscan live data output for the electric power steering module. ... After dinneriwas looking at it on my way to dinner. There is lots of variables that are from the can bus, like speed and steering angle

 

[redracer]

Screenshots

 

[jmccorm]

Fantastic! That does a very good job of telling us what other CAN messages it's looking for (some we've identified, others are unclear).

Based on the rest of what you've provided, here's my guess for the Value 2 and Value 3: EPS Commanded Motor Speed, EPS Measured Motor Speed (not necessarily in that order). You wouldn't happen to be able to eyeball those numbers and see if that might fit, would you?

If so, also see if Module Temperature is plausible for Value 1.

 

[jmccorm]

An open question to anyone --

Would you happen to know (or suspect) what relationship exists between the Electronic Power Steering Module and the ABS system? Why would the Power Steering Module regularly need to know something from the ABS system? And what?

Robert --

I do believe you provided the answer to this one! It's either going to be IOD Fuse Out or Vehicle speed. I'm not sure about IOD Fuse Out, but a wheel speed sensor multiplied against the configured tire size would allow the ABS system to determine MPH.

 

[jmccorm]

Robert --

I'm not in much of a position to track down faults right now, but there's a bug in my existing wake script:

#!/bin/bash
#
# This script is designed to wake up the CAN bus by simulating the
# press of a fictitious center dash button. A random number is
# used to help avoid the ECU interpreting this as a stuck button.
#
FAKE=$(printf "%x" $(( $RANDOM & 15 )))
cansend can0 2D3#07000000000000${FAKE}0

I need to replace it with the earlier version, which was this...

#!/bin/bash
cansend can0 2D3#0700000000000000

If seems that one or more combinations of the following message will inadvertently TURN OFF the uConnect radio. Not a severe bug in the grand scheme of things, but it's unexpected behavior from a script that you just expect to wake up the CAN bus with a throwaway button press.

Here's what it ends up sending:

can0 id 0x2D3 0x07000000000000x0​

So we'll just go back to sending this instead until I have time to sort it out...

can0 id 0x2D3 0x0700000000000000​

 

[redracer]

If seems that one or more combinations of the following message will inadvertently TURN OFF the uConnect radio. Not a severe bug in the grand scheme of things, but it's unexpected behavior from a script that you just expect to wake up the CAN bus with a throwaway button press.

Hmm, that's interesting.

That's close to something that I want to accomplish. I want to figure out the command to cause the uconnect radio to reboot. I see that the UDS page does talk about this, but I have not quite figured that out yet.

 

[jmccorm]

That's close to something that I want to accomplish. I want to figure out the command to cause the uconnect radio to reboot. I see that the UDS page does talk about this, but I have not quite figured that out yet.

This may be a situation like the script to honk the horn where you have to go into an elevated mode before you can actually issue the command you want.

So... up until now, we've been using these two commands:

ReadDataByIdentifier 0x22​

​

Probably the most widely used UDS service, it allows the client to request a piece of data from the ECU using a special moniker (called the data identifier). The data identifier is generally a 16-bit number.​

The type of data can literally be anything (engine speed, software version, board serial number, etc).​

There are no sub-services. Bytes following the Service ID are interpreted as additional data IDs!​

​

​

InputOutputControlByIdentifier 0x2F​

​

Like all the other “identifier” services, this allows the client to identify some I/O on the ECU by a special moniker and control it temporarily – for example, turning on a switch or overriding a PWM signal.​

To reset a module should involve *this* UDS command, which I think is what you're seeing:

ECUReset 0x11​

​

Instructs the ECU to perform a reset of itself, if safe to do so.​

So... a few notes here.

If you're going to try your hand at this command, you've got to be sure to run it against the uConnect radio. In my vehicle, that means you're sending commands on ID 0x7BF and you're listening for responses on ID 0x53F. It's probably going to be the same for yours, too.

It is probably unwise to try to craft the command freehand (based on what you read online from docs). Instead, you should probably copy from known tools. The good news is that you've got both a Tazer and you've got JScan, so either one you could use to *just* reset the radio (and only the radio) and the sift through the traffic to figure out what was what. Tazer will a recent firmware upgrade.

The reason why I really want to stress copying here is that a couple of months ago, a little birdie whispered in my ear that if I go around issuing my own UDS reset commands from scratch, I'm at risk of some very bad things happening (module no longer functioning). Their advice has proven trustworthy. I figured you'd want to be warned as much, too.

Which, BTW, I meant to ask... why are you resetting the uConnect radio? Do you have some configuration changes you want to get it to accept quicker, or...?

It sounds like you may have something very interesting going on! ?

 

[redracer]

Which, BTW, I meant to ask... why are you resetting the uConnect radio? Do you have some configuration changes you want to get it to accept quicker, or...?

It sounds like you may have something very interesting going on! ?

Haha. -insert evil laugh-

Unfortunately it's nothing so interesting. I have found that on long dedicated road trips is when the radio decides to misbehave. usually muting all audio on one channel, or deciding my gps coordinates are another state away. And, unlike the UConnect 8.4 with a way to hold a key combo to cause a reboot, the UConnect 7 does not have a native way to reboot.

So, I just want to program a button on a utilities screen on my tkcan.py for rebooting the UConnect, right along with triggering MAX A/C and temp sync, etc...

 

[jmccorm]

So, I just want to program a button on a utilities screen on my tkcan.py for rebooting the UConnect, right along with triggering MAX A/C and temp sync, etc...

Just to make sure I understand:

The uConnect 7 doesn't reboot because you don't have those buttons, or the uConnect 7 doesn't reboot because you have the right buttons on your center cluster but they don't have any effect?

 

[redracer]

Just to make sure I understand:

The uConnect 7 doesn't reboot because you don't have those buttons, or the uConnect 7 doesn't reboot because you have the right buttons on your center cluster but they don't have any effect?

It's the later. I do have all the same buttons that you do. it's just that the 7 does not respond in the way that the instructions for the 8 describe

Sponsored