That's awesome.

 

If that was all you got from my post I did a terrible job explaining what we've done.

In other words.... short of the battery going dead where the PCM can not operate it's going to be next to impossible for the PCM to be bricked no matter what goes wrong or is done during a flash.

I'm not sure why someone didn't come up with this method years ago.

 

$$$$$ for credits Right??? This is awesome. I cant wait to try this. keep up the good work guys we appreciate it.

 

Do you even know what you are talking about??

 

Do you?

I probably get an email or PM at least once a week from someone asking about PCM recovery from a failed flash. This happens a LOT more then you think. It's one of those things that you just don't see talked about a lot because people don't want to admit they screwed up and be ridiculed by others for being stupid or careless.

What blows my mind are the one's where something happened while they were just reading a PCM's file out and it bricks the pcm. If I hadn't seen it happen before with my own eyes I'd call BS and say that wasn't possible but I can assure you this is very possible with a certain commercial tool that comes to mind.

Looking on certain forums it also seems that when this happens your SOL for getting reimbursed for the cost of the license that was lost when the PCM bricked. I'm not saying this is being done intentionally but it does make you wonder....

 

OK, apparently you do know what you're talking about. Usually when I see a post with a question like you asked, it is usually a troll of some kind. I do apologize!

 

I never said anything,my comment that sparked this was an open ended statement that let people draw their own conclusion....someone just posted what people would be thinking.

I also stated what I've personally seen and it makes me wonder how a couple of nobody's were able to come up with a solution that multi million dollar company's with a staff full of experts never figured out. I mean it's possible that it was something that just fell through the cracks in the corporate ladder but I find that hard to imagine that NO ONE had thought of this since there is more then one company that does this.

Maybe using the flash kernel to not just allow reading/writing but also preventing a bricked pcm or loss of control over the data bus was a genuinely unique idea......regardless.... it's going to be open sourced with the PCM hammers source code when it's finished .

 

nice work pete and anonymous developer/programmer person from gearhead efi !

is this PCM controlled flash pause going to work with the P59 computer? (or later pcms for that matter?)

sorry I fell of the face of the earth the last few weeks. I ran across a ton of fabrication and tuning work that I'm trying to wade though as well as get a Turbo LS ready for next years drag season (from scratch....eeek)

as always if you need ANYTHING let me know. I'm happy to pitch in with my limited PCM knowledge or testing, equipment sourcing etc..

Doug

 

I have a kernel for the P59 that will do the same thing but I have not done much with that one just yet. Still working out the rest of the flash in the kernel......it does things in a much different manner then what commercial tools do and is making life difficult getting the rest of this to work the way it's intended.

What makes this different is that rather then sending data to a specific address you just load block after block into the PCM at the same address and the kernel places the data where it needs to go. This method isn't so much for working with the P01 computers and it more aimed at the P59's. When you write data to the PCM there may be an offset that's used to shift things around to where they need to be.

We are going to write FE FF CE and offset the data by 3 bytes
if we started at address 00 00 00 and just wrote the data FE would be at address 00 00 00, FF would be at 00 00 01 and CE would be at address 00 00 02. Well it's not going to work since we needed to offset the data by 3 bytes
So we write FE to 00 00 03, FF to 00 00 04 and CE to 00 00 05 giving us a 3 byte offset.

Now this does work and there are ways to do this with out changing the addressing like padding the data you start with. To do lets pretend we just send 00 00 00 FE FF CE and start writing at address 00 00 00. Yes the data will also end up in the same place as in the example above. But not you run into issue with the amount of data being written being larger then what it should be and you have to pull data back out somewhere else.

When your just reading the bin file from the pcm the offset doesn't come into play and is the reason that writing is much harder to do.The offset just makes sure that the correct data ends up where it needs to go so every thing lines up with what the PCM is exacting to see. A great example of what happens when the offset isn't correct can be seen when writing the 2156 OS onto the 0896 PCM, The data for the Vin and Serial number are corrupted more often then not. It's because the offset the data was written to was wrong.

What's being done with the kernel we are working on is taking care of the offset that needs to be used with the kernel rather then the program running the flash. I don't want to say there are a lot of different offsets used because were not talking about dozens of variations here but this does greatly simplify the process of writing the file to the PCM since the kernel is able to determine what needs to be written and where it goes. The real effects of how this plays out will be seen when writing calibration only data to the pcm, rather then needing to know where the data should be written for every OS to the kernel will take care of that....and if the data being written isn't going to fit rather then write the data to the wrong place or at the wrong offset it can reject the data and tell us what's wrong. This way we don't inadvertently write data to places it shouldn't be.....for example writing into sections of the OS and corrupting the PCMs boot data.

I have no experience with the newer E series Pcm's so I can't say with any certainty that similar methods could be created but I would imagine it is very likely it would be possible. Although most of the time issues on the E series stuff goes beyond things this kernel addressed and is the result of the Master and Slave OS's not matching where the PCM will no longer boot.But that's an entirely different topic.

Sorry if this is a very technical explanation and those reading it don't understand what it means. Just know it's awesome stuff

BTW....how long did the last version of my Read app I sent you take? I know it's still not 4x speeds but I'm trying to speed it up the best I can

 

lol, sorry, don't misunderstand me, I did get a lot from what you said ...

my first sentence tersely packs a lot of meaning.

 

right on, glad to hear p59's are still getting love.

last p01 read with 5.3.1 was right at 10 minutes.

 

I live just a few minutes away from Truckdoug, AKA Doug.
I'm up for being a Guinea pig on this. I have a Corvette project in mind that I hope your deal may do.
I'm also looking for a 2002 or 2003 Corvette auto trans Bin file as I've wanted to play with Tuner Pro and user defined parameters etc.
I tune professionally and have encountered locked tunes, but not on P01's.

Thanks for all your hard but fun work sir!

Ron

 

Hi all, sure I too use tuner pro AND believe there GUI Correct

Lance

 

Have Truckdoug email your OS number and or VIN and I'll see if I can come up with a file for you.

If I'm not mistaken the 2003 Corvette still used the 0411 Pcm still didn't it? I know I've seen one in a stock 03 before but I'm not sure if that's the case for all of them or not.

It may be worth trying a couple of other OS's on the car to see if the dash and other modules will respond.......Most if not all the Xdf support is focused on the F bodys and truck OS's.....I'm not sure you'll find an Xdf that'd work for your car. Guess we'll need to get the OS number to tell for sure.

Now I HAVE encountered a locked tune on a corvette before that was right around the same year as your car and I was able to walk the guy with it though unlocking it with the Pcm still in the car(does require opening the pcm up) the guy didn't have fun doing this...however it was hilarious to watch over a live stream. Something about seeing the Pcm's circuit board hanging by the wiring harness in the fender well just isn't something you get to see every day

On a bench harness it'd be 10x easier. In his case I hard coded the entire security block from a similar bin with the same OS number into a modified version of one of my apps specifically for this purpose. Rather then just side loading something like a serial number on shutdown I side loaded the entire section of the security block . It wasn't even close to being ideal or the proper way to do this but it did salvage the guys tune and that's all he was really after anyways. I think the only part that wasn't correct was the BCC code but it was like 2am when I did it and didn't really care because it worked .

 

Really convenient location of the ECU on a Corvette! Ha!
When I removed the inner fender on mine the ECU was caked in filth, so I took it out and disassembled it for cleaning.
I built my own bench harness.
I spent 37 years as an engineering tech, product development tech and finally a Project manager at Tektronix here in Oregon. Spectrum analyzers, Television, and Microwave Technology. Sadly was never into software or programming.

Anyway, the OS is 12221588. This is true for both 2002 and 2003 Corvette auto trans cars. And yes, both P01. The P59 came in the 04 Corvette.

My car is a 2000 C5. What I want to do is put the 02/03 operating system (Its superior) into my ecu but retain my VIN and vehicle description. The C5 BCM won't play with the wrong VIN. And of course come emissions time, it needs to be correct.

I am 100% sure this can be done because I've done some touch up tuning on a 1999 corvette (same OS as my 2000) tuned by another local shop and it had the later OS installed. HPT won't let us do this, but it will allow us to tune one. It comes up with a dialog box stating such.
I guess I could just ask the other tuner how he did it, I not only know him, I went to high school with him. But I'd rather do it my own bad self if that makes sense.

Ron

 

I'm guessing your talking about the VIN/OS mismatch error? Changing the Vin is childs play and GM actually placed unsecured commands in all the OS's to allow a vin change with out even unlocking the Pcm. So make the vin what ever you need for tuning and put it back to your stock Vin when your done. Problem solved. The PCM doesn't care what vin you have in it, I've got a Jeep vin in a P01 right now

I can tell you right now there isn't an Xdf for the 1588 OS but if that's the last OS the vetts used and works in the earlier models fine I'll get it added to my wish list. We are trying to keep Xdf development to the last OS of a car line or Pcm type since they typically have fixed all the bugs in older versions. In your case your wanting to upgrade but most of the time people would rather stay on their current OS even if it's crap compared to an updated OS for the vehicle.

I'l looking at the possible OS's an 02 Vett could have used and is there any reason you'd want to go with the 1588 OS over say the 2156 or 3358 OS? The 2156 has AMAZING Xdf coverage and the 3358 has an XDF that is currently being developed. I'm tossing in the 2088 OS just because it also has great XDF coverage but it looks like 2001 was the last year it was used.

I have no idea if these are stock tunes or not. I'd need a VIN to get a stock file.

 

I guess I should point out that the 1588 OS was also used in 2002 but I only have bins for it in 02 that are manual trans.

 

I typed out a response, tried to add an attachment, it blew up and I lost what I typed! Of course...…

Correct on the VIN/OS mismatch.

2156 looks to be perfect. I was able to open it with hpt 2.24.
HPT 4.xx no go...…..I guess they locked us out of opening .BIN files.
Good thing I saved 2.24

As far as 1588 is concerned, that's just from what I downloaded from hpt.



This is my VIN for my 2000
Can the vehicle description also be changed?

I have to run and tune a suburban. Dang.....
I'll check back later.

Thanks for the info! very helpful.

Ron

 

Vehicle description is decoded based on the Vin number you put in...assuming it's valid for the type. My p01 with a Jeep vin freaks out tuning software lol.

I'll see if I can come up with an 02 or 03 bin file that would closely match your vehicle and that use's the 2156 OS. This is also just my preferred "Go To" OS for just about anything.....so much you can do in it.

 

Got it that the VIN contains the vehicle year and description.
The file you posted for the 2002 Corvette seems fine to me. Can't you just insert my VIN into that?
I'll have to put all of my tune parameters in as my car is highly modified. That's not an issue.
Forgive my ignorance if this isn't possible.

Ron