When OEM Service Information Leaves You Wanting More

Chris Diagnostician Lansdale, Pennsylvania Posted   Latest   Edited  
Case Study
Heavy Duty
Network Communications
Icc 000677.05
Icc 000110.09
Icc 000190.09
Icc 000247.09
Icc 002000.09
Icc 003719.09
Icc 003721.09
Icc 002003.09
Ecu 522596.09
Ecu 003695.14
Ecu 000110.00
Regen Inhibited
Low Power

This case study is an exploration of finding your way when the OEM SI (service information) is lacking. Machine in question is a 2015 John Deere 3039R, 1,144 hours on the meter, that was in for routine service, some hydraulic leaks, and a complaint of low power. Per my standard procedure I plugged in the EDL (electronic data link) and fired up ServiceADVISOR to take a look at any DTCs. Engine is a Yanmar 3TNV.

Five codes were intially present, three in the ECU and two in the ICC (instrument cluster controller):

  • ECU … - Engine Coolant Temperature Signal Extremely High - 1 count, stored code
  • ECU … - Exhaust Filter Cleaning Inhibited By Operator Interface - 111 counts, stored code
  • ECU … - No CAN Message Received From Source Address 1 - 1 count, stored code
  • ICC … - Engine Starter Motor Relay Current Below Normal or Open Circuit - 3 count, stored code
  • ICC … - Source Address 3 Abnormal Update Rate - 1 count, stored code

As SA (ServiceADVISOR) automatically stores a record of every action i perform I went ahead and cleared out the codes. The only concerning code in my mind was the 111 counts of …, the others could very well have been caused by loose battery terminals (had an aftermarket battery that we hadn't installed), low cranking voltage after sitting for a long period, or a myriad of other things; either way I wasn't concerned as they were stored and all were lower counts. 

I fired the machine up and let it get up to operating temperature while I pulled the engine load profile, one of my favorite pieces of data. As evidenced in the table, the machine has spent the vast majority of it's life at load speed and low load. This leads to wet stacking and rather quick clogging of the DOC/DPF unit. 

Engine was up past the ECT (engine coolant tempt) threshold of 140 F at this point and park brake applied but I could not get the machine to initiate regeneration via the operator station. These machines are fussy at times so I choose to perform a service regen command straight from SA and monitor the data. The regen request failed three times in a row before it finally took and started to burn off soot; I was a bit concerned but had other things to attend to and SA doesn't exactly have a reputation for unwavering reliability. Upon completion of regen I started looking at my standard data PIDs. I noticed something strange there, exhaust filter cleaning inhibit and interlock statuses were both inhibited still. This is important because if the ECU sees these two PIDs as inhibited then the operator/machine will never be able to go through regen without intervention from the factory scan tool. This explains the 111 counts of operator inhibited regen.

These data PIDs should always default to uninhibited. Criteria for inhibition of cleaning is simple:

  • Operator Pressed The Disable Cleaning Switch
  • A DTC is set relating to: Air throttle actuator (position or drive circuit), MAP sensor, MAT (manifold air temp), EMT (exhaust manifold temp), EGR Valve, DOC inlet/out temp sensors, DPF differential pressure sensor
    • No DTCs for any of these systems were set

Criteria for interlock status inhibition is:

  • Park brake off

All criteria was met, disable switch was inactive, no DTC's set related to any of the important engine inputs, and park rake was on {computer saw park brake was on within it's dedicated data PID} yet the data PIDs would not change. After a key cycle, even if the operator disables cleaning, the status defaults to uninhibited to prevent issues. 

I began to research the codes a bit more as well as additional codes that set after regen completed, I won't explain every code in detail, the FMI 09 codes in the ICC all refer to abnormal data update rate for various parameters over the CANbus. The screen shot below is all the data/code set criteria that I'm given. CAN system diagnosis directs one to perform multi-meter diagnosis of the CAN network. The programming control units just refers one to programming procedures as these codes will sometimes set after a programming event, which had not occurred. 

… and … both being set in the ICC let me know that the ICC was functional and just losing communication with the other modules, both codes were also clearly labeled as ECU and TCU not responding. ECU … led to some confusion as there is no call-out for source address 1 in any SI. I needed to know what to do next but I had just hit a brick wall in information. Now what? 

Taking a detour and using previous experience, along with the fact that there was a new software update available for the ICC and SI did call out reprogramming the ECU as a fix for "nuisance" codes. I reprogrammed the ECU and ICC (I chose not to reprogram the PTH as I didn't want to go through re-calibrating the hydro-stat system at this point), hoping that the ECU was just logic locked in it's inhibited state. No change at all. Once again I hit a wall and was starting to doubt my ability to figure this out, there just didn't seem to be enough information on the systems. I took a break and went out to the parking lot to diagnose another machine while I was thinking. Walking away gave me a bit of clarity.

I realized that source address 0 was referring to the ECU based on DTC descriptions and source address 3 is the TCU, the ICC is source address 23. Still not really any further ahead than I was before. This machine only has three control modules ECU, ICC, and PTH (powertrain hydrostatic controller) yet it was calling out a source address that had no documentation. I thought about it as I headed out to a road call that had just come in. The light bulb went on about 5 minutes down the road: CANbus structures message priority so that the lowest number has the highest priority, hence the ECU would be most important followed by the PTH and finally the ICC. So what could take priority between the ECU and the TCU?

How about the EGR Valve? If you read my $1200 EGR valve post then you are already aware that JD/Yanmar loves to use a linear EGR actuator that only receives 4 wires: CAN H, CAN L, 12V, Ground. If a component has CAN lines going to it then it has to have a CAN transceiver and therefore it must also have a network source address to determine origin of messages as well as it's priority in the network. My logic dictated that this must be source address 1. I immediately remembered my previous experience with an EGR valve pulling the network down and so scoped the valve. I don't have a capture saved on this computer, but I assure you it was 100% perfect. Time to stop, breathe, and let my gathered data guide me in the right direction.

What data did I have so far? I knew a few things:

  • My network was functional to some degree as I had the ability to view live data and pull codes
    • EGR, ECU, TCU all stopped responding to the ICC at some point
    • Could never capture a time when the network went down on the scope; never saw any degradation of signal
  • The ICC seemed to be the most stable as it was the only module to never throw an abnormal update rate code
    • The ICC seems to be a gateway module of sorts, though there is no SI to back that up
  • The software is up to date
  • Based on the modules setting codes, the ECU is suspect
  • I haven't checked to see if the ECU was receiving a permanent signal from the regeneration disable switch in the dash (perhaps a short?)
    • Referencing the schematic I saw that the ICC receives the inhibit signal from the regen disable switch
      • Theory of operation didn't dictate what happened to the signal from there, but the only wires connecting the ICC to the ECU are CANbus wires. I theorized that the ICC must receive the signal, convert it to a bus message and send it out to the ECU.
        • This meant that even though the ECU was suspect so was the ICC.

I took a reading at the ICC on the wire for the inhibit switch. It is just a momentary 5V signal to signal change of state and was operating correctly. Since the ECU defaults to un-inhibited one 5V pulse signals it to inhibit and if the button is pressed again the ECU knows to switch back to un-inhibited. That confirmed that the ICC was receiving the signal and that there was not short or open in the wire. 

So is the ICC:

  • not understanding the signal input from the disable switch?
    • Can be eliminated because the ECU should still default to un-inhibited after a key cycle
  • sending the wrong message to the ECU over the bus?
  • sending the right message but the ECU can't understand it?

Unfortunately, the only way to confirm the proper message is being sent, as the signal passes from the ICC to the ECU before changing the state of Cleaning Inhibit PID, would be to use a CAN sniffer (sounds kinda dirty doesn't it?) and a decoder, as well as knowing the proper message structure for that particular message. Situations like these are one of the rare times where I see CAN decoding as being a potentially useful tool.

The next logical step, in my mind, was to go to the ECU and check power and grounds as the ECU seemed to be having the most issues.

I performed loaded power and ground checks and all wires passed with flying colors. No smoking gun here.

JD allows for something called a Donor ECU Swap, or a hail Mary as I call it. I had no smoking gun, but I do have an ECU that is used in multiple different types of machine. I found a service unit on the lot that was the same tractor configuration and engine and pulled the ECU (basically a twin ECU with different injector coding). Generally one would inhale all the data from the suspect ECU and put it off to the side, then connect the Donor ECU and inhale that data into the computer as well. The suspect ECU programming would then be exhaled into the donor ECU. The whole process can then be reversed. I opted not to do this as it's tedious and I wasn't convinced the software was good. When software is loaded, such as during an update, it doesn't erase the old programming and install a whole new program but rather it only modifies the parameters that were changed in the update. I can't prove this but I've seen enough to have very strong suspicions. 

The only potential downside of plugging in a different ECU, besides injector coding not matching, is the VIN security code will sometimes set as the VIN in the ECU does not match the VIN stored in the ICC and PTH. Anyway, I plugged the donor ECU in, keyed on and voila! Problem solved. New ECU is on order and will be programmed with a fresh payload. I'm not sure if there is a hardware or software problem internally in the ECU, though I did check pins and connectors for damage or corrosion but saw no signs of it. Pictures are in the attachments.

Thank you to whoever made it this far, I tried to keep it relatively concise while familiarizing everyone with the equipment and thought processes.

Lessons learned here are as follows:

  • Automotive SI is way nicer to deal with. Things like code set parameters and (sometimes) clearer fault descriptions make the job so much easier.
  • Having good SI is incredibly important but sometimes you can reason your way to the solution, though it may take longer.
  • Don't fit the data to a shotgun/silver bullet/pattern failure diagnosis, allow the data to lead you to the proper diagnosis.
  • If you hit a wall, sometimes walking away for a bit is this best so you can reorganize your thoughts.
    • Unless you actually hit a wall in the customers vehicle, in which case you have bigger fish to fry.
  • Training, experience and critical thinking/logic, aka your brain, are the most valuable tool you have.
+9
Allan Instructor
Winnipeg, Manitoba
Allan
 

Hey Chris nice case study and a very good diagnostic strategy. Use logic to fill in the blanks when S.I. is lacking. Walking away when you hit a wall is good advice. Have done it myself with good results. Being able to swap in a known good ECU was a quick way to verify what you already knew. The real lesson here is - you need to understand the system you’re diagnosing - you were able to put together the pieces of the puzzle missing from S.I. because you had a good understanding of the system. Good job. 

+1 Ð Bounty Awarded
Chris Diagnostician
Lansdale, Pennsylvania
Chris
 

I appreciate it Allan. I'm lucky enough that I can usually get time to play with lots of different equipment and vehicles. I bring a case of beer to one of my contractor customers and they give me all the time I want to get baseline readings, waveforms, and play with some different failure modes. It helps me to help them so it is a win-win.

I find that taking the time to familiarize myself with base concepts and a variety of different systems on a ground floor level definitely helps me to adapt quicker in the field. When SI is lacking I try to go back to "how does the system generally work?" and then extrapolate from there as to how it works in a given situation; it's served me well so far.

+1 Ð Bounty Awarded
Jaxon Technical Support Specialist
Stafford Heights, Australia
Jaxon
 

Morning Chris, another excllent write up, thak you.

+1 Ð Bounty Awarded
Brian Owner
Parma, Ohio
Brian
 

Thanks for sharing. Yes walking away for a bit coming back for more in the morning always a good think (As long as problem does not make me loose sleep)diag​.​net/file/f450njhcs…

+1 Ð Bounty Awarded
Brendan Owner/Technician
Browns Plains, Australia
Brendan
 

Thanks for the case study Chris.

Well laid out logical diag process and well written.

Unfortunately it's a little window into the lack of SI we have on even common vehicles in Australia. We are a technologically forward country but our lawmakers have let us down in this industry. Luckily through the hard work of some of my colleagues we are closing in on the finish line of reaching a R2R agreement similar to what you had in the US years ago - my fear is that while we are finishing one race another one started years ago.

Keep the case studies coming, really enjoy them.

+1 Ð Bounty Awarded
Chris Diagnostician
Lansdale, Pennsylvania
Chris
 

Brendan,

It's good to see that the fight is going on world wide to ensure access to better quality information. There is always another race going on whether we know it or not. Keep up the good up work and I'll try to keep case studies coming in here.

+2 Ð Bounty Awarded
Zachary Mobile Technician
Austin, Texas
Zachary
 

Excellent case study per usual Chris. I know we spoke about it a bit via the comments section of your YouTube video but I enjoyed getting additional details here. As to your educated suspicion that John Deere merely allows modification of parameters during a software update rather than a full rewrite I pose this question: Is there an ECU wipe feature that would allow you to essentially format the original engine controller and program it as if it were brand new? Can you lie to the scan tool in some way to make Service Advisor think it's a new unit? I know with say the Ford IDS for example, you can often install a used ecm that might not otherwise work by leaving the key off when trying to create initial communication with the scan tool. After IDS makes you jump through a couple hoops to try and establish communication, it will then let you provide manual entry of the data. That's when you can turn the key on and input the vin and other applicable parameters as if it were a blank ecm. It's been awhile since I've had access to an IDS so I may be fuzzy on the exact details. I believe that is the gist though assuming my memory hasn't begun to fail me. Anyway, just curious. Thought that might be a way to test the theory of faulty software versus hardware if it's indeed possible to do such a thing. 

0 Ð Bounty Awarded
Chris Diagnostician
Lansdale, Pennsylvania
Chris
 

Zach,

On Yanmar ECU's that is not an option. It is a one and done initial programming event. Short of going board level and doing EEPROM work (in theory, never tried it) I am not aware of a way to "virginize" those ECU's though there are remans available so Yanmar/Bosch obviously have a way to do it relatively easily. I believe it is most likely something to do with either Yanmar's programming or their software licensing to Deere. I know there are issues with loading suspected bad software into a new ECU to the point where they have you go through a special process when programming a new ECU and check off that the old ECU is not available.

For Deere ECU's (also Bosch architecture for the most part) there is a full ECU donor procedure that allows you to inhale and exhale data and then reverse the process after testing. 

I hope that clears it up for you a bit.

+2 Ð Bounty Awarded
Zachary Mobile Technician
Austin, Texas
Zachary
 

It does clear things up. I figured there must not be a way to do that or you would've. 😁

+1 Ð Bounty Awarded