[Each picture is linked to a larger copy.]
There is a common problem with some of the multi-function display (MFD) screens in the 2004 and some 2005 Prius, manifested by the buttons and the touch areas on the screen itself becoming sluggish and unresponsive, no display of current or average MPG, and no control over the stereo or air conditioning. This problem tends to start sporadically and slowly become worse over time, although there have been a few that have failed suddenly and hard. Another owner who replaced a failed unit in his own car -- unfortunately, out of warranty and thus expensive -- was able to keep his old one and kindly passed it along to me with the intent of possibly finally finding the cause of this problem. People have been reporting and wondering about this on the forums for quite a while, and the symptoms seem to be largely the same in most cases. Toyota knows all about it, as detailed in TSB EL002-05, and their fix is to swap in a new unit. But out of warranty, these replacement units are a few *thousand* dollars from dealers. There's sometimes an opportunity to obtain a refurb unit for about $400 - 500. This is detailed in a Priuschat thread [copied here] although the Toyota-sourced path is no longer in effect. If Autobeyours is out of stock too, what can be done? Well, after having finally found the most likely problem cause I can now help the owner community keep these units going, and with enough persuasion I or Steve or several other people might be convinced to start a little exchange/repair service.
The item in question, front and back.
To set up for testing, I had to pull my own MFD out of the mounts, leaving a large void in the car. Once the two angled bolts at either side of the unit are removed, it's pretty easy to snap the whole thing in and out but the two vent panels on either side need to be left out since the bezel hooks under them. That's okay, it's not like my car hasn't spent about half its life running around with parts of the dash torn apart. Chris Dragon wrote a really helpful document about dash disassembly that may be of interest.
My still-good unit with its button panel assembly. The angled brackets that hold the two mounting bolts need to be removed or at least loosened and swung out of the way to get at two of the MFD mounting screws.
Both units and the empty bezel. The clock and hazard/odo/trip switch module are still in place. These two have slightly different part numbers, making me wonder if my so-far-non-failed '04 unit might be from a different manufacturing line or production run. Hmm, let's take another look at the TSB...
Well, whaddaya know. It looks like my unit *is* a ...081, one of the possibly improved ones recommended as the "current replacement", and the bad one is presumably outdated. Analysis of the differences to improve reliability are detailed on a separate page; see below.
Pre-testing the bad unit. It powers up and allows entry into the diagnostic modes, and from here I can check to see what connectivity it still has. Here we can see the battery voltage and various other signals that are hardwired into the harness into the back of the thing.
Turning on the running lights causes the unit to dim the screen and change the displayed state. I also pressed the parking brake, and the unit sees that change too.
The touchscreen works fine; the little box follows tightly as I drag the butt of a pen around on the surface.
All the single-color and bars video tests are okay. This picture is likely to create interesting moire' patterns on your monitor depending on how you're viewing it. If you're bored, view the big picture and stare intently into it while moving your head toward and away from the screen.
The bezel buttons seem to function, responding instantly in the box when pressed. However, there is no beeping emitted. That's significant.
Upon returning to the normal screen, though, we clearly aren't getting data from the car -- in IG-ON mode here, I should see the battery state and *some* instantaneous MPG reading even if it's zero with the car not moving. I can switch to the consumption screen, but it takes a very long time to respond. Why? Because the MFD uses the stereo amplifier to make the button beep -- and expects a *confirmation response* back from the stereo saying "okay, I made a beep!" When that doesn't come back, the MFD eventually gives up and switches screens anyway. But waiting for that network timeout is what produces the "sluggish" response. Naturally I don't see the MPG average on the consumption screen either, since that's stored in and sent from the speedometer ECU.
We also can't talk to the climate control system. All of this matches the symptoms described in EL002-05 and the forums, and points to the fact that the AVCLan, a small data network between various components in the car, isn't reaching the MFD. [It's actually IEbus, a two-wire network pretty much designed for the automotive environment.] Okay, time to figure out where that comes in and why it's busticated. At the same time, we'll just get a good look inside the unit in general.
First layer: rear cover removed. The largest white connector is M13 -- the main one from the car, and is the one with the connections marked up in the parts-location bible page shown. M14 next to it is for the navigation, for which there's no connector in my non-NAV-equipped car's harness. The third connector is completely *undocumented* in the manual.
The outer frame of the box comes off next. There's a lot of sheet metal holding this thing together, and healthy attention paid to shielding integrity. The shield soldered onto the board covers a bunch of inductors, and appears to be a power supply for the electroluminescent panel backlight whose little white connector can be seen near the right end.
Next, the two halves of the unit split apart into a rear board and the rest of the display side. A short jumper connector [U-shaped thing with the *black* ends, upper left] must be removed first. The other cable is the one to the button matrix in the bezel. During some interim testing, sporadic network connectivity *was* achieved once in a while, and it seemed to come from wiggling that short jumper connection or something nearby. So that's now a prime suspect.
But the majority of connections between the halves appear to go through this 60-pin micro-connector.
The rear of the outer board. The area with the black coils is more of the high voltage power supply for the backlight. Note how a couple of leads from this area are isolated by physical slots all the way through the board -- there's a good reason. During some bench testing I tried to measure the voltage produced by this section, and my meter that's rated for 1000 volts shot up to 1800-something on the highest scale and made a small unhappy noise inside while a spark jumped to the test lead. So this area has a couple of KILOVOLTS running around it, explaining the very widely-spaced connector [barely visible through the board] leading to the display. Fortunately, the meter handled the momentary overload and was undamaged. It's funny as hell how people worry about a 200-volt battery and orange wires, and then routinely and voluntarily poke their fingers mere millimeters away from voltages *ten times* higher on a daily basis without a second thought.
This small board mounts to the remaining half with two screws, but there's also a little bent-over peg that one edge rests on, presumably to reduce vibration. There's a plastic pad glued under where the metal finger bears against the board underneath, and the whole thing is very slightly stressed upward at that point as evidenced by a compressed divot in the pad. This prompted close [i.e. under a 30x binocular microscope] examination of the board to see if prolonged stress had started any cracks in lands or solder joints, since the suspect short jumper also connects to this nearby. But it's only a two-layer board as opposed to the multilayer larger ones, and looks nominally healthy.
Removing and turning over the final display board reveals the *big* processor. The ribbon cables going to the screen are brought into nice latch-release connectors, rather than the limited-cycle force-fit ones we see in a lot of other products.
Finally, we're down to the back of the VDU itself. Note the high-voltage warning logo; as we've seen, they ain't kidding. Since going further would involve unbending metal bits, we'll stop here. It's pretty clear that the screen itself is fine, so no need to mess with this.
At this point, everything is getting a cursory pass under the microscope to look for obvious physical problems. It's state of the art SMT, and everything is *very* small scale! The little jumper cable gets its jacket cut off to see if there's anything up with the wires or connector pins. Here's one of the pins I backed out of the housing to look at, to check if perhaps the springiness of the lug has weakened. It appears to be okay and still well under the width of the mating pins at its rest position, and through the front of the connectors all the other lugs look okay too.
But the pins themselves appear to have a little bit of pitting right where the connector fingers bear on them -- hard to tell, it looks worse under particular angles of light and nonexistent under others.
Same with the smaller connector that goes to the button matrix -- tiny wear areas. A pass with DeOxIt and several plug/unplug cycles seems to clean all this right up, though, so I wouldn't say the connectors are outright corroded.
However, this doesn't fix the problem or even change it. After a few more testing cycles, I know several additional things: I've reduced what is necessary to reproduce the symptom to just the two main boards, naked, thus eliminating the jumper connector and its little ancillary board entirely. The video screen isn't here either. I've eliminated the button cable, which was evidently giving some false button-press events during early testing stages by picking up stray voltage from somewhere. Probably exacerbated from my other hand holding the unit near the VDU high-voltage supply, sending lots of nice spikes into open logic inputs. I'm scoping the IEbus network leads, and seeing occasional signals that look an awful lot like an unterminated data line. I should be seeing something rather different on the scope here. I can still cause the problem to come and go by wiggling this assembly. When the network is working, the signal stabilizes around 2.5 volts with small deviations when a packet goes by. When it breaks again, these short spikes toward ground start occurring and the whole thing jams. Interestingly, with the the car's stereo on but at a very low volume level those spikes actually leak into the audio output a little bit. That might be a really easy way to tell if another failing unit is due to the same network-related problem without any tools: just power up the stereo at zero volume and listen carefully.
I can also hear the difference between a good network and a bad network on an inductive probe, eliminating the need to hook up the scope every time. Reducing the test environment to this makes rechecking much easier, since I can just plug in, turn on the stereo and wave the probe around near the network connections and then fiddle the volume or tuning up and down. This generates a fast stream of network events which either I hear on the probe's little speaker, or gets lost in the much louder open-network noise when it all goes south again. Twisting the inner display board somewhat clockwise seems to make the network stabilize, and is now pointing rather strongly to that 60-pin inter-board connector as the problem area. There's nothing else that can *move* anymore, other than trying to flex the boards themselves. Now, at this point I've been all over these things under the microscope, and still can't see anything amiss, but it's definitely a physical-stress related problem. That's possibly good, since it's not a failed *part* that would probably need a schematic to actually debug.
But let's take a closer look at that connector. All the pins are gold- flashed, and I see no evidence of the pressure pitting like on the other connectors. So connections through this *should* be clean. However, there may be a little design problem. The center "male" piece is connected to the outer shell via long U-shaped bent leads, and is intended to be able to float around and adapt to insertion misalignment -- a little of which will invariably happen when the two halves of the MFD are put together, since the board mounting positions aren't totally precise! While the connections are invisible with the two parts together, a little dimensional analysis under the 'scope reveals a potential problem. In this expanded diagram of the connector pieces, the two .100" figures are NOT a typo. It looks like the intent is to have a slight interference-fit mating as far as widths of things go, and let the outer shell's connection bars protrude slightly into the relief slots in the inner part. The inner fingers are supposed to be the sprung elements, but sit fairly deeply recessed without a lot of protrusion out of the inner block. The issue is that the two faces that align at .100" are going to be *just* flush rather than nested, relying on the small amount of outward flex of the inner pins to make contact.
Now let's put the pieces together. The inner fingers touch the outer contacts and the slight springiness keeps them pressed together. Great.
But what if the center plastic moves substantially away from center, such as could happen at each end if one half of the connector gets twisted? Whoops, we've just broken contact on one side.
The obvious fix is to allow for more spring movement of the inner fingers, since the connector's base dimensions seem at odds with how it was likely *supposed* to work. This should accomodate more deflection, and is an easy change I can do to the connector.
And here's how. Every one of those sixty pins gets a little tweak outward, using a small sewing needle under the 'scope. After doing a couple of them, note the rest-position difference between the two pins at the red arrows in the big picture. After this treatment to all 60, the connector feels a *lot* tighter when mating, and given that a strongish counterclockwise twist had been exacerbating the problem, this has *got* to be the permanent answer short of changing out the connector [yeah, good luck without a serious reflow station available].
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X X X X X X X But after all that, it DOESN'T WORK. X X X X X X Back in the car, the network problem is still there, and still comes X X and goes when the boards are wiggled relative to each other. X X X X X X X X WT bloody F. X X X X X X X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Let's take a closer look at where the network goes. It comes into the rear board via two leads [upper pink dots] and then loops through to go OUT again via two other leads [lower pink dots] that go to the stereo. Here we can clearly see that it's a straight pass-thru -- curiously, via two 0-ohm black chip resistors -- and also has a branch over to one end of the NAV connector. But where does it go within the MFD itself? It won't be at all easy to trace connections physically through this swamp of surface-mount and buried layers and blind vias, especially when they dive under large parts like the car connector shells. But as strange as it seems, the network may actually pass through the 60-pin connector. Strange because you'd think the network transceiver would be placed on the outer rearmost board and tie into some other data interface to the main processor... but given some of the other oddball parts placement we've seen around these cars, I guess we have to expect anything. And it's easy enough to go after this in the electrical domain. That same meter that almost met its doom in the high-voltage backlight supply has one really nice feature: its diode-test and continuity audible beeper has a *really* instant response -- faster than any other meter I've used, and fast enough that you can actually hear "scratchiness" in a moving connection. And believe me, milliseconds make all the difference when you're moving through a thicket of test points trying to find the ONE that's connected to somewhere else. So by using that and a couple of Very Sharp Probes to get through the conformal coating, I shortly discover that two pins at one end of the 60-pin connector do indeed carry the IEbus network through to the inner board. Two pins located at one END. Think about that for a moment, given all the foregoing.
A little more physical tracing follows those two leads up to this area on the inner board, where they connect to a termination network and present two handy test points, TP47 and TP48. Obviously where to check for network connectivity, huh? The two leads continue through to the other side of the board and end at pins 5 and 6 of a small chip labeled CA0008. Googling this returns surprisingly few substantial hits -- just a lot of noise from the datasheet pirates that try to keyword up anything that even remotely looks like an electronic part number, those fucking parasite bastards. Kill them all. But there are some hints floating around that the chip is the equivalent of the Hitachi [now Renesas] HA12187 interface driver, documented here and clearly geared toward "automotive audio equipment". So here's where to connect a couple of test wires, and to ease testing access I tack a couple more onto the car-connector pins at the other end. I'm using the NAV connector since I'm not as concerned about screwing that one up.
To work in this environment without sweeping broad swaths of dust-sized chip components off the board from excess heat, I need a very tiny soldering iron. I don't have one. So this copper-wire extender for my smallest Weller tip will have to do. Not perfect and needs frequent scraping and re-tinning, but I got my wires on.
One of the connections is solid. The other is *all* over the place as the boards are wiggled, and not in any really sensible pattern following how the connector is stressed -- although the clockwise-twist-to-fix is still somewhat in evidence. This is nuts. I've been all over the solder connections into this piece several times by now -- they all look smoothly flowed and good. But now maybe I know where to *really* look.
And in the microscope's-eye view, however subtle it may have been to hide until now, THERE IT IS. A tiny hairline crack under pin 60. No, much less than hairline, since a hair would look like a giant ugly log in this picture or an even larger magnification. OMFG, that was hard to find.
So with my tiny iron and a little bit of my good ol' non-RoHS-compliant "real men ride Harleys and drink pisswater american beer" 60/40 LEAD-containing thankyouverymuch solder, I manage to punch through the somewhat excess puddle of conformal coating around here and reflow both network connections. I still can't see anything amiss with the other 58, as tempting as it might be to try touching up *all* of them.
Retesting shows a solid connection, even under substantial deflection in both directions. Beeeeeeeeeeeeeep with no breaks. Yay. The "naked boards" setup back in the car yields a solidly working IEbus. The test wires get removed and the unit gets reassembled, with particular attention paid to letting the outer board settle into the position of least sideways strain on the connector BEFORE tightening down the mounting screws. Once swapped into my bezel, it goes back into the car. And works perfectly over several days of testing.
Read an UPDATE written two years later, reflecting
on the Prius community experience
with fixing these things and advancing a new "twist stress" theory on unit factory
assembly that may also contribute to the problem.
_H* 071117, 071120, and a later update 100124