MSefi.com read only forum (Jan.15,2018)

Good morning to all! I figure my first post should have at least a little substance to it....

First, thank you to everyone! As a professional "lurker", this board has helped me many times in my MS project.

Back ground: 1984 Jeep Grand Wagoneer, 5.9L V8, carb to TBI, first squirt Jan 2011 on a V2.2 MSI running MSI/Extra fuel only. Has been a stable platform for daily driving since. I decided to upgrade to the MSII daughterboard and take advantage of the IAC stepper and start controlling spark. Hardware install of the board went like it should. Jumpered 12v, Ign, IAC circuits. Plugged it in to the car for a checkpoint - connection was solid, loaded MSII firmware V2.905, checked IAC stepper function - fine. Then I mounted the ECU back into the car and began the under hood portion off ignition control....

After finishing the ignition hook-up, I plugged the laptop in and opened Tunerstudio - "A controller has been found but there is no firmware loaded"

Hmm...

Laptop details: MacBook 13", 2.13GHz dual core, 4Gb RAM, VMWare running 64bit Windows 7, Gear Head USB/RS232 adapter with their driver installed. I use this laptop for work and connect to various components via the same serial/usb connection...

Now this is the same computer used for the MSI install, and the same used for the IAC stepper testing - not 3 days ago. So I tried a second USB/RS232 adapter, loaded fresh drivers from FTDI and attempted to upload the firmware again. This is where it gets funny....

On the MS Downloader, upon opening the firmware file, MSD/l can read the controller, identify the existing firmware, erase the memory and begin loading the new firmware. HOWEVER, between 17% and 22% completion, MSD/l will become unresponsive, window will freeze and I wait. About a minute later (literally 50 to 70 seconds), MSD/l unfreezes, loads the completed tasks and shows a successfully upload - a split second later "ERROR: command not recognized e=0xE1". (Normally when an upload freezes like that one of the values in the code is off, but if that were the case than it would freeze at the exact same time i.e. 20%)

Here's an example of the situation I pulled from this post: viewtopic.php?f=31&t=40397&hilit=error+command

""MegaSquirt Download 2.00

- Reading C:/Documents and Settings/User/My Documents/Downloads/Monitor_v2.905.abs.s19:
- Detected MS-II (HCS12) code.
- Entry point: 0x0000
- Code range : 0x4000-0x3db360
- File read successfully.
-
- Opened comm port 8 at 115200.
- Erasing main FLASH:
- Erased.
- Writing:
- Setting page register 0x3c:
- Page set.
- Erasing page 0x3c:
- Erased.
- Setting page register 0x3d:
- Page set.
- Erasing page 0x3d:
- Erased.
- Write complete, 1467 records, 46849 bytes.
- Verifying:
- Setting page register 0x00:
- Page set.
- Setting page register 0x3c:
- Page set.
- Setting page register 0x3d:
- Page set.
- Verification succeeded, 1467 records total (4 skipped).
- Elapsed time: 49.83 seconds
- MegaSquirt Download 2.00
-
- Reading C:/Documents and Settings/User/My Documents/Downloads/Monitor_v2.905.abs.s19:
- Detected MS-II (HCS12) code.
- Entry point: 0x0000
- Code range : 0x4000-0x3db360
- File read successfully.
-
- Opened comm port 8 at 115200.
- Erasing main FLASH:
- ERROR: Command not recognized, e=0xE1
- Elapsed time: 0.47 seconds""

Now I read Grippo's response "ignore the ERROR e=0xE1" however when connecting to Tunerstudio, "a connection is attempted 3 time, unable to find all data, TS will now go offline", but connecting to Tunerstudio results in "3 connection attempts made, unable to read all data, TS will now go offline"

(yes the com port setting are correct)

SO.....

I know this is a dense post, but for those who stuck with me, this is what I've attempted as a solution:

2 different USB/RS232 adapters using both FTDI and Prolific driver.
Restored VMWare Windows to the date and time TS could connect and tune successfully
Scrubbed the board with alcohol (we had a couple humid days, and the manual said flux can be an issue)
Tried several different versions of the firmware along with several downloads of the latest V2.905

I'm not looking for an end-all solution, just some ideas to kick around. I would like to get this damn thing on the road....

Should I attempt to plug in the MSI processor and load MSI/Extra?
I'm weak in electrical circuit analysis, is there a specific component to test?

Thanks again everyone, I wouldn't have made it this far without your help!

BJR,

MS-II operates at 115200 baud, MS-I at 9600. As well, the MS-II code is *much* larger. So any weaknesses in your serial comms are much more likely to show up in MS-II.

That being said, you only need to load the code successfully once and it should be fine after that. This may take several tries. I know it did for me with some of the usb/serial hardware adapters I have tried. So try it repeatedly until you get the verification successful message, then stop and try to connect.

There are other comm tips here: http://www.megamanual.com/connect.htm

Lance.

Ah, thank you!

Exactly the page I need to be studying!

I knew the code was larger in MS2 - never thought the "size" would be a factor with the communication, and it appropriately explains the freezing of the boot loader at different percentage completion.

I'll be hooking the meter up to the DB9 connections as soon as I get home!

Ok, after much studying and testing, here are my results...

(all of this testing was done with the same hardware and software configurations the previously had perfect connectivity uploading V2.905 firmware and adjusting parameters in TunerStudio. The system used was also restored to a date before the last working session)

Upon measuring voltage and continuity as outlined here (http://www.megamanual.com/connect.htm), all components checked out with 4.99 - 5.00vdc or 0.000 - 0.003 Ohm. Except for.....

DB9 Pin 4 to DB9 Pin 6 does NOT have continuity
DB9 Pin 7 to MAX232 Pin 8 does NOT have continuity
DB9 Pin 8 to MAX232 Pin 7 does NOT have continuity

I reviewed the PCB layouts and it doesn't look like any trace connects to DB9 Pin 4 and 6 through 8. But than again, PCB and electrical components is a bit of a weak point for me (it's why I bought an assembled V2.2 board in the first place!)

Despite these discrepancies, MS Downloader successfully loaded firmware V2.905 without freezing or error. Log attached (MSDl Log File)

I concluded that one of the original issues uploading firmware was an under voltage to the ECU during transfer at <8.5vdc (thank you Lance!). From the time I used 13+vdc, each session loading the firmware resulted in success.

The trouble comes when I open TunerStudio.....TS prompts immediately with "Firmware signature mismatch" - even though the project has the correct description and .ini file. Attached is the screen shot of the exact error message. It took me a second to notice what was out of place - the Controller Serial Signature is MS2 Rev 2.905, except where there should be a "5" is a strange character - almost what looks like a German "o" with two dots above it? (Umlaught?)

Weird right? I attempted to change the controller definition and received an incomplete error message. I can't really explain it - it's attached.

So I went on my merry way re-loading the firmware with a verified success. Opened TS and I receive the same error message, this time the Controller Serial Signature is MS2 Rev 2.905 - exactly the same as the project! (with no weird characters this time) Screen shot of this attached as well.

On the second time around, I chose "connect anyway" after which the controller would go online for a brief second, load no parameters and go offline. It would do this three times than prompt it was unable to retrieve all data needed and would now go offline.

I also reinstalled TunerStudio just for the heck of it (with no difference). I know this is a lot of information but at this point I'm leaning toward the MAX232 (U5) being an issue, but if there was a problem with a communications component, why was the firmware loaded successfully (and verified) with MS Downloader?

So...Any ideas to kick around?

Three attachment maximum. This is the second firmware mismatch screen shot.

BGJr,

When the PC/controller will connect but then TS goes offline, it can often be a result of the INI not being right for the code (or the INI being corrupted). If this was mine, I would re-download the INI and re-install it. Actually, if it was mine, I would start a new project with the new INI (I would move or delete the old project folder, then follow the prompts when TS doesn't find a project the next time it starts up).

I had some issues with later versions of TS connecting properly (I downgraded to 1.004 from 1.14? to fix this), so you might want to check some of the recent TunerStudio posts.

If those doesn't help, and you have re-loaded the code, then it may be a hardware issue (or maybe the laptop serial port).

DB9 pins 4 and 6 don't need to be connected, so don't worry about that. DB9 Pin 7 to MAX232 Pin 8 does not need to be connected either, neither does does DB9 Pin 8 to MAX232 Pin 7 (the MAX232 is a dual driver/receiver, and these connections aren't for the second, unused channel). So those aren't the problem. You might check that the pins on the DB9 and MAX232 are well soldered and free of excess residual flux.

Also, have you tried another computer (if you have easy access to one) to see if the comms work better on that?

Lance.

Close - but no cigar....

So I tried several work arounds last night, and the connectivity to TunerStudio did improve, but still does not display input data. I cranked the motor a couple times and it appears that the controller is functioning, at least with some parameters - fuel was being injected.

Creating a new project, and using the correct .INI file freshly downloaded, unfortunately had no positive effect. TunerStudio continued to prompt a "Firmware Mismatch" identifying the controller signature incorrectly. Sometimes the "MS2 Rev. 2.905000" has all letters in the correct form, other times it only displays "MS2 Re" or a combination of strange characters.

Turning my "stubbornness" off, I heeded your advice and used an old Toshiba Satellite running Win 7 Ultimate. It still required the use of a USB/RS232 adapter, and having two, I tried both. This time I set the verbosity on the MS Downloader to the highest setting and waited the 160 sec. to complete. (I also turned the VCP buffer up a bit incase connectivity really is the issue). After this upload, I also downgraded to TunerStudio V1.004. Connectivity did change a bit. Now TS will no longer go offline (gauges stay bright constantly), however the waving blue bar up with the menu options displaying connectivity will stop every 4-5 seconds, freeze and continue moving. TunerStudio will remain in this condition. Attempting to adjust any parameter will freeze the pane, and I will have to close the program - although not force quit.

I did not check for flux residue on the MAX232. Tonight I will be removing the jumpers placed for the MS2, replace the MS1 processor and do a thorough inspection then. If I can recover the original condition of the controller, then I can compare connectivity and TunerStudio performance on a known working controller.

It continues to befuddle me when the controller was working and communicating properly to TunerStudio a week ago, and with no hardware or software change, a problem ensued. It would appear to be an environmental change. Maybe those two days between working and non-working (which were wet and humid) shorted something on the daughterboard? Maybe connection is ok, but not all of the data is remaining on the PRAM after a power cycle? If this was an issue at work, I'd simply throw parts at it, get the machine running and figure out the details later. Ah, but then again, this is my money were talking about!

Thanks again Lance, I'll post when I make progress.

-Brian

You know, I just read this (viewtopic.php?f=30&t=40379#p238424) posting and it brought some new thoughts....

The day that I first couldn't connect, powering the controller, all 3 LEDs lit. However, since I was unable to connect with TunerStudio, I tried boot loading the controller several times. Afterwards, with the boot loader not shorted, applying power to the controller only flashed the LEDs for a brief moment.

Taking the daughter board out of the 40 pin socket, cleaning the board and replacing MS2 resulted in all 3 LEDs shining bright when power was applied.

During all of my troubleshooting, the MS2 daughterboard has shown to be the least consistent component. Sometimes retaining the firmware and sometimes losing it when removed from the main board (prognosis based solely on LED function).

Very curious that another would have a similar issue.

-Brian

...Sometimes retaining the firmware and sometimes losing it when removed from the main board (prognosis based solely on LED function)...

BGJr,

I wouldn't make this assumption.

Also, it isn't impossible that it isn't the comms at all, but is a power issue. If the ignition LED flashes at a regular rate determined by the stim;'s tach pot at first, but then stops when the comms stops, a power isssue is more likely. Assuming your power supply is 'known good' (the wall wart style seems to fail irregularly, and 9V batteries are notoriously unreliable because of the relatively high current required by MS), you should probably check for that. See these tips: http://www.megamanual.com/ms2/V3trouble.htm especially tip #0 and #14.

Lance.

Lance, you were spot on. Power was the issue causing every problem. I went back across each circuit needing to have +5vdc and discovered that the voltage varied from +5.00vdc to +3.89vdc at U5, Pin 1 @ 40 socket, and everywhere else. I tested the +12vdc for the stepper circuit and it was sporadic, jumping from +.40vdc to +1.6vdc. Following the Raw 12v traced the issue to the 2 amp fuse. It was blown but since I cheated during install and used an old glass cylinder, it was not a clean break. Replacing with a new fuse brought a clean +13.5vdc to the board, and all the connectivity issues went away!

I assume that the capacitors held enough voltage to allow connection for a brief moment before being drained by the RS232, the connection would go offline, the capacitors would build up voltage again, and connect once more for a brief moment before repeating the cycle.

I always get a laugh out of the simplest problems that get so darn complicated

Thanks again for your help, I have a relay board on order and addressing my half-assed fusing is priority number one!

-Brian