When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
I just figured out how to use the SSD MONGOOSE software and using it to track down issues with my 2005 XJ8. Apparently I bought a bunch of problems that I have slowly been resolving. But although I can now get the car to start now (which if you check my other posts, is a major improvement… it purrs until it dies out), it is not able to run for more that 30- 40 seconds before it starves out from lack of fuel pressure. The issue is that the fuel pump is not being told to run after it starts. To be clear the fuel pump runs on first ignition on, but apparently is not actuated after starting the engine. If you check my other posts, I did resolve the first issue no start at all by replacing the fuel pump and filter as well as cleaning the injectors and replacing the plugs.
This is clearly a computer issue at this point and when I ran the module test I discovered that I have a pretty major communication bus issue. There are just too many items not talking to be a computer failure at this point. My guess is that I have a dead short on a pin or wiring harness.
Among the most pressing:
FEM - Front Electronic Module
REM - Rear Electronic Module
DDM- Driver Door Module
EPB - Parking Brake Module
SCLM - Steering Column Module
It should be noted that other than the starting issue the only items that appear to be non functional on the vehicle is the steering column lock and, intermittently, the remote for locks. Everything else works. So it is obvious that the individual modules above are functional and working independently, just not necessary communicating as expected with the com bus or the SSD mongoose software.
History: The ECM WAS REPLACED and reprogrammed with the original vehicle vin while off the vehicle.
So my question to the forum. Where should I look for the most likely failure point in the wiring. I already checked the REM and it and the wiring and all the plugs and they appears to be perfect. I found the plug under the rear passages seat that had corrosion and removed the connector plug and individual soldered the connections to ensure proper connections forever. I just don’t know which bundle of wires to follow at this point. Should I pull the driver door panel? Is that a likely place for corrosion to cause this issue?
You are on the right way with SDD Diagnosis, but there should be some DTCs to read out.
What is striking about the control unit overview is that none of the control units are recognized on the SCP bus. DDM, FEM, REM, ICM are all involved in the process of opening the doors, deactivating the alarm, canceling the immobilizer and releasing the steering wheel lock. As a result of propper identification the ECM receives the release to activate the ignition and fuel system that way.
It's not entirely uncommon for controllers to work properly even though they can't be detected.
SCP (Standard Corporate Protocol) is a data bus system developed by Ford with twisted two-wire cables.
I would download a wiring diagram and start with looking at the wiring between the mentioned control units and the SCP pins (2 and 10) on the OBD connector.
Does your battery show up green in top left screen of SDD? Before chasing wiring, get the codes. Write them down, clear all codes and run refresh from the main screen, not the same one that you clear codes with. If still com loss put that in as symptom and see what it suggests. Show all codes, including the ones that are unrelated in the next tab. Post all codes in the forum.
Battery shows up yellow. Had the battery tested and it tested fine.
Using a different code reader tool it tells me the battery is 12.05v.
I attempted to clear the codes using SSD software and I get the same error that it cannot communicate.
What is the voltage at the battery terminals? 12.05v should be closer to 12.6v with a good, charged battery. You seem to have a bad connection if your battery is fully charged. The absolute lowest for programming is 13.6v and I would not do it at less than 14 to recover the ECM. If you have a battery charger you could connect it, check the voltage where connected and read the OBD voltage again. They should be very close to one another in value. Check to see if any modules come online when you are up to 13v or so. Your charger should give you at least that voltage. Watch the SDD battery indicator stays green during the scan.
Sorry for the delay. I purchased a more robust battery charger and was able to charger the battery to 14volts. It appears to report to the car as 12.9~ which appears to be well within spec.
the SCP network is still not reporting. Pulled the car apart to test wiring. The CAN BUS is fine. The SCP is another story.
G239843t29 : CHECK THE SCP + FOR SHORT CIRCUIT TO BATTERY
Reports over 12volts. In hindsight, knowing what was reported by the DSS software, I should have started there… but I have lost all faith in my diagnostic skills at this point.
So the obvious next question is where is it shorting to the battery. I know that I caused the short as the car was running fine before I started to do maintenance. Specifically the moment that the problem arose was after I pulled the transmission pan to replace the filter. I went to start the car to circulate the fluid while I added the additional fluid to top it up and the car refused run. Does that offer any clues to anyone on the forum?
Last edited by Bluefish001; Oct 8, 2022 at 03:35 PM.
Download yourself a workshop manual for the X350, there you will find a pinpoint test for the SCP error G239843t29 (starting at the OBD connector, as I wrote).
When you changed the transmission oil, did you also change the sealing sleeve for the cable connector? Is it possible that the cable or pins got damaded? Or that transmission oil got into the connector?
Anyway, I would open the connector, check it and clean it with brake cleaner and do the pinpoint test.
I actually have the manual and did the first test. It failed with over 12 volts.
Originally Posted by flatsix
Download yourself a workshop manual for the X350, there you will find a pinpoint test for the SCP error G239843t29 (starting at the OBD connector, as I wrote).
When you changed the transmission oil, did you also change the sealing sleeve for the cable connector? Is it possible that the cable or pins got damaded? Or that transmission oil got into the connector?
Anyway, I would open the connector, check it and clean it with brake cleaner and do the pinpoint test.
Steps taken so far to find the short.
With the meter attached, I pulled every fuse and relay to see if I could isolate the short to a specific circuit. Only one fuse had any effect and it was the fuse to the DLC, so that was not helpful.
‘Because this is an issue specifically related to the SCP network, I decided to trace those specific modules:
I then disconnected EVERY plug in the boot… no effect. Unplugged the FEM plugs, no effect. Discovered after an hour of disassembly that the car does not have a SCML which would have been nice to know before I wasted the time. Disconnected every plug I could get my hands on under the dash and only one had any effect. It is a gray plug located behind the left hand dash outer removable cover parallel to the drivers door. But since the voltage went to zero, rather than 3 volts, I am guessing that it is also not informative to the shorting to battery issue. That only leaves the DSM and the DDM. I have to purchase torx sockets to pull the seat for the DSM; and the DDM requires that I pull the driver door panel which will have to wait until tomorrow.
The main observation I can report is that the wiring and the modules appear to be in like new condition. I doubt anyone has been this deep into this car before. Without access to the SCP, which includes the REM that manages the fuel pump, I am dead in the water to diagnose the car effectively.
You are actually on the right track with this approach. The short circuit on the S+ line can be caused by a plug or cable problem or a defective control unit.
There are professionals who can find such errors using signal images on an oscilloscope. We probably only have the tedious method of staking out of the line.
I would start with disconnecting each of the affected control units and if this doesn't reduce the current to less than 3 volt, continue with the connectors.
Due to the DTC you can narrow it down to the extent that the error on the S+ line must be on pin 2 of the DLC. The circuit diagram shows which control units and plugs are attached there.
You are on the right way with SDD Diagnosis, but there should be some DTCs to read out.
It's not entirely uncommon for controllers to work properly even though they can't be detected.
Fritz
Fritz,
That is a curious observation about not detecting a module. I have seen that if for example, the switch the Ignition to ON there needs to be say a 10 second delay before clicking on the YES check before the system starts scanning so the buss can fire up and become stabile, or wondered if it was a programming error with IDS/SDD not giving enough time for the modules to respond and then marking them "not detected", even though I know they are there and functioning. It sort of makes the ability of getting codes out of them a bit difficult.
If I run the configuration capture a couple of times, some of those modules seem to wake up. If the module has a specific configuration in the New/Existing module configuration screen, it may time out but then eventually make the connection and successfully configure the module.
Is there a way to just have the IDS/SDD ping just one module on a particular buss to check communications?
I need to learn more about that process and exactly how to decode the VCATS to make sure it is right for my 2005 X350 4.2 NA USA XJ8L vehicle actual configuration.
This is typical of one or more bad busses. The modules do not give up because they do not get the expected info. They just work when they finally get good info even though it may be intermittent. Also they will keep broadcasting their readings etc even though the other modules are not able to receive it.
You need to do pinpoint tests to determine which bus is not as it should be.
Fritz,
That is a curious observation about not detecting a module. I have seen that if for example, the switch the Ignition to ON there needs to be say a 10 second delay before clicking on the YES check before the system starts scanning so the buss can fire up and become stabile, or wondered if it was a programming error with IDS/SDD not giving enough time for the modules to respond and then marking them "not detected", even though I know they are there and functioning. It sort of makes the ability of getting codes out of them a bit difficult.
I need to learn more about that process and exactly how to decode the VCATS to make sure it is right for my 2005 X350 4.2 NA USA XJ8L vehicle actual configuration.
SDD topology is not the real deal 😂
read the VID from the car then go compare it to the as-built it’s that simple
SDD topology is not the real deal 😂
read the VID from the car then go compare it to the as-built it’s that simple
Its only that simple if connected to the internet because SDD can sync to verify the config, not as easy using a clone version with PC date of 2011 and not able to connect and update. True?
I am still wanting to know if the Premium vs Audiophile configs are different.
Its only that simple if connected to the internet because SDD can sync to verify the config, not as easy using a clone version with PC date of 2011 and not able to connect and update. True?
I am still wanting to know if the Premium vs Audiophile configs are different.
This is typical of one or more bad busses. The modules do not give up because they do not get the expected info. They just work when they finally get good info even though it may be intermittent. Also they will keep broadcasting their readings etc even though the other modules are not able to receive it.
You need to do pinpoint tests to determine which bus is not as it should be.
What is the diagnosis process when the provided solution is reconfigure the module to resolve the communication faults? I recall pin point tests require the diagnostic cables to show bus waveforms and trigger syncs.