Power of the software update

2017’s Top Technician winner Karl Weaver is back with a piece looking at the importance of staying on top of updates

Published:  06 October, 2020

As I write this (in April), we had just began our fourth week of lockdown and I am doing just two mornings per week to deal emergency jobs for key workers. Very strange times indeed! However this has given me the opportunity to write up a few more interesting jobs that I’ve done over the past few months. This particular one got me thinking about a few different things and maybe considering tweaking my diagnostic process slightly.
The owner of a garage that we do a bit of diagnostic work for contacted me to ask if I could take a look at a 2015 Ford Fiesta 1.5 TDCi that was causing him grief. The complaint was that shortly after start-up and moving off, the vehicle would drop into limp-home mode with multiple warning lights on the cluster.
As always, I asked some questions to gather as much background information as possible, and so the story began. The vehicle came into their workshop with the above symptoms. The fault codes stored pointed towards a turbo wastegate fault. You’re probably mostly thinking the same as I was at this point; sticking wastegate, wastegate control solenoid malfunctioning, vacuum fault, can’t be that complicated surely?
We discussed all the tests that were carried out and what parts had been replaced. This included a new genuine solenoid valve, an actuator repair kit followed by a reconditioned turbocharger. With the fault still present the turbo supplier then recommended a trip to the nearest franchised dealer for testing and a turbo position sensor relearn. After spending some time on the vehicle, the dealership’s diagnosis was the turbocharger and recommended a genuine replacement unit. Reluctantly the garage fitted a genuine unit but guess what? I don’t need to answer that!

The vehicle arrived and I started my plan for diagnosing this fault. I was in challenge mode now and was not prepared to be beaten. I knew my plan had to be thorough so I took some time to confirm the fault and do some research. As tempting as it is, just to clear the fault codes and carry out a fresh test – this isn’t always a good move, particularly when the fault is intermittent and may take some time to replicate. In this instance however, there was little to lose by doing this as apparently the fault was very consistent.
I took a read of the fault codes which were as follows:

  • P2563-72 Turbo Boost Control Position Sensor Circuit Range/Performance
  • P2599-00 Turbo Boost Control Position Sensor ‘A’ Performance Stuck High

The codes were cleared and the vehicle was driven. Within 15 meters we were back in limp-home with ‘Engine Malfunction’ message, a spanner symbol and ABS/ESP warnings on the cluster. At this point I carried out a full code scan to see what other codes were stored and why the ABS light was coming on. As suspected it was a DTC often seen in ESP which is purely down to the Powertrain Module not delivering the calculated engine torque reading via the CAN. While sat in the vehicle, I repeated the test several times while monitoring some serial data just to check for any anomalies including Mass Airflow, Manifold Absolute Pressure, Exhaust (DPF) Back pressure, Turbo Wastgate Position and all intake and exhaust temperature sensors which were all within spec.
By now I had found that the fault would set after about 10 seconds even if you remained stationary and just raised the RPM. This was going to make testing much easier as we wouldn’t need to drive it anymore.
My next step was to gather all of the technical information required and also search for technical service bulletins relating to this fault/symptom. Over the past two years I have learned the power of OEM information portals and OEM diagnostic tools. I had signed up to Ford ETIS and purchased the VCM2 interface so this seemed the ideal time to put it to the test and get to grips with it.
I am familiar with several if the other manufacturer’s tools and portals but this one was new to me so I enlisted the help of my good friend and fellow Top Tech Winner of 2019 – Neil Currie. He remotely demonstrated how to use the portal and where to find the information. The information was limited in this instance and all we could find was a bulletin relating to the wastegate actuator. The symptom and one of the DTCs matched but this had already been replaced, twice, so it was time for some testing.
The fault codes suggested that it wasn’t boost pressure-related, more the position of the actuator being incorrect. A thorough visual inspection showed us that it was a simple electro/vacuum controlled wastegate system consisting of a wastegate vacuum actuator with built in 3 wire position sensor, vacuum solenoid control valve, vacuum pump, the engine computer (PCM) and the wiring and pipework to connect it all.
With a vacuum gauge I checked the vacuum to the solenoid valve which was good and the controlled vacuum on the other side which was also good. I manually applied vacuum to the actuator with a hand pump which proved there was no leak and that it moved freely from min to max stops. The serial (live) data allowed us to see the command or duty as a percentage for the solenoid valve and the actual position on the sensor in volts. This confirmed that it was a conventional 5-volt position sensor with a 5 volt supply and ground from the PCM and a signal wire back to the PCM which typically would range from between 0.5 – 4.5 volts.
It also allowed us to monitor the command and the actual position the point it faulted. What I could see is that when the fault occurred the command went to zero and the position voltage went low which in turn fully opens the wastegate thus reducing/limiting boost pressure. Did the command stop, which caused the solenoid valve to stop applying vacuum and exhaust the diaphragm to atmosphere? Or did the PCM see an abnormality in the position and decide to switch the command to zero? There is always a delay in serial data and the refresh rate is not always fast enough to capture a glitch or see which of the two lines of data changed first.

We can’t trust the live data but we can trust the oscilloscope so I set it up to monitor the electrical side. I did this in three stages:
Stage 1: All three wires at the position sensor. Firstly, I monitored the 5-volt supply and ground at the sensor and then the signal wire at the sensor and back at the PCM and watched to see what happened at the point of fault. There was no abnormality in the 5-volt supply or the ground and both signal wire readings were identical.

Stage 2: The solenoid valve which has just two wires. One is a 12-volt supply and the other is the switched ground which is turned on and off at a high frequency by the PCM. This is called a duty cycle. The longer it is on for the more vacuum is applied to the diaphragm and the longer it is off the ore of that vacuum is vented to atmosphere. At the solenoid I monitored the 12 volts supply which is nominal battery voltage (NBV) and the PCM-switched ground. During the off period it shows battery voltage (NBV) and during the on period it shows 0 volts. Both readings were what we expected to see. We could have added a third measurement here and monitored the current which would tell us more about the actual internal movements of the solenoid but what I saw in Stage 3 showed this wasn’t necessary.

Stage 3:  I monitored the Solenoid Duty and the position sensor signal. The vehicle was run and made to fault again and this time we could see exactly what happened first; the cause and the symptom. Fig.1 shows that the command/duty is suddenly switched off and the position signal starts to fall shortly after.

So where next? The above tests may sound long-winded but in fact took no more than 20 minutes as accessibility was easy. Again with the help of Neil I connected the Ford diagnostic tool and logged into the FDRS online software. We looked through the functions and saw that there was a relearn function for the position sensor. Thinking I may have struck gold, I downloaded and ran the function which sadly once again made no difference. I was confident I had tested everything correctly. What was left? Two key parts had been replaced and eliminated from the investigation. The wiring and connections were confirmed to be good. That only left the PCM itself or the software within it.
The power of networking is great and once again I conferred with Neil who agreed with my thoughts and process. Back on FDRS he demonstrated how to check when the software was last updated and also how to run a software update. With battery support connected I followed the on-screen prompts until the new calibration file was fully installed. With the RPM raised for a longer period of time the fault did not reoccur. An extended road test (See Fig.2) confirmed all was good. Fig.3 demonstrates the system in correct operation. You can see how when the required boost pressure is achieved the PCM adjusts the duty cycle to reduce the vacuum and open the wastegate in order to reduce and regulate boost pressure.
What have I taken away from this job? It begs a question; at what point in the diagnostic process do you attempt a software update? Maybe I could have tried this earlier on in the process. My experience with other manufacturers has shown me that normally if there is a software update it is to fix a known fault or to alter certain parameters to account for wear and there will be a bulletin for it. I’m sure I am not the first person to see this fault but even with help I couldn’t find a technical service bulletin for it and clearly neither did the technician in the Ford dealership. I am happy though. The car is fixed, I got paid and I know next time I will be reaching for that OEM tool and information much quicker, and confidence to use it!

Related Articles


©DFA Media 1999-2020
Terms and Conditions