PN 89111-50040 I stumbled upon a problem with my network gateway ECU when I attempted to reset the adaptations for my ECT in TIS. The reset wasn't completing even though it said it was when I attempted a reset. I performed a DLC3 cable check, TIS says the k-line and L-line are NG.

TIS DLC3 cable check under the "help" tab.
Moreover, when attempting to reset the adaptations, even though TIS says they're reset, there's no actual reset command from the main ECM. The only reason I know this is because the transmission still has hard downshifts from 4-3 and 2-1 after the problem was repaired (bad lock up solenoid). When checking the source of the K-line, it's actually the SIL line in the network gateway ECU.

I checked the error codes (on a whim) in the car to see if any of them align with this network gateway ECU. I had trouble codes under ABS, BCM (body control module), and Steering Lock. I thought I'd attack the network gateway ECU first, since this is not only a single line communication gateway, but also seems to reroute signals on the BEAN bus. I backprobed the SIL line while TIS was attempting to communicate with the gateway. I got this signal:

This looked like a valid signal to me. I uploaded the screenshot to Grok (X's AI) wondering why I'd get a K-line error if the gateway was toggling like this. Grok indicated that TIS was talking to the gateway as evidenced by the three long pulses followed by the two short pulses, but the gateway wasn't responding. Hence, TIS flags the cable as no good. I knew my connection to the gateway connector was just fine because I had my back probes in the connector.
My immediate response is to check power and ground to make sure the voltage to the gateway is good. I backprobed pin 10 and measure 3.8V. Excellent. All I have to do is restore battery voltage to the gateway, and my cable will check out good. Referring to the schematic above, Batt goes through J12 to the MPX-B2 fuse. It's by the passenger kick panel. I test it: 12V. Next, I check J12. Uh, that one's a bit harder to check and requires quite a bit of work. Nevertheless, I check it. I have to remove the nav unit to get access, but at least I'm able to do so. The following picture is of J11-17 which sits behind the Navigation unit.


Popping the tabs on the side, pulling the connector forward, and separating the part of the wire harness with J12, I've got the following:

J11-J17 pulled forward and flipped upside down.
J12 is in that disconnected junction. I check the voltage: 12V. Wonderful. All this work and battery voltage is just fine. J12 routes to the left of that harness, above the steering wheel, and down to network gateway ECU. After all of this wiggling and jiggling, I now have a BATT voltage (pin 10 at the harness) of 0V. It's no longer 3.8V. At this point, I check for any heat, vibration or corrosion signatures between J12 and the ECU. I cannot find anything. Peel the wire back and migrate as far as I can up the harness and test Batt: 0V.

At this point, I'm running a parallel wire from J12 to the ECU and soldering it in. I'm not taking any chances at this J12 oxidizing in the future and taking out battery voltage AGAIN so I remove the pins from the connector, solder a third blue wire with the yellow strip in parallel, and route it to the network gateway connector. I'm keeping the existing wiring in place just in case something else I'm not seeing is on that power line. So now, I've to 12.5V at the harness.

THIS IS WHERE THE REAL FUN BEGINS

I reperform another TIS DLC3 cable check: exactly the same result. K & L line NG. Wonderful. All this work has restored 12V at the network gateway ECU connector, but my gateway isn't responding. Little to do at this point but order another used gateway.
When the second gateway comes in, I plug it in and run the DLC3 cable check: K & L line NG. Hmmm ... two gateways showing the same problem ... I probably should go inside this module and try finding the bad component. Maybe an electrolytic cap has failed, or something simple like that.

The PWA (printed wiring assembly) comes out easily. Unfortunately for me, I don't recognize any of the circuitry and now have to hope Grok can help me with the architecture. I attach an external 12V source to the power pin 10, and ground to pin 24. I check voltages in Picoscope on both the top bank of 47uF 50V caps, and the two lower caps. All voltages check out fine. Stable 5V and 3.3V. A/C coupling shows a noise fluctuation of less than 50mV. Caps are fine but just to double check, I desolder all the caps on one of the two boards. ESR is fine on each one. Capacitance is fine on each one.

The tape on the ends allows me to keep the back side isolated from any unseen metal.
Now I need Grok's help to line up the architecture in it's LLM training with what I'm looking at to see if a component is the problem. It directs me to the transceiver. I probe it to IC7. It's an MC33290 transceiver. The datasheet is readily available. I solder back probes to the battery voltage pins. Solid. I back probe the RX (pin 4) and run TIS again. Communication proceeds through the chip and onto the MCU. The last thing to test is the TX line (pin 5). BINGO. The transceiver is relaying TIS communications, but nothing is being transmitted on the TX line. It stays at a solid 5V throughout the entire TIS DLC3 cable check query.
I can't find datasheets on any other components of this board. Absolutely nothing. Particularly the main MCU. It's a Denso MV4380. No source for another part anywhere. No datasheet anywhere. Again, I have to rely on Grok's help with the architecture. "What do I check now?" "Check the 4MHz clock to the MCU." It's X2, the large metal can right next to the MCU.

This is my clock. Less than 40mV and looks like hell.
Grok suggests replacing the crystal. WHAT THE HELL FOR? IT'S A PASSIVE DEVICE? I think I've reached the limits of Grok's assistance: it's great for architecture and inside it's training ground, not so much for specific fixes. On a whim, I check for any test points on the board. On the back side, I see TP602, TP102, and TP101. TP602 = 3.3V solid. TP102 = 5V solid. TP101 = 0V. "Grok, one of my test points is 0V. Is that a ground check point?" "No, it should be 3.3V if the MV4380 is within this family of devices. The 3.3V rails are separated but are sourced from the MCU. One is for the clock, the other is for internal and external devices." If you say so. This board isn't working so I'll try anything at this point to revive it.
Fine. I'm going to apply an external 3.3V to TP101 and see if anything happens with the clock. I wire up a little daughterboard with an LT1086-3.3 and solder the output to TP101. It's sourced from the board's Batt. I check the clock again.

Fully restored 4MHz clock.

Beautiful! Now, I think I've solved the problem which happens to be on BOTH of my boards but I've only tested this one. I'm not returning the second one anyway because of all the soldering and testing of the transceiver and at points all over the board.
I put it back in the car and run TIS. Same response: K line NG. Wonderful.
"Grok, is there something you have to do when the clock is restored?" "You have to reset the MCU. The MCU in this family line requires 5V on the reset line to get out of the reset state." OK, I'm not sure how this is going to help because I never lost 5V but OK, I'll try.
Grok: "Look for a line with an RC filter near a corner. It should be a 10k resistor and a 10uF cap tied to the 5V line." I'm checking all over the top of the board and cannot find this filter combination near a corner. Pin 102 on the MCU looks promising, but no dice. I flip to the bottom of the board, BINGO. I've got my filter. It's right next to TP102 (makes sense). Grok thinks the cap should be 10uF. I say this tiny little 402 is 0.1uF. He thinks the components are cracked/heat cycled, etc. Not under my microscope. They look pristine. I'll check the tau of the RC filter just in case.
[img alt="tau of RC filter on reset line (pin 65)
"]https://cimg5.ibsrv.net/gimg/www.clublexus.com-vbulletin/1919x1031/tau_of_mcu_reset_line_1d0ca72de317e6486328d6f327bf9303a71e2924.png[/img]
tau of RC filter on reset line (pin 65)

The reset line is not my problem. It ramps to 5V in 1.22m sec.
"Grok, the reset line is not the problem." Grok: "Send it in to Tanin, SIA, Upfix. You've reached the end of the road. There is nothing more you can do. Let the pros handle it." "How are they going to get MV4380 microprocessors, much less program them?" "They have proprietary tools, the Denso programmer, and the files necessary. Spend the $200-300 to get the MCU replaced and reprogrammed."
Fine, I'm at the end of the line. I don't know what else I can check. I call the three places. "We only fix the main ECU with transmission shifting issues." OK. Grok's wrong and sloppy again. Great in his training, terrible at individual solutions but helpful in my case.
Oh, I forgot to mention. I bought TWO MORE of these ECUs off Ebay hoping one of them would fix my problem in the interim. Both had 0V on TP0, and were non-responsive to TIS.

Conclusion:
(1) If you have a network gateway ECU issue (which I happened to stumble across BTW), it's real easy to test. You can save yourself so much time. With battery voltage (12V) applied to the connector and checking TP101 with a multimeter, you'll know IMMEDIATELY if the MCU is dead due to a prolonged undervoltage condition which killed the MCU's internal voltage regulator which is required for the 4 MHz crystal. My guess is that even though I've restored the clock with an external source, the internal PLL in the MCU die doesn't ever see the clock because it doesn't have power. Thus, even though I see 4 MHz, the MV4380 upscaling multiplier does not. This is just a guess.
(2) I believe Lexus had a latent manufacturing defect on the BATT line to the network gateway ECU that would only show up much later in the car's life. FOUR SEPARATE NETWORK GATEWAY ECUs FAILING WITH THE EXACT SAME PROBLEM??? FOUR SEPARATE CARS??? This undervoltage condition doesn't set a check engine light but a full system scan would reveal ECU communication issues. By then, it's too late. The MCU is already dead.
(3) Replacing electrolytic capacitors will do you NO GOOD. They're fine. They're within spec. A measurement of the voltage rails at the electrolytic caps will confirm this. It's that absent 4MHz clock that is the problem.

Hopefully, this process and it's conclusion will help someone save ALOT OF TIME.

 

I forgot a photo of the actual network gateway ECU location:

Network Gateway ECU located just above the emergency parking brake.
I pulled the cable from above to start testing donor replacements quickly because all of them test NG in TIS.

 

Well that is quite a bit of detail however I have no idea what was the actual issue/problem is or what you are trying to fix?

 

I was trying to reset my ECT (electronically controlled transmission) adaptations. I fixed the hardware problem problem could couldn't reset the adaptations until TIS saw not only a good CAN bus but also a good K-line (SIL as it's marked in the factory EWD or electrical wiring diagram). That's from the first image in my opening post.

As an aside, I learned through this process how a person would suspect their network gateway ECU was non-functional without a scan tool. If you have an overnight battery drain issue like I have had, it likely means your ECU isn't putting the devices on that SIL chain to sleep. Thus, your car will be draining around 400mA rather than 15-20mA after 30 min. If your car is going through batteries faster than normal (i.e. 6 months rather than 3-5 years), you likely have a network gateway ECU issue.

These are devices on the SIL line.

More SIL connections
If the network gateway ECU isn't working, these are just a few of the devices that won't be put to sleep. Hence, what a mechanic would see as a parasitic drain issue is actually a network gateway ECU issue. It's counter intuitive because a mechanic with generalized knowledge would be tracing a parasitic drain by pulling connections from modules. Drain drops from 400ma to 20mA, there's your bad module. R&R. Unfortunately, that wouldn't fix the problem in this case because the modules were never being put to sleep in the first place.

 

You have extremely advanced diagnosis skills, I enjoy seeing this content on CL. I don't mean to offend when I say this but have you checked the large surface mount resistors on the ECU? Usually reflowing the solder on those resistors fixes the shifting issues on 6 speed cars.

 

No offense was taken. Sometimes, solder joints crack with the heat cycling over time. It happens. Before I'll reflow joints, I typically want to understand the system and what the various components do. By understanding the system and using a scope, I can see right off the bat if there is a solder crack. In this case, the network gateway ECU is a critical component in both the BEAN and MPX bus as the schematic shows from the service manual.

For example, the main ECM may have hard downshift problems (which is very common on these cars). You can pull the board and start reflowing, but that's a BIG BOARD! Takes alot of time under a microscope checking all of the different SMDs, but why do this when I can put a scope probe on S1, S2, S3, and S4 solenoids and take the car for a test drive? The scope will tell me if the shift solenoids are shifting properly w/in an hour. Then, I've saved 2 days and don't have to waste any time reflowing anything on any of the shift solenoid circuitry if transitions are clean, and after transition, voltages are stable. NO NEED TO REFLOW! NO TIME UNDER A MICROSCOPE! YES!
[img alt="S1 = Ch1
S2 = Ch2
S3 = Ch3"]https://cimg8.ibsrv.net/gimg/www.clublexus.com-vbulletin/2000x1081/s1_s2_s3_b5e9ac222a34deb13dfe8fbdfaba3b4e01edab22.png[/img]
S1 = Ch1 S2 = Ch2 S3 = Ch3
This is an example of the voltage on S1, S2 and S3 solenoids. They're all shifting properly. Full stop, I'm done, I'm not reflowing any circuitry in S1-S3. All shift transitions are clean. Moreover, since voltage is stable at +12V in each case, I know my electrolytic caps are good as well. I don't need to pull the board and look at anything. My scope has already shown me S1-S3 solenoids or their drive circuitry are not my problem.

The important take away is that by immediately reflowing components, you take lots of time looking under the microscope and touching the board with an iron hoping to stumble across the problem. By pulling out a scope, backprobes and taking a test drive, you'll know immediately where the problem is. If there's cracked solder joints on S2's circuitry, but nothing on S1, S3 or S4, I'll see it on the scope and know which circuit to target rather than trying to tackle the whole board.

The network gateway ECU is a very small board so checking all of the components with a microscope on both sides doesn't take that much time. Less than an hour probably. However, in this case, the crystal was dead as I show in the first post. Thus, there was no need to reflow anything. Without a clock, the MCU (micro controller unit) won't do anything. It requires the clock edge to synchronize incoming data, reframe it in MPX or BEAN form, and put it out on the MPX and BEAN bus. I'm guessing here because this is what the AI Grok says and there's no literature on the internal function of this module. Thus, a mechanic would say "I've got battery and ground, the module isn't talking to Techstream, replace the module." What do you do when all of the modules are sold out at the dealer?" What to do when every used module has the exact same issue: no clock? You can restore the clock, but that doesn't bring the MCU back to life most unfortunately for me and I cannot buy an MV4380 anywhere, much less reprogram it with Denso tools.

No offense was taken at all. I put this up because it's taken me weeks chasing this problem ON THE BOARD ALONE because there is no literature on the guts beyond whatever Grok has been trained on. I was hoping that the next person who had this problem could get to root cause in 2 hours rather than in weeks. If there's a potential gateway issue, make sure pin 10 has 12V, backprobe pin 7 on a cable check in TIS and if you've got the same response I did, check TP101. 0V? You're done, full stop, the 4 MHz clock is dead, the MCU is toast, start ordering donor units.

 

Ch1 = S1, Ch2 = S2, Ch3 = S3
Not sure why the image didn't post in my previous post.

 

Here's the kicker for me. No matter how many times I clear the codes, I cannot get rid of the following. I clear them, turn the key on, and they're back. Here's is Grok's summary and notice, NOWHERE IN THIS LIST, OR ON MY SCANTOOL IS THERE ANYTHING ABOUT A NETWORK GATEWAY ECU ISSUE:

 

In over 30 years in my repair business there were times I dealt with a new bad part and diagnosed again and said it has to be that chip and received another and did not fix. Always found external to chip being problem after confirmation was not chip. Of course I was dealing with new and you used but having 4 doing the exact same thing makes me think it is external to board. What I would do is try and find one in a salvage yard and not on ebay to try. There are even posters here that are currently pulling an engine out of one to put in another that most likely has that board. Not saying you are wrong but having 4 do exact symptom is suspect. One other thing which is common for the LS430 is for the rear tail light to leak and the fuse box in trunk left wheel well is affected and can cause a lot of different problems. Check to see if any water damage at all on board to verify. A lot have had to replace whole board. Just a thought. Good luck.

 

Love to believe it. No clock? I restore the clock but the MCU still won't talk? On all 4 boards? I've got a 5th coming next week. If that doesn't work, I'm punting and will either prototype a new board (lots of work) or ...

I agree with you. I thought with the second board I was doing something wrong until I saw no clock on the crystal, yet a pristine 4 MHz sinesuid with 3.3V applied to TP1.

 

On a newly wrecked car, I could check this in 5 min now. Simply hook up a breakout box to the DLC3, turn the key on, and run Techstream and do a cable check. If I get no response out of the breakout box like in the first post on my scope, and I get cable not good with Techstream, I know that gateway is dead like these 4 others. They all react the exact same way. No response.

I think there's a latent defect in these cars creating an undervoltage condition silently over the years that is killing all of these gateway ecus. I'd never believe I was saying this but for that damn clock signal being completely absent in all 4 boards but yet, I can restore it no problem.

 

It would be nice to see diagram of internal of that chip and that would tell a lot but no go. Generally reset will start clock but chip could be waiting for a signal to start. The reset just resets the micro. From your posts you are thinking the internal voltage regulator for 3.3v is bad. I have made crystal work also by voltage but never made the chip work as there was always something else internal or external to chip. Where is the next board coming from?

 

There is an engineer from Japan that is in this forum that is quite knowledgeable with this car and hopefully he will see this and chime in.

 

So Alextv, you've been down this road before? You've done the same thing I did, with EXACTLY the same result. I'm not surprised with these four bad boards. I wish Grok would have pointed me to your post ... it could have saved me ALOT of time. The only things I know for certain about this module are (1) about the transceiver (IC7) because the datasheet is readily available, (2) that there are no datasheets on any of the other ICs on this board EXCEPT for this large transistor on the top whose number turns up as an an audio amplifier, of all things. I think it's a mix up even though the package is the same. It's in a section of the board that seems to deal with the MPX and BEAN bus so I don't know what it does.

Grok claims this family of MCUs has a reset line. What does it matter if it's tied to 5V? That rail isn't my problem, and there are no other voltage regulators I can find (3 pin anyway). The chip must be reset? 5V comes up immediately if the RC filter tied to pin 65 is to be believed. The TX line is tied to the MCU line 102 directly, and through a 10k resistor 5 pins away on the next side of the IC. I've had to completely rely on Grok's conceptual data to even get this far. How could I initialize this MCU? I thought that's what the reset line was for but maybe not.

I'm really uncomfortable creating a breadboard with a modern MCU, taking AI generated code with no specs, and trying to talk on this BEAN or MPX bus. What if I reframe an SIL hex 55 on the MPX bus and the air bags deploy? The more I think about it, the more uncomfortable I get with trying to prototype this board. It would be really simple too. All I'd need are level shifters (12 to 3.3V and 5 to 3.3V) but w/o any personal knowledge of the frames? Moreover, based upon an AI which has given me not so great specific information but exceptional conceptional information?

Next board's coming from Ebay. Four wrecked cars from four different resellers all with the same result: no 4 MHz clock. I can only guess a low BATT on the input to the device is killing this MCU.

 

In the sixth image in the first post, IC3 (next to the MCU) is supposed to be the eeprom that stores the adaptations. Maybe those are the adaptations for the zero point or something on the MPX or BEAN bus? W/o a CAN but input, I know the main adaptations for the ECT aren't stored there. No point. Put those on the main ECM. Even screwy or corrupt adaptations shouldn't preclude the MCU from at least attempting to transmit something on the TX line.

Those two pads right next to IC3 with the silkscreen "S" and "G" are supposed to be the JTAG connector for programming the MCU at the factory. According to Grok, it's a one time programming, and if you try to decode the file, it locks up the chip forever with hex FF. I haven't tried that. I don't see a point if the PLL inside the MCU is dead/cannot be revived regardless of what I see on the crystal.