Damage from no recirculation diode?

[bigwheels6]

I have built and installed a GPIO/megashift controller to a 4L60E and I neglected to install a recirculation diode and associated resistor in the pressure control solenoid circuit. After several tuning runs, the controller seems to have lost the ability to see the three input signals (switchA, switchB, switchC) from the pressure manifold. I have tried grounding the three individual wires at the ampseal (25,6,26) and I do not see the signal go low on the tuner studio display. The GPIO is connected to a MSII through a CAN, and all of the other inputs, from the MSII and directly into the GPIO work properly. I had been going over the build and install instructions to diagnose the input signal problem when I found the note about the recirculation diode installation.
I was running v4.145 code when the problem occurred and updated to v5.201 in an attempt to fix the input sensor problem. The update introduced a problem with the brake signal. It sees the brake when on but oscillates from brake on to off when no brake signal is applied. The problem of not seeing the input switches go low when grounded persisted.

My questions-
Does anyone know what damage is likely when running a GPIO/megashift on a 4L60E without the recirculation diode on the pressure control circuit?
Does anyone know the next diagnostic move with a controller that doesn't recognize these pins (25,6,26) being grounded?
Thanks for any help!

[Bernard Fife]

bw6,

It's hard to say what the damage could be from not having recirculation diodes in place. It could certainly do bad things to the I/O ports. I haven't done it myself, and the few people who have seem to have gotten away with it for brief periods.

The first thing I would do is make sure the code wasn't corrupted and is now using a variable voltage input for the shift lever. For more information, see: http://www.msgpio.com/manuals/mshift/V5tune.html#i

The next thing I would do is use the input test mode (in 5.110+ code) to check that the code is recognizing the inputs correctly (i.e. that this is a hardware problem and not a software problem). There have been recent changes in this area that might affect you, but if it was working then that seems unlikely. In any case, it costs nothing to check. If you do check, try to get a datalog to post, as we might be able to tell more about what is going on. An MSQ file of your parameters would let me check you setup here too.

[bigwheels6]

Thank you Lance.
The first thing I checked (when the old code was still running) was the setup of the input lever configuration. It was and is still setup for GM digital switches. I even tried raising the digital voltage threshold from .9 to 1.9 to see if that would get the signals to go low. After grounding the pins at the ampseal and getting no response I began to question the integrity of the code as well, thus the firmware upgrade (which only introduced the brake input problem, the brake sense was working properly up to this point).

I will check in test mode to see if the inputs can be changed manually tomorrow and capture the data you mentioned. I'll try to get it posted tomorrow as well.

Another thought- when I first purchased (DIYautotune) and assembled this kit 3 or 4 years ago, I encountered some trouble while attempting to load the initial firmware onto the board. The resolution was for me to send it to you (Lance) via post, and you returned it a couple weeks later saying that it was missing some code that enabled the firmware loading process (perhaps you remember). I was able to complete the build and the box didn't have any further issues until most recently (this project sits on the back burner. I finished the rest of the car a few months ago and started the initial tuning a few weeks ago) It worked properly for about 20 miles worth of tuning sessions before the switch inputs suddenly stopped working.
I'm not sure if this relates, but it seemed worth mentioning.

[Bernard Fife]

bigwheels6,

I do remember that we had to burn the bootloader onto the processor, as this had apparently been missed at the factory. That was a while ago!

That reminds me of something else that *could* be a problem. If the board was built a while ago, it is possible that it needs a good cleaning. This can be because of accumulated dust, etc.; but more likely because of residual solder resin absorbing moisture from the air and becoming somewhat conductive. This was an issue with early MegaSquirts (almost 15 years ago!) where various I/O would work perfectly on assembly, but then start acting up months or years later. It took us a while to figure out what was going on.

So if this was mine, I would wash the board by lightly brushing it with an old toothbrush using 99% isopropyl alcohol (rubbing alcohol), and you can lightly scrape off any resin you see with a toothpick. Then rinse it in hot water, then let dry it thoroughly (with compressed air or leave it overnight before powering it up again).

[bigwheels6]

Well the issue convolutes further-

I sustained a bit of a brain injury during the period after building this car and I have a new habit of forgetting things. I peeled into the harness and found a recirculation diode and a heat sunk resistor right where they belong although I can't remember doing it. So now I'm back to no real root cause.

I have attached the .msq file. No real tuning here at all. I just updated it to the 5.xx firmware and it seems to have lost a few things. The PC table looks like it reverted to baseline, and it gives an error notification when I open tuner studio and it connects. This is new behavior, along with the goofy brake signal, but the original problem with the shift lever inputs carries over from before.

During the datalog session I go into test mode and then cycle the three switches and the brake input. Switch A is nonresponsive while the rest do as they should. I do notice that when I replicate the input signal for Park, it sees it and gives me the correct feedback. The brake signal goes high and low irradically except for the end of the session where I apply the brake a few times (after leaving test mode) and the signal stabilizes in the correct state.

I did take the time to coat both sides of the board with several coats of clear lacquer after cleaning it, when I first assembled it, and it doesn't show any signs of visible corrosion. Do you think a cleaning might still be helpful?

Thank you once again,

2016-02-22_15.43.45.msl

(367.17 KiB) Downloaded 536 times

2016-02-22_15.46.30.msq

(62.04 KiB) Downloaded 690 times

[Bernard Fife]

bigwheels6,

My condolences on the brain injury - they aren't a lot of fun.

I will have a look at the datalog and msq when I get a chance.

If the lacquer is still in good shape, then you probably don't need to clean the board again, but if the lacquer is cracked or peeling anywhere, I would definitely give it a scrub.

However these issues do seem more like electrical problems than anything else, and I wonder if the board is getting the full supply voltage. If the supply voltage dips below 9 Volts or so, the ADC can start to act very oddly, reporting higher voltages as the supply voltage drops, and this can be very confusing. It's compounded by the fact that you can't relay on the MShift voltmeter to report/log the voltage correctly. So if you have a digital multi-meter laying around, you might want to check the supply voltage (at the source and at the regulator on the board).