MSgpio.com read only forums (Jan.15,2018)

Oops - forgot to pull the PC solenoid fuse today when uploading new code for my MShift - 4L80E transmission late style solenoid.

What am I likely to have fried? The solenoid or something on the board?

This is the result of getting angry after the GPIO code was corrupted again for no apparent reason. At this rate I'm thinking about ditching it and fitting a different controller as it's getting to be more hassle than its worth

What am I likely to have fried? The solenoid or something on the board?

Probably neither, but there's a chance it could be either. You have to test both.

it's getting to be more hassle than its worth

Then it is time to switch for you.

Ok, thanks Lance. Guess the only way to find out is hook up a pressure gauge and test?

The most annoying thing is that it seems so easy to corrupt the firmware, and I don't really get why.

Today it was the result of a quick power up then down while I was messing about. After that when I powered up again all of the settings were messed up. Reloaded the MSQ but the temp readings were screwy and inputs were flicking on and off or not working. Reflashed the code and loaded MSQ and its fine again now.

Weird.

Flak Monkey,

In thousands and thousands of hours of testing, I have *never* corrupted the firmware (and only corrupted the user parameters if the board was powered down during a flash burn).

In the reports of others, though, this seems most likely to occur when MShift is being used in pass-through mode from non-B&G code. Even then, it only seems to occur (I understand) when burning new parameters to the MShift code, not while doing normal running, etc. So it seems there is something (likely minor) in the non-B&G code or TS that doesn't properly handle the flash burns on the pass-through all the time. So I recommend those using non-B&G code to connect directly to the GPIO board using its serial port when changing parameters or tuning the trans behavior.

The other possibility is that your serial hardware is noisy (electromagnetically), or failing. Either of those can cause all sorts of issues, of course.

Lance.

Thanks Lance - this isn't the first time it's happened to me, generally as you say it's been during settings changes. Today it was a power up/down cycle within a couple of seconds that corrupted it.

What you describe could be the case, I'm connected to it via CAN through my MS3 so that might explain it. I can easily connect directly to it for tuning though as I have the serial cable plugged in. I'm using the USB connection on the MS3 for comms. I initially struggled to get the CAN working, but reloaded the firmware on the GPIO and it started working straight away, so I've left it alone since.

I never remove the fuse on the 4L80e.
I think it is the same kind of solenoid and wiring as the 4L60e so it is OK.
And everything is still working correctly today after a lot of code loading.

For the code corrupting, when I make only little changes, it was OK to go through the MS3. but I often had problems when loading the complete msq just after a code update.
When I use directly the serial port of MSGPIO, it is OK.

Thanks. That's reassuring to hear. I'll have to see if it works when I get the motor running. I've never used the transmission - I've just completely rebuilt it with a load of trick bits from Jakes and PATC - so it'll be interesting

So what do you normally do? Make the changes via the serial connection and then when you next connect via CAN just click the 'use controller settings' option on the difference report that pops up?

No, I nearly always with CAN: for datalogging of very small parameter changes.
When I make a code update, I connect directly to the MSGPIO serial port. I connect with Tunerstudio, get the last msq and save it.
Then I close tunerstudio, I update the code.
WHen it is done, I connect with tunerstudio again and load the msq saved just before. I check that everything is working fine.
then I connect again on MS3 USB port, with CAN, I update the ini file for the CAN device in the project propoerties, I keep the settings from controller if the difference report sees a difference.
Normally it should be OK.
When I updated the settings with the difference report via CAN, I often got problems. (maybe I also did not wait long enough to shut off the car: the MSGPIO takes longer to burn than the MS3.)