Here I am

Loss of ODB2 Port network connection, I think it's a TIPM problem

Attention: TDR Forum Junkies
To the point: Click this link and check out the Front Page News story(ies) where we are tracking the introduction of the 2025 Ram HD trucks.

Thanks, TDR Staff

Coolant pressure test kit recommendations

Thinking of selling, anyone else sell/trade a high-mileage 05?

Status
Not open for further replies.
Ok, so after 2 re-flashes I finally got my other project complete and did some driving today, first one hour trip all seemed well... Hoping for the best, but knowing it was not likely I had found the fix. Sure enough, on the way back maybe 10 minutes in. All OBD2 connected devices were no longer seeing the ECU.

Kept the truck running when I got home, so I could connect with the wiTech and see what was happening with communications on the network. Once again, it was the ECU that apparently decided to stop communicating. What remains weird, is that the other computers are not setting a code for failure to communicate to the ECU.. and the Wireless control module had a stored code for failure to communicate with the TIPM! What a mess. Screen shot of what wiTech displays attached.

Now it appears to be an ECU problem, however.. I'm wondering if there was some type of network glitch that set the loss of TIPM to the WCM, that perhaps made the ECU go into a CAN off state to protect itself? The truck ran perfectly fine, no MIL lights, and great MPG the entire time, as it has been doing for years.. it's a truly bizarre situation.

wiTech Screen shot no ECU comms.JPG
 
Found this article, apparently CAN does have a "off mode" where a computer that is transmitting bad signals can be eventually turned to mode off for the network.. that sounds like it could be what is happening to the ECU.. and perhaps it has something to do with odd DTCs over the years. Maybe the WCM loss of TIPM was due to the bad traffic on the network BEFORE the ECU went to "off mode". Just thoughts on this, the article is interesting.

https://www.kvaser.com/about-can/the-can-protocol/can-error-handling/
 
Based on the witech topography was the truck running at the time the ECM was offline? If it was running normally as you say then that's a witech glitch not anything going on with the ECM. If the truck is already running and the ECU goes offline the truck should continue to run because all the inputs to keep it running or hardwired. However if the module was offline and you shut it off it wouldn't restart because it has to communicate with the TIPM to allow the starter to engage.
 
Based on the witech topography was the truck running at the time the ECM was offline? If it was running normally as you say then that's a witech glitch not anything going on with the ECM. If the truck is already running and the ECU goes offline the truck should continue to run because all the inputs to keep it running or hardwired. However if the module was offline and you shut it off it wouldn't restart because it has to communicate with the TIPM to allow the starter to engage.

The truck was running for that screenshot, but it's not a simple wiTech issue... because absolutely no scan tool or OBD2 device can communicate with the ECU when it goes off-line to the network. That has been the issue all along, but I thought in the OP that the TIPM was shutting off the OBD2 DTC connector... I know now that is not the case, since I can get to ALL other devices on the network, just not the ECU. This screen shot is very much like the other time where I first saw this with the wiTech, that took almost all day with the key on, truck not running, to get the fault to occur.

Also for the read in the screenshot you might see there is no VIN, apparently that typically is provided to the wiTech via the ECU/PCM.. and it wasn't communicating. Now when I ran a report on all ECUs the other devices did show the VIN within them and they were all working properly.

As to the restart, I think you are absolutely correct to say it won't start if the ECU is offline during the start sequence, but that never happens, as I have long noted, I can "fix" the off state ECU condition by shutting off and restarting the truck, which for the ECU is like a reboot. If it goes to off state as I suspect due to hitting it's TX error counter, it resets that to zero during a restart, and thus there is no starting issue.. but you got me thinking! I need to do another all day on key, and see if it will act up, and then try to start.. most likely that will not happen.. but an off and on with the key, and it "fixes" it.

It's a strange situation indeed, but I'm now pretty sure the ECU swap is the next major attempt to fix the problem.. once I get it and can flash the ECU I have on order... that will be an adventure in itself, I'm sure.

Thanks for the reply.
 
Last edited:
Clearly the ECM is still active when it's in its non-communicative state, since the truck is still running.

Since the ECM is still active when not responding, can you test in any way to see if it is responsive to inputs even though it is no longer transmitting replies?

Can you drop power to only the ECU momentarily and force a reboot while the truck is running? I'm guessing probably not, but who knows?

The comment about asymmetrical CAN signals would suggest a biased reference, have you checked and cleaned all the grounds? You've got 120 pins on your ECM, there are probably more than one of them that is supposed to be going to ground. I wonder if one or more of these grounds might be compromised somehow?
 
Clearly the ECM is still active when it's in its non-communicative state, since the truck is still running.

Since the ECM is still active when not responding, can you test in any way to see if it is responsive to inputs even though it is no longer transmitting replies?

Can you drop power to only the ECU momentarily and force a reboot while the truck is running? I'm guessing probably not, but who knows?

The comment about asymmetrical CAN signals would suggest a biased reference, have you checked and cleaned all the grounds? You've got 120 pins on your ECM, there are probably more than one of them that is supposed to be going to ground. I wonder if one or more of these grounds might be compromised somehow?

The wiTech can not send any commands to the ECU/PCU as it is not in communication, in fact when connecting it tries to obtain the VIN from the ECU, it does not respond.

Correct the truck still runs, and I do believe that is the fail-safe condition. What is odd, rarely any DTCs are set, and no CEL/MIL, then again to even set a MIL the ECU has to communicate via the TIPM to the CCN to illuminate that on the gauge cluster, I'm pretty sure the inability to communicate makes that not possible.

I think it's impossible to do a running engine reboot, the way that is done is a cycle off and on, which of course shuts off the engine. The ECU on a modern vehicle is critical to the engine running, it controls the injection cycles.

I've checked all the connections and the noise on the line seems a bit much, but in order to be sure it's a real issue I'd really need to compare to another truck, using my much newer car with 29bit CAN, vs. the 11 Bit on the Truck might not be a fair comparison. while I think it's excessive, I'm only guessing, in part because I know there is a problem.

That said, with the ignition on, engine not running, I did unplug the engine harness and could not see much of a difference on the types of signal patterns on the bus. I was hoping I could find what computer might be making the noise, and narrow the problem. Absent that I have to look for other indicators, and since the only computer that is not communicating when the problem comes up, is the ECU, the others are talking and I can do actuation commands from the wiTech to verify it.
 
Hopefully this might help. I was working on a 2014 1500 yesterday that had similar symptoms, would not start on occasion. We finally caught it broken and wiTECH showed no VIN, and PCM was off line. We are thinking we have a n open or partial open on one of the CAN legs. Here are a couple of screen shots from a presentation we had in Detroit several years ago that shows normal and one leg open BUS messages.
upload_2020-7-9_8-47-44.png



Notice that the colors split right at the 2.5v line. That is because one leg is positive, the other is negative or mirror image.

upload_2020-7-9_8-50-55.png


This is a faulted signal with one leg dropping out. Notice how the colors are biased up past the 2.5v line. When one leg is open to a module the voltage gets "pulled" up because the voltage is slightly higher on one side of the BUS.
 
Here is another shot, you can clearly see the color shift of the traces are above the 2.5v line.

Thanks for the images.. I wasn't able to grab them from the O-scope I was using, though I did get a couple of printouts. I didn't see the faulted signal in your images, what I saw looked mostly normal, though I also have a 3rd trace that was the additon of CAN H and CAN L, and since they are supposed to be mirror images, in the opposite direction, the addition should yeild a straght line.. which is sort of was, but there were some spikes during transmission above and below in the addition line on the scope.

When I did same on my 2018 Cruze, there was very little variation on the addition line, the signal was much cleaner thatn what I observed on the truck.. It could just be the 9 year newer computer technology on the Cruze that is to blame, really a scan on another truck of same generation would be a better comparison, but I did not have one availible to scan.

At this point I'm on hold waiting for that used ECU to arrive on it's slow boat from China... Once I get it I'll be looking to get it flashed and programmed.. then installed to see if the situation is in fact an internal communication issue with the ECU, I'd say something like the network interface card for a PC, but in this situation inside the case of the ECU. It's a bit of a guess on my part, but that is the only thing that seems to fit with problems I'm seeing.. At least I'm hoping that is it. This has been quite the saga.

Were you able to scan the CAN signals yet on the troubled Ram 1500 you are working on with an O-Scope? It will be interesting to see if it has a similar issue. Also, on mine a key off, then on seems to always correct the situation, from what you are saying sounds like not always effective in your case. I've not as yet had a non-start issue, and hopfully won't! I plan to take a trip with the truck soon and certainly don't want that to be a problem.
 
No I haven't had a chance to look at it with the oscilloscope. He was going to take the truck to Tahoe and hopefully he made it okay. I was going to play with it a little bit on my truck because the oscilloscope that I purchased is a little difficult to set up, not anywhere as easy as the ones we had when I was working.
 
And just to clarify the can messages should be mirror image of each other for a good signal. There should be no stray tails and they shouldn't really be too fuzzy, assuming that you're oscilloscope is set correctly and isn't making it look fuzzy
 
Still waiting on the ECU, that supposedly cleared customs but is taking some crazy time to get in the US mail.. but in the mean time the isssue persists, with a new twist. Cruise control stopped working! It makes sense it would, but what does not make sense, most of the time it continues to work without issue. On my weekend trip it would not engage cruise control, so I stopped and did an engine restart and it began working again. No lights, though I should probably do a scan tomorrow to see what stored codes could be waiting for me there. In later drive cycles the ECU stopped communicating, as is now the "normal" for my truck, but all other times the cruise control continued to work. It truly is bizzare.
 
Finally got the ECU.. it has a few minor dings, but it appears not compromsied. This weekend I'll look into trying to install it and getting it programmed.. more on this saga is coming when I give that a go.
 
Finally got the ECU.. it has a few minor dings, but it appears not compromsied. This weekend I'll look into trying to install it and getting it programmed.. more on this saga is coming when I give that a go.

I’ve been following this thread, all the while hoping this never happens to me. I’d have to sell my truck and get a different one being I don’t have
the diagnostic abilities that you guys do. I hope that ECM works out for you and you get this figured out.
Good Luck!
 
OK, Learning curve and the now normal computer glitches... a bit of trial and error.. and I'm ALMOST done with the ECU swap. Last step needs the PIN that I have to get from the dealership, could not get there in time today, so it will have to wait until Monday.

Before going through that hassle, I thought I'd plug in the new (used) ECU and verify it actually works. It appears is it fully functional, from what I can tell so far.

I plugged it in, brought up wiTECH, renewed my subscription, giving FCA another $70.. and made the connection. Now I was able to get data off the original ECU in offline mode, basically the only thing you need to be connected for is flash programming...

That said, I expected this would need a flash, and it did. My original ECU is serial number 4340, the used one is serial number 9, yep, NINE, but if it works it should not matter, interestingly the used one has a date mark only a couple months from the the date on the original, assuming that is a date mark.

In any case, the instructions are not very intuitive, but they do get you there. The injector codes need to be copied from the original ECU, the other method says you can get them off the injectors themselves, which sounds easy, until you try to find these numbers.. good luck with that. I could not find them, and I assume some disassembly might be required to see these.

In any case, the wiTECH can get you there, but you can only see them in the misc functions where you would go to program them, before you enter a number it shows the current, and I did a screen capture and printed that out, so I could use it in the swap ECU.

I also had to enable the proper configuration and options, Exhaust Brake enable, PTO idle up enable, and the add on water in fuel sensor with the extra filter kit.

Since I don't yet have the PIN, I found I could manually enter the VIN in the replacement ECU.

I'm down to only the SKIM Secret Key code not stored in ECU error code (P0633), to fix that you go to the WCM and do the replacement ECU function, where it requires you to enter the PIN from the Dealership. That should be the last step, but I did a long network communications test, leaving the ignition on, and with my 13.4V power supply (I can show anyone who wants to make one how to do so for $20 from a 30A power supply you can get on Amazon). Keeping the voltage constant during any programming is mentioned many times in the procedures, so I'm assuming that is for a reason, and thus take it seriously.

No network communication errors! Now the saga is not over yet, the proof will be several drive cycles and trips.. if the ECU stays in comms with the UG, I'll call it a complete success. If not, well I'm not really sure what it could possibly be.. hopefully I won't be going there!
 
Whatever you do, do NOT erase the P0633 code. You get rid of it by following the replacement procedure and it will go to stored by itself, then it can be erased once truck is running and your all done.
 
Whatever you do, do NOT erase the P0633 code. You get rid of it by following the replacement procedure and it will go to stored by itself, then it can be erased once truck is running and your all done.

Thanks, good to know. I now have the code and will be hooking up soon to finish the process.
 
Last edited:
Ok, ECU all programmed, Truck runs, no DTCs. Now it's time for a test drive. Seems the used ECU I got actually works. Also, when sorting service records, I came across the first indication of an issue with the original ECU, when the truck had barely 7000 miles! It was an implausible U1421 code that is applicable to an auto transmission truck. There other odd codes over the years, some U-codes. This is what led me to first suspect TIPM, but it now seems almost certain it was always comms problems from the ECU.

IMG_20200810_104321648.jpg
 
Too good to be true. While the replacement ECU seems fully functional.. I get the SAME issues that existed with the original. The ECU becomes non-responsive via the DLC/OBD2 connector. I just shut off at some random time after running for a time.. sometimes a short time, other times stays on for even a long drive.. just as it die before! I got only one stored DTC, from the WCM for loss of comms to the TIPM.. just as before.

I'm at a loss.. seems all that is left is some other module, but with CAN protocol that seems very unlikely. Could have have a second bad TIPM doing the same as the original? Seems the odds of that are super small. Could there be a wiring issue between the ECU and TIPM, perhaps.. but HOW DOES CRUISE control still work!! Seems that would need communications.. I don't have other modules saying no communication to ECU.. which SHOULD be there if the comms to ABS and other modules was cut off.. seems the only place comms are cut are the TIPM.. going right back to where all this began.

It's crazy, and I'm not sure what to do next, but at least I now have two fully functional ECUs, and I got the spare at a good price.. I guess that is a plus.. but I'm not sure what to do next.

U0141 SAME DTC AS WITH OLD ECU.JPG


LOSS OF COMMS TEST NO ECU RESPONSE.JPG


POST ECU SWAP NON RESPONSIVE ECU-PCU SCREENSHOT.JPG
 
Oh man, that feels so bad.
As an idea, did you try to run it with other CAN Moduls disconnected to check if one of these is pulling the BUS down?
I mean aside from TIPM and ECM that are needed to run the engine at all.
 
Status
Not open for further replies.
Back
Top