Motor Vehicle Diagnostic Scanner

[Kim Veller]

Ihave been using it for 22-months. No problems whatsoever. My car never returned a fault code. Check engine light never turned on. For 22-months, I was completely happy with the car as it gave me 0 problems and it has performed really well.

Last night, I decided to go to my car's dealership for an oil change. They said my car has a recall for the rear O2 sensor software; that it needs to be reprogrammed. I said, "OK whatever, do what you have to do, as long as I get my regular oil change and go home after."

My question is, are they correct to say that these OBDII devices can mess up the ECU? To my knowledge, they only read, and cannot write to the ECU. It is my belief that they messed up flashing the ECU with the software update.

As communication interfaces, they will never write data to the bus on their own, but they will write whatever they are told to by a connected bluetooth device. Of course, it is possible to mess up the ECU this way, e.g. by trying to flash the wrong firmware, change config data, or whatever the ECU allows to be done via OBDII. But Torque does not know how to do this, and I can't imagine that it's possible to send data saying "kill yourself" accidentally.

On the other side, the shop had to connect its own device and communicate with the ECU, too. And their software is much more powerful than Torque, and for sure knows every command that can be sent to the ECU, including the potentially dangerous ones. For me, it sounds much more likely that they accidentally messed up your ECU and now blame your device. The problem is: They found a device connected to your OBDII port which shouldn't be there, and now blame it, while it will be impossible to find out what really happened.

Apart from some "killer commands", the ECU might have been destroyed electrically. The OBDII-Interface can implement several different data buses with different voltage levels. If the bus lines get connected to +12V, this could destroy something. If I were the designer, I would make it so that 12V on any of the OBDII lines would not roast the electronics, but I am not the designer...

On the other side, it sounds unlikely that your device just built a short circuit when the car was at the shop...

At times, one may encounter a freak occurrence in which a module locks up while in communication via scan tool. Another possibility is that the vehicle's battery did not maintain a steady and/or sufficient voltage while updating the software (unlikely). This sometimes can't be accomplished with a battery charger; a Midtronics GR8 style variable amperage charger or equivalent may be required if the battery is unstable.

Again, depends on model year. Some older vehicles have a tendency to throw errors mid update, after which, are unable to complete a recovery process leaving the module useless, therefore requiring replacement.

I would suspect that it was the dealer's system / ecu flash attempt that killed your ecu. My evidence - being a member of the jaguar forum where similar things have happened : a small update that fails then needs 2 days or more to fix - just google it. However, proving it is them is another thing... good luck.

Simple OBD readers such as those based on the ELM327 are basic, but they do allow mostly unfettered access to the engine ECU. Most of the time, there is a graphical client on top displaying the raw data in a human-friendly format. However, some clients (e.g. OBD Wiz, which I use on my diagnostic PC) support typing commands directly to the ECU through this interface. As these are low-level commands, there is likely minimal error checking and I could, conceivably, send a command that would cause the engine to stop and not restart - altering the base ignition timing, for example.

For most cars, however, this is not a permanent fault. Most cars have ECUs that are read-only. The data in memory can be manipulated, yes, but if the battery is disconnected, the memory is cleared and the ECU will revert to factory defaults. Only specialist ECUs actively support overwriting the air/fuel map.

That's not to say you shouldn't approach this with caution, as you can still do some lasting damage, for example, setting the ignition timing so far advanced that it causes detonation, which can destroy the engine.

2000 Nissan Altima was stalling on acceleration. Still starts though when engine dies but stalls again when accelerating or under load. The "Service Engine Soon" light was on so a friend connected his OTC Scanner and soon after that, the car won't start. Couldn't get any error codes. It turns over, but won't start. Left it at his place overnight and came back the next morning to troubleshoot. Tried starting it and it starts. Took it home, changed fuel filter & oil. Ran ok for a day then stalled again when my daughter was driving it. After much research, I decided to buy my own OBD2 Scanner from Amazon. Got an Ancel 410 for $73.00.

In the meantime, I you tubed other probable causes and found a leaky vacuum hose that was chewed by a mouse or rat that lived in the engine over the winter. I took out it's nest awhile back. Looked like a Christmas wreath. That seemed to fix the stalling problem but the "service Engine soon" light was still on but the car was still running fine after a few road tests. Looks like the leaky hose was causing the stalling and causing the "Service Engine Soon" light to come on.

NOw that the car was running again, My friend came over again with his OTC OBD Scanner to try and scan for error codes and was able to get the following codes. (My Scanner did not arrive yet) P0100, P0505, P0325,P1490, P0446,P0464. His connecting the OBD Scanner again killed the car and would not start again after it was running fine already. Still needed to get the "SES" light off too!

So back to youtube. Apparently, the scanner sometimes messes the ECM and has to be hard reset. This can be done by removing both battery terminals and crossing or connecting them together for about 10 seconds(make sure both terminals are removed from the battery) this will discharge the capacitors and you should be able to start your car again.

After the entire cluster of warning lights lit up while I was driving, speedometer and tachometer stopped working, lost power steering and the AC, I was able to get my vehicle home, but once I turned it off, it wouldn't restart. This is the second time I've had this problem and I replaced my ECM, had my keys reprogrammed and I thought that had solve the problem. That was three weeks ago. This all recurred a couple of nights ago. Because I was going to do a scan on another vehicle, I unplugged my Zus vehicle health monitor from the OBD port and then wondered, "Slim chance, but what if my vehicle starts?" It did. Immediately.

With the vehicle health monitor plugged in, upon trying to start the vehicle, the ECM had activated the anti-theft function and so it wouldn't start and the cluster would light up. Unplugged, everything works perfectly.

On-board diagnostics (OBD) is a term referring to a vehicle's self-diagnostic and reporting capability. In the United States, this capability is a requirement to comply with federal emissions standards to detect failures that may increase the vehicle tailpipe emissions to more than 150% of the standard to which it was originally certified.[1][2]

OBD systems give the vehicle owner or repair technician access to the status of the various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely since its introduction in the early 1980s versions of onboard vehicle computers. Early versions of OBD would simply illuminate a tell-tale light if a problem was detected, but would not provide any information as to the nature of the problem. Modern OBD implementations use a standardized digital communications port to provide real-time data and diagnostic trouble codes which allow malfunctions within the vehicle to be rapidly identified.

GM's ALDL (Assembly Line Diagnostic Link) is sometimes referred to as a predecessor to, or a manufacturer's proprietary version of, an OBD-I diagnostic starting in 1981. This interface was made in different varieties and changed with power train control modules (aka PCM, ECM, ECU). Different versions had slight differences in pin-outs and baud rates. Earlier versions used a 160 baud rate, while later versions went up to 8192 baud and used bi-directional communications to the PCM.[15][16]

The regulatory intent of OBD-I was to encourage auto manufacturers to design reliable emission control systems that remain effective for the vehicle's "useful life".[17] The hope was that by forcing annual emissions testing for California starting in 1988, [18] and denying registration to vehicles that did not pass, drivers would tend to purchase vehicles that would more reliably pass the test. OBD-I was largely unsuccessful, as the means of reporting emissions-specific diagnostic information was not standardized. Technical difficulties with obtaining standardized and reliable emissions information from all vehicles led to an inability to implement the annual testing program effectively.[19]

The Diagnostic Trouble Codes (DTC's) of OBD-I vehicles can usually be found without an expensive scan tool. Each manufacturer used their own Diagnostic Link Connector (DLC), DLC location, DTC definitions, and procedure to read the DTC's from the vehicle. DTC's from OBD-I cars are often read through the blinking patterns of the 'Check Engine Light' (CEL) or 'Service Engine Soon' (SES) light. By connecting certain pins of the diagnostic connector, the 'Check Engine' light will blink out a two-digit number that corresponds to a specific error condition. The DTC's of some OBD-I cars are interpreted in different ways, however. Cadillac petrol fuel-injected vehicles are equipped with actual onboard diagnostics, providing trouble codes, actuator tests and sensor data through the new digital Electronic Climate Control display.

3a8082e126