NefMoto

Okay, I already count this as a loss but more or less I need to see if this has happened to anyone else.  I will break it down in the steps it happened to try and make sense of what happened.  Hopefully if a root cause is isolated others can avoid wasting boxes...  lengthy but i want to explain what happened.

I was editing 2.7t M-box code for my car, I messed with KFMI_UM, corrected CS with the MTX plugin through tuner-pro as always.  It gave confirmation as always and thats when the weirdness started.

So generally when i shut down tunerpro out of habit i will hit save on the file again then close the bin and close the program, what caught me as odd was that once again it said CS corrected, even though it should have given the message that no changes were made and that no CS were corrected since had just saved it previously.  That threw a small red flag, so I closed tunerpro and re-opened it.  Same thing.

So i sent the file over to my other laptop, same thing.  Just kept calculating CS at save which wasnt huge cause for alarm to me, just odd.

I put it into me7check and EcuFix, both reported it as good.

I flashed it with the nef tool, uneventful, completed, disconnected, great.

I go to do a TB adaptation and clear codes, cannot connect to the ecu through VCDS, cannot connect through nef, start trying every tool ive got, no connections.

Pull ecu, reset power, reconnect and attempt to reflash with nef, I can connect but cannot do anything.  Cannot get boot mode.

I notice the throttle is cycling over and over, every second, non stop if the key was on.  On a whim I decide to try and crank it over since at this point im thinking the ecu is toast anyway.  To my surprise it fires up, runs for 3 seconds and dies.  I do this 2 more times and then try to connect again hoping maybe i had reset whatever the hang up was, nope.   Decide I am done messing with it and go grab another ECU.  As I pull out this troubled one its hot, it smells... I let the smoke out.

But how?

I changed the file back the the last known good version.  I edited KFMI_UM back to stock and the CS issue stopped and everything still appeared normal.  Flashed that to a new box, everything went normal and car was back to life.

So in the end I guess I am just curious WTF just happened.  Did editing that one map really cause all this or was it a fluke?  I have killed ecus with bad checksums and grounds undone, but never like this.

Edit: added 3 files, one normal, one with just one line of KFMI_UM edited which causes the tuner pro CS save glitch like yesterday and another that is a problem file that has been run through winols instead.

Hardware problem. Just a coincidence I'd bet.

From my experience with the MTX plugin is that it has issues when you edit certain TQ variables... It says the CS is corrected, but in reality it is not correct.

I always double check with OLS after editing w/ TunerPro & MTX CS PLugin and when TQ variables are edited OLS will find that the CS is incorrect and correct them.

I've bricked my ECU a few times on the road due to this until I realized what was happening.

I can see this, but he's saying the ecu was physically hot and smoking. I really doubt it had anything to do with the file that was on it at the time.

Wasnt fully smoking but def hot and had the distinct smell.  This only came after i tried to start it up.

On the TQ maps and CS, wouldnt me7check or ecufix (whittakers) catch that?

If you want to post the files (or email them so noone misappropriates your work) I'll look at the csums with winols. I've seen quite a few m-box's that mtx and me7check reported as good that still had errors.

I am going to mod the file back and try to replicate the CS save issue then send it over.

I have winols also, but never use it.

I just came across some code that appears, at a quick glance, to be doing some kind of check on the _UM variables themselves. I haven't really spent any time on it though.

That doesn't explain the behavior of the MTX plugin though.

Maybe the ECU got stuck in a infinite reset loop that ended up overheating something?

Not exactly productive to this discussion, but why did feel the need to change the _UM map?

I had an ecu recently that was stuck in a programming loop. No matter how many times you flashed or reset the power it would always read THIS IS THE RAM PROGRAM with vcds. Not that it's relevant, but it was curious nonetheless.

I had some issue one time, its wrong CKS.

Correct same file cks with WinOLS (I had it before with MPPS and ECM2001) made an Boot in ECU and everithing was fine.

Are you talking about that other multipoint block you found? If so, ME7Check doesnt check it!

I was just playing with TQ stuff, I still get interventions now and then and the way i understand that map is that it is the TQ target with the monitoring comes on.  i could be totally off base but i pictured the ecu fighting between that map and kfmiop under high load so i wanted it to better match my other maps.

I get that whenever a flash fails, or if i dont hit disconnect on the older versions of nef.  I am always able to connect with VCDS and see that message and then re-flash.  Not this time though


I just got done changing the file back to how it was yesterday when this happened and once again tuner pro is doing the same thing, ecufix and me7 check say its good.

Need to reinstall winols real quick to test.

assuming that a "brick" can be recovered, and "killed" cannot, can bad checksums truly kill an ecu?

was your original ecu killed?

No idea, I didnt open the case but i smelled totally smoked which would be totally new to me for a CS error.

I think there is more too it with the TQ maps

This is making more sense now as to the root cause and the MTX plug in not catching certain stuff for some reason.

I was able to replicate the save issue on any file, so I did it to a stock file and posted that above.  Winols finds 1 error that MTX, ME7check and ECUFix all miss for some reason.

Beyond that, I am still baffled what smoked the ecu???  Was it when i tried to start it?  I have dealt with checksum issues before and the car would always start and run once then never again, never in 3 second pulses.

What address are the corrections applied to?

That might be a bit over my head, how do i see that?

The 3 files in the first post will probably tell you more than I can.

Step #3: Reading Multipoint Checksum Blocks...
 1) <14224>  Adr: 0x024000-0x02658D Chk: 0x0B08F804 CalcChk: 0x0B08F804  OK
 2) <14234>  Adr: 0x014000-0x014243 Chk: 0x0054AC79  ~0xFFABF016 INV NOT OK CalcChk: 0x0054FAC1 ** NOT OK **
 3) <14244>  Adr: 0xFFFFFFFF-0xFFFFFFFF  END

yup. its the one phila found.

So what's the verdict? That area isn't checked?

Worse:

1) ME7Check doesn't check it
2) MTX plugin apparently corrupts the MP descriptor block such that the checksum/inv pairs are wrong (so my first attempt at detecting them FAILED on ST's first image)

So we have a bug with me7check. That's kind of a big deal considering how many people rely on its output to verify if a file is safe to flash. I guess the bigger issue is that the mtx plugin corrupts the file further.

I still don't think that this could physically damage an ecu though.

I'm going to flash this file to see what happens.

If i understand you correctly Nye, then even though only one checksum was actually bad it shifted it all and made it to where they were all bad?

Could explain the mega bricking that occurred, throttle body adaptation that never wanted to stop and so on.  Bummer.  Waste of a perfectly good ecu.  If MTX wasnt 12 bucks that has paid for itself 1000 times already I would be bitching to him right now.

I'm flashing the bad file now.

Naw. its just a single value.


I don't think this should cause bricking, let alone ECU damage...

brave man, sorry in advance if you get the same results I did.

brave man :)

when I get to my shop later i will open up the ecu in question and see whats what.  Maybe try flashing it again if it doesnt look super burnt.  But the smell and temp were unmistakable to a fired board.

No communications after power cycle. Bootmode and it's back to normal. No detectable increase in heat produced.

EDIT:

I still wouldn't recommend flashing this. I flashed it to an ecu that has seen better days that I keep around just to play with.

Now THAT is interesting. I have mailed setzi about the bug. He's been awol so... we're kinda boned i think.

So. Thats why proprietary software is bad. abandonware.

Phila: please help me complete me7sum ;)

For ME7.1, 0x08040 and 0x1B9B0 are the only ones left, right?

So I think the smoke happened after I tried to crank it (and did 3 times).

bummer.

When you went back to redo it, did you bench it or go boot mode through nef?  I would like to try and salvage that ecu of mine.

Also, can anyone confirm that my file above labled with winols was indeed corrected so i can double check myself?  i hate to admit it but thats the first time I have corrected checksums with winols, I dont like EVC and i try not to use their stuff but now i might have to use it as a failsafe.

Yes, AFAIK.

I do not have a clean sample pair of bins to test 1b9b0 though, so we'll have to come up with a set.


Right now, it is impossible to really know anything. I *believe* the winols correct file is ok.

Oh one more thing!

Right now the MP block detection is NOT done by finger printing ASM, it looks for blocks that LOOK like MP descriptors. Now that we know MTX (might) corrupt the csum/inv pairs, I had to loosen the checking quite a bit.. which I don't much care for.

It would be better to detect the MP descriptors by ASM matching...

Also, I have several ME7.1 files that don't seem to have the 14224 block at all. I don't know if they are elsewhere, or really aren't there.

crazy, well i am glad a guy like me with 20 ecus stumbled upon this with my shop car and not some dude in his daily driver on the side of the road.

yo trooper, first of all, i had the exact same shit happen to me when i played with the the torque *_um map you messed with.
our fellow homey infinkc helped me out.  he tried boot-mode repairing my old ecu, but had no luck - i got the same clicking bullshit and it totally sucked.
if we ever find a solution to this, i'm quite excited to see what it is...

well that makes me feel better about a ghost on my machine, lol.

Now im not even going to waste any time on trying to bring back that ecu.

oh, N, btw i will be in WA this weekend and half of next week if you know anyone needing a road or dyno tune...  portland on saturday and wed.

The file winols corrected looks good. I corrected your BAD file, and ran it against the one your winols corrected and they were exact matches. The bad one you uploaded showed one error before correcting that me7check missed.

I flashed the file on the bench with nefmoto (as that's what you did), then cycled the power and tried to connect with vcds. After which, I used galletto with bootmode to reflash.

dd do you have git and do you have the tools to build me7sum?

Ok DD, sounds like it was good up until I tried to run the car on it then.  lessons learned for sure.  Thanks for the hands on testing and confirmations. 

haha, yah?  dude, let's meet up then either for cars or beer then.  i'll pm you my info.  randomly enough, i'll get my LC-1 + ME7L fully operational this evening, so that'd be rad.  any chance you'll bring the matte beast?  assuming no since its far away, albeit portland is closer than say austin, texas.

No driving our WRX up, trip actually came about for some suby tuning.  Turned into a multi day drive trip instead of flying since the GFs family is up there.

Got your email, i will drop you a line with our sched.

Nye-no, and no. I'm looking into it though. I'd love to be able to finish it up, but my programming skills are sub par at this point.

Maybe less for contributing directly, more for building .exe files from the latest source..

Sad I didnt know you were heading up, even worse knowing soemone on here is in my neck of the woods.....(Renton)

I will be up again in April or May.