MS3 with CAN pass-thru issues

[mill3833]

Here's something else that's curious...

Was going to investigate updating my MS3Pro SW, and figure I should do this with the wired-USB connection. But lately it has been un reliable. So have been using BT.

So just now, I connected up the USB (converter part of MS3Pro unit) and what happens (also did this with 4143 code) TS connects for about 1 sec, then goes off line, then connects, then goes off line. Today I let it go like this for a while. After about the 4th or 5th cycle, the "Can't connect with MSShift, going offline" message came up, and once MSPro stopped trying to CAN to MSShift, then USB interface worked flawlessly.

I will check to see how previous versions of MSShift worked in this regard and report back.

Dave

[mill3833]

These work with BT jsut fine, but MSShift CAN via USB issue affects:

4144
4143
4142
4141f
4141
4138t
4135

I then tried 5012. It too didn't work. But then I tried power-cycling the system, including TS, when it powered up, with USB, it registered another diff report, so, so send TS to MSShift, and then it worked !? So I tried repeating the process, with 4144. But now something's jacked up, and I lost my TPS load over CAN.

Dave

[Bernard Fife]

Dave,

I am not sure I follow this (I don't have an MS3 with BT or USB), but I do know that nothing has changed in the MShift CAN or serial code for a very long time (at least not on purpose). I don't even write the CAN/serial code, I get these as packages (several files) from Al (Grippo) and use them without changes to make sure I am compatible with other B&G code.

I just tried the CAN pass-through comms (MShift 5.012 with 2.920 on MS-II) and it all works fine on my bench - no TS dropouts at all.

If updating MS3 resulted in problems connecting, then I would have to guess that something in the code for MS3 has changed with respect to how it handles the CAN pass-through. If that's the case, you need to ask about this on the msextra forums.

The other possibility is that TS is dropping the ball at some point (possibly because I understand that MS3 no longer uses the exact same B&G protocol for serial comms).

BTW, I will ask the forum admin team to split this from the previous posts and move it to the TS sub-forum so Phil can comment.

Lance.

[Ap67et10]

I just duplicated your exact issue when I tried switching back to serial connection. I was running through USB and it would still drop out after anywhere from 2 mins of running to 10 min of running. TS screen would go grey then say GPIO was not responding and it stopped trying so MS3 could go online. I think I might try some different MS3 code to see if that changes anything. Currently I am running 1.3.1 beta 3 in the MS3 and 4.139 in the GPIO and I have TS v2.6.0.


Andrew

[mill3833]

Lance,

Just to clarify, I have not updated MS3Pro, ever. Was thinking about it, but then ran into these com issues. And its been down hill from there. The only input TS is reporting as a reasonable value is trans fluid temp, as it slowly returns to ambient as I'm left in utter frustration. Not even the Stop light input works any more.

Well, will look at it with a fresh mind tomorrow.

Andrew, let me know if you figure anything out.

Dave

[Bernard Fife]

I should do this with the wired-USB connection. But lately it has been un reliable. So have been using BT.

Dave,

Okay, if you didn't update the MS3 code, then it was the switch from a reliable bluetooth connection to an unreliable USB connection to MS3 that started all the problems? Unreliable communications can definitely cause corruption of data and even program code, and lead to the sort of problems you are seeing.

If that's the case, then I would switch back to the reliable bluetooth connection. However, first I would reload both the code and INI for each controller (by a direct serial connection on the GPIO board), as they have likely been corrupted. If it was mine I would start a new TS project to ensure a 'blank slate' too.

There are some aspects of the most recent B&G CANbus code I neglected to implement in the MShift code (most notably the CRC check function). So I will look at doing that with the code as soon as I can (a few days, I suspect), as it's not impossible that might be causing issues if MS3 is trying to use that function (though it would not explain at all to me why a switch from bluetooth to USB on MS3 would affect the MShift code).

Lance.

[Ap67et10]

I loaded 1.4 alpha 1 into MS3 and still found issues. I went back to USB and it would work for a little while but would eventually loose connection. I could guarantee connection loss if I romped on the throttle a little. I had a similar issue one time with a DIYpnp that was all related to the tuning cable. So I got my tuneup halfway decent and then ran it without TS connected, but got the same result where the GPIO would disconnect. I can tell when it disconnects because it won't shift anymore and defaults to 1st gear. Pull over cycle the key and its back online again for a period of time.

Based on what I see you just posted, I should probably reload the GPIO again, load up the tunes I have and test without ever connecting TS when running?

I also didn't think about compressing the TS debug file...so here it is. I am absolutely useless when it comes to code related stuff, so I don't know what it says, but I did see where it shut down CAN.



Andrew

[Bernard Fife]

I should probably reload the GPIO again, load up the tunes I have and test without ever connecting TS when running?

Andrew,

I wouldn't load the tunes, at least not the MShift one, as it is likely corrupted from the comms issue. You should recreate the MSQ by entering the relevant setting by hand into TS.

I can tell when it disconnects because it won't shift anymore and defaults to 1st gear

MShift doesn't necessarily need a connection to shift. So even if the CANbus comms weren't working at all it I believe should still shift the trans (it wouldn't show up in TS, but you ought to be able to feel the shift). So if it is getting stuck in 1st, it is likely that something else is going on, such as firmware corruption due to bad comms (rather than no comms).

BTW, I will work today on the MShift comms to see if there is anything wrong there.

Lance.

[mill3833]

I wouldn't load the tunes, at least not the MShift one, as it is likely corrupted from the comms issue. You should recreate the MSQ by entering the relevant setting by hand into TS.

Lance,

Good advice. Unfortunately, I'm not as familiar as I should be with where everything is stored and what's vulnerable to corruption. I can tell you I've never reconstructed an MSQ from scratch, always uses the TS version. And I know I've had corruption, as I've accidentally cycle power before burn was completed. I'll give this a try with a clean MSShift bootload, clean project, and clean MSQ.

Dave

[Ap67et10]

Ok so I have some more info. I think I found out my main issue with the coms dropout and getting stuck in 1st.

First thing I did was reload firmware into the GPIO through the serial. Then made sure everything was set up properly with MS3 and then hooked straight to the GPIO to log. Everything was working great until the screen went grey for a min, then came back. All CAN info was back on and looked fine, but it wouldn't shift again. Then I realized I had lost my OSS input and showed no speed. I'm assuming this is noise related, so I tried a bunch of crap and still had the issues. I have noticed that it seems to work well for a while then as the vehicle gets hot, and sits in the sun (its like 95* F here today) it just gets worse and worse. I couldn't go more than 5 seconds after a reset before it would lock up again.

The thing that gets me is that now I have the OSS input coming from a Dual VR sensor which also has my front wheels speed input to MS3. That signal has zero problems at all, yet the OSS signal is apparently having quite a few. I'm thinking a good option may be to route the OSS into MS3 instead then pull it from CAN? The main thing that I suppose may be an issue (which was a concern when I set it up, but figured Id at least try it) is that the Dual VR board is powered by MS3 5v and grounded through MS3 SG. The VR inputs go to the board then digital out goes to GPIO. I'm not well versed enough in computer electronics to know if I caused a noise nightmare by doing that though??

Here is a datalog of GPIO when hooked right to it. I also went to 5.015


Andrew