PDA

View Full Version : Known issues with March 2015, Release Candidate 1



Blacky
March 20th, 2015, 06:03 PM
Currently known issues and possible workarounds for the March 2015, Release Candidate 1 of the EFILive Software and Firmware



Software: V7.5.7.280
Software: V8.2.2.274
FlashScan/AutoCal firmware: V2.07.81


Issue 1:
If you are Black Box Logging PIDs from an ECM and TCM simultaneously and you have selected a PID from the transmission controller (TCM) that has an identically named PID in the engine controller (ECM), then when the log file is loaded back into the V8 software for viewing, that TCM PID will be displayed as if it originated from the ECM. The PID's data will have correctly been logged from the TCM, only its name will appear to indicate that it was logged from the ECM.
Workaround:
None. It is a restriction of the *.efi (V7.5 log file format). That restriction will be removed and the TCM PIDs will display their true origin once the V8 scan tool software is available.

catman3126
March 22nd, 2015, 03:28 PM
tuning an lly tonight and everytime I save the LLY tune after converting it to DSp5 it locks it and I have to open with V8 and clear restrictions, and it would not let me save it without my V2 connected when I was done. never had this happen before.

Blacky
March 22nd, 2015, 04:15 PM
In the release notes we have this:

IMPORTANT
Your security restriction options on the [Permissions] tab page in the V7.5 Tune Tool software may change during the upgrade to this version of the V7.5 software. Please review those security restriction options and reconfigure them according to your preference.

It is possibe, (probable even) that your security restrictions in the V7 tuning tool software have been changed during the update. Please make sure they are set like this, which is the default value:
18153


What happened in a previous version was the settings got saved incorrectly into the V7 registry. That meant when we corrected the bug in this version, there was no way for the softwar to automatically "fix" the settings. So we advise you to check them and set them to what you want them to be.

You can use the V8 software to remove any security settings that got set when you saved the files using V7.

Regards
Paul

Mitco39
March 24th, 2015, 08:36 AM
Paul,

I dont think the BBX quick setup is saving the security restrictions properly. The CTZ to COZ worked great however with the ctz if I save it as private and then export it to a folder I can still open it as none of the security flags are set. I would assume its the same for the .coz's.

Thanks

Mitch

Blacky
March 24th, 2015, 08:46 AM
Hi Mitch,

Security restriction changes are not "baked into" the tune files in the BBX list until the BBX file is saved. So if you change the restrictions, then export the file it will have the original restrictions that the file had when it was added to the BBX list.
If you save the BBX file first, then re-open it (as would be the case if you sent it to a customer), then export the files you will see that the security restrictions are retained.

Regards
Paul


Paul,

I dont think the BBX quick setup is saving the security restrictions properly. The CTZ to COZ worked great however with the ctz if I save it as private and then export it to a folder I can still open it as none of the security flags are set. I would assume its the same for the .coz's.

Thanks

Mitch

Mitco39
March 24th, 2015, 09:23 AM
I tried that as well. I get the .coz cannot be opened error when trying to open that file. Thats if I double clicked the .bbx file in my windows explorer. If I open up the bbx file inside of V8 it opens up like you said it would in the post above. Is there a way to send this to the customer and just have them double click the bbx file and have it pop up the window for them to click program?

Or maybe I am missing something.

Everything else seems to work perfectly. I was also wondering is it possible to add in a feature that would update the autocal/v2 firmware to the current version of their software they have downloaded automatically? It would really make this a one or 2 click process for the customer if we were able to do that.

Thanks a bunch Paul,


Mitch

Blacky
March 24th, 2015, 09:28 AM
Hi Mitch,

You can't (yet) double click on a *.bbx file and have it open automatically. But we're working on it, so soon you will be able to do that.

We have decided against automatically updating the firmware since it is impossible to downgrade the firmware once it has been updated. We have been asked about an auto firmware update option and we are still considering it. Meanwhile, the [Check Firmware] button on the main V8 Scan and Tune window is the quickest/simplest option for now.

Regards
Paul

Mitco39
March 24th, 2015, 09:46 AM
Makes sense Paul.

Thanks so much for your quick replies. Finally just got on board with using this system as I have started doing more and more trucks and this is going to save me a huge amount of time especially now that we can go from ctz to coz inside this program.

Next little question for you. Is it possible to hide all the read commands as well "switch tunes" option from the autocal as this confuses many customers. Again not a huge deal by any means, just adding suggestions haha.

Thank you sir.


Mitch

Blacky
March 24th, 2015, 09:53 AM
Hi Mitch,

You can't remove the read options from AutoCal.

You can enable/disable the switching options for AutoCal.
18163

AutoCal settings are saved in the BBX quick setup file if you check the "Include current device settings" checkbox.
18164

Regards
Paul


Makes sense Paul.

Thanks so much for your quick replies. Finally just got on board with using this system as I have started doing more and more trucks and this is going to save me a huge amount of time especially now that we can go from ctz to coz inside this program.

Next little question for you. Is it possible to hide all the read commands as well "switch tunes" option from the autocal as this confuses many customers. Again not a huge deal by any means, just adding suggestions haha.

Thank you sir.


Mitch

Mitco39
March 24th, 2015, 10:04 AM
Ah perfect. Thanks.

catman3126
March 24th, 2015, 10:51 AM
Makes sense Paul.

Thanks so much for your quick replies. Finally just got on board with using this system as I have started doing more and more trucks and this is going to save me a huge amount of time especially now that we can go from ctz to coz inside this program.

Next little question for you. Is it possible to hide all the read commands as well "switch tunes" option from the autocal as this confuses many customers. Again not a huge deal by any means, just adding suggestions haha.

Thank you sir.


Mitch

I have had this happen too. guys call me and say they have tried switch tunes when they have a DSP/CSP5 switch installed lol

Chuck CoW
March 24th, 2015, 01:43 PM
Hi Mitch,

You can't (yet) double click on a *.bbx file and have it open automatically. But we're working on it, so soon you will be able to do that.

We have decided against automatically updating the firmware since it is impossible to downgrade the firmware once it has been updated. We have been asked about an auto firmware update option and we are still considering it. Meanwhile, the [Check Firmware] button on the main V8 Scan and Tune window is the quickest/simplest option for now.

Regards
Paul

That's good. Automatically (or forcing) firmware upgrades will cause problems for some of us. Given the volume of autocal customers and the range

of years past since some of their use can make headaches... It's even troublesome at times just keeping things straight between Release Candidates and

public release stuff. Sometimes I force the customer to have to update and other times they download new stuff and force me to update and as simple

as it sounds, it's either 10 mins of customer service support, 1 hour of phone support, and remote log in sessions at times depending on the customer

computer skill level and intelligence.

The Software has evolved where it's much easier than in the beginning, but It's still quite a lot of unnecessary phone support to keep everyone on the same page.

I had some ideas to make it easier and I'll reach out to you when I get everything on paper.

Chuck CoW

davematthews
March 25th, 2015, 03:36 AM
I'm not sure if this was the case before this release, but I thought if you saved the file "Save Tuning file, For Autocal", that it automatically saved it with security set?? I noticed in the last update. That's not the case. Whatever you have set on the Permissions page is what the file will be saved as.

I really thought it automatically secured the file before. I guess what I'm asking is why would you want to save for autocal and let the customer see it?

Blacky
March 25th, 2015, 06:06 AM
I'm not sure if this was the case before this release, but I thought if you saved the file "Save Tuning file, For Autocal", that it automatically saved it with security set?? I noticed in the last update. That's not the case. Whatever you have set on the Permissions page is what the file will be saved as.

I really thought it automatically secured the file before. I guess what I'm asking is why would you want to save for autocal and let the customer see it?

"Save for AutoCal" has always only set the Remote License and has never automatically applied any other security settings - other than those specified on the [Permissions] tab page.

After reading your post I agree, it makes sense to always set the "Cannot be viewed or modified" flag when saving for AutoCal. I can't think of any situation where you would "Save for AutoCal" and still expect or even need to be able to view or edit the file. It is something I'll consider for the next update.

Regards
Paul

Chuck CoW
March 25th, 2015, 06:25 AM
"Save for AutoCal" has always only set the Remote License and has never automatically applied any other security settings - other than those specified on the [Permissions] tab page.

After reading your post I agree, it makes sense to always set the "Cannot be viewed or modified" flag when saving for AutoCal. I can't think of any situation where you would "Save for AutoCal" and still expect or even need to be able to view or edit the file. It is something I'll consider for the next update.

Regards
Paul

That would be great if it was automatically set, but the option to "uncheck" it somewhere was available.

I know we discussed it before, but I'm here configuring a few autocals right now and it's always a waiting game for

each individual autocal to have the drivers loaded before the software can talk to it. What is it that makes each one unique

that we have to wait 1 minute or so for drivers to load. I understand the device is unique insofar as serial # but from the

usb device side, shouldn't they all be the same?

Chuck CoW

Blacky
March 25th, 2015, 06:43 AM
Hi Chuck,

Each EFILive device has a unique USB serial number as can be seen in \Program Files (x86)\EFILive\Drivers\Utilities\FT_Prog_v1.12\FT_P ROG.exe
18170

A unique USB serial number has been generated for both FlashScan and AutoCal for about the last 18 months, ever since our production systems were updated to support gang-programming of FlashScan and AutoCal devices. I.e. we now program multiple devices at the same time during production. To be able to connect and identify multiple, identical devices (prior to any EFILive serial or license numbers being set) there needed to be some way to identify each device. A unique USB serial number is how we do that.

If your system is set up to "Search Windows Update" for USB drivers, then each time you plug in a different USB device Windows will spend 20-30 seconds trying to find a better driver on "Windows Update" (there is not nor ever will be any such better device driver on Windows Update, so its pointless allowing the search to continue). You can cancel the search and it will immediately load the driver that is already installed on your PC (when the software was installed). To cancel the search, click on the balloon that pops up saying that drivers are being installed. That should open a dialog box showing that it is searching Windows Update and provide an opportunity to cancel that search.

Or you can switch off searching windows updates completely (which is what I do).
https://technet.microsoft.com/en-us/library/cc730606%28v=ws.10%29.aspx#BKMK_Anchor1

Regards
Paul


That would be great if it was automatically set, but the option to "uncheck" it somewhere was available.

I know we discussed it before, but I'm here configuring a few autocals right now and it's always a waiting game for

each individual autocal to have the drivers loaded before the software can talk to it. What is it that makes each one unique

that we have to wait 1 minute or so for drivers to load. I understand the device is unique insofar as serial # but from the

usb device side, shouldn't they all be the same?

Chuck CoW

Chuck CoW
March 25th, 2015, 08:47 AM
Hi Chuck,

Each EFILive device has a unique USB serial number as can be seen in \Program Files (x86)\EFILive\Drivers\Utilities\FT_Prog_v1.12\FT_P ROG.exe
18170

A unique USB serial number has been generated for both FlashScan and AutoCal for about the last 18 months, ever since our production systems were updated to support gang-programming of FlashScan and AutoCal devices. I.e. we now program multiple devices at the same time during production. To be able to connect and identify multiple, identical devices (prior to any EFILive serial or license numbers being set) there needed to be some way to identify each device. A unique USB serial number is how we do that.

If your system is set up to "Search Windows Update" for USB drivers, then each time you plug in a different USB device Windows will spend 20-30 seconds trying to find a better driver on "Windows Update" (there is not nor ever will be any such better device driver on Windows Update, so its pointless allowing the search to continue). You can cancel the search and it will immediately load the driver that is already installed on your PC (when the software was installed). To cancel the search, click on the balloon that pops up saying that drivers are being installed. That should open a dialog box showing that it is searching Windows Update and provide an opportunity to cancel that search.

Or you can switch off searching windows updates completely (which is what I do).
https://technet.microsoft.com/en-us/library/cc730606%28v=ws.10%29.aspx#BKMK_Anchor1

Regards
Paul


That should help, but if I switch it off then it means it's switched off globally for all USB devices and not just autocal?

Chuck CoW

GMPX
March 25th, 2015, 08:49 AM
That's good. Automatically (or forcing) firmware upgrades will cause problems for some of us.
But when people don't update the firmware to match the software releases it causes us support problems, the firmware works hand in hand with the PC side software, they have to match.

Blacky
March 25th, 2015, 08:57 AM
That should help, but if I switch it off then it means it's switched off globally for all USB devices and not just autocal?

Chuck CoW

Yes, it would be switched off for all driver installations.

But you can always manually search Windows Update for drivers like this (right click on a device and select "Update Driver"):
18171

I prefer to handle driver installs manually like that.

Another option would be to disable searching Windows Update while you are preparing multiple new AutoCals and then re-enabling it afterwards.

Regards
Paul

GMC-2002-Dmax
March 25th, 2015, 09:23 AM
Hi Mitch,

You can't (yet) double click on a *.bbx file and have it open automatically. But we're working on it, so soon you will be able to do that.

We have decided against automatically updating the firmware since it is impossible to downgrade the firmware once it has been updated. We have been asked about an auto firmware update option and we are still considering it. Meanwhile, the [Check Firmware] button on the main V8 Scan and Tune window is the quickest/simplest option for now.

Regards
Paul

I would not like an Auto-Update Firmware option, I want to be able to update it when I want, not when I plug in my V2.

JMHO

Mitco39
March 25th, 2015, 09:27 AM
I would not like an Auto-Update Firmware option, I want to be able to update it when I want, not when I plug in my V2.

JMHO

I meant it as more in an end user situation where there would be no reason for the customer to not update the autocal to the matching software version they are running. I thought it just a way to save the end user mouse clicks if you could store (only if you wanted to) the firmware in the bbx file. Thats all.

Chuck CoW
March 25th, 2015, 10:59 AM
I would not like an Auto-Update Firmware option, I want to be able to update it when I want, not when I plug in my V2.

JMHO

AGREED. I feel the same way as well.

Chuck CoW

Chuck CoW
March 25th, 2015, 11:09 AM
Agreed... BUT YES, it causes problems for you with support.

YES, it causes problems for ME having many autocals out there and everyone has different software.

YES, it causes problems for the END USER cause he's not the designer of the software, not a tuner,

and usually can barely turn on a computer no less wrap their head around drivers, firmware, release candidates,

public releases, etc. They just want their shit to work and don't care how.

If EFILIVE is wasting lots of time with support for issues such as this, just remember that they are usually calling the tuner first.

I think there can be a better way to handle the software updates and compatibility issues, but we all need to toss around some ideas

while each of us considers the possible consequences for the developers, the tuners, and the users.

I'm thinking about this good cause it's always been a problem. All of us are always excited to get the latest STUFF, but all too often

it comes with a price.

I'll keep thinking about this and get back to you soon.

Chuck CoW

GMPX
March 25th, 2015, 11:31 AM
Thanks Chuck, suggestions are always welcome.

Chevy366
March 26th, 2015, 06:00 AM
Updated to the newest RC1 version and went to read a P12 and had a hard time reading through V8 (3 attempts one was a $101 error, another was a $0311 with a $11 Mode Not Supported) it finally read all the way through but gives a error that the calibration contains one or more invalid/incorrect checksums, OS has red "X" beside it says OS is 12627882, checksum is $6FDDC631.

Says in error block balloon, will not let me reflash due to checksum error.

It use to work fine what happened? Old checksum in an older tune is $D14F1F23, seems "engine operation" and OS are different, old "engine operation" checksum $2E10FFAA, new checksum $A5570DD4, when I say old it is still a .ctz file.

I just did "update checksum' and got a warning message that it could corrupt the controller, safe?
Has green check mark now. ------------------------------------------------------------------------------------------------------------------------------------------------------------------

Quote Originally Posted by Chevy366 View Post
It use to work fine what happened?
Don't know, can you send the trace files to support?

Quote Originally Posted by Chevy366 View Post
I just did "update checksum' and got a warning message that it could corrupt the controller, safe?
No, definitely not safe, don't flash that in.
You may say, well why put the option there? There is some occasions when it needs to be done, however the warning holds true.

Also, can you please post this in the RC1 release thread, problems with RC1 should be posted in there. That is probably the only thread Paul will be monitoring for problems.
Before you do though are you 100% sure you updated the firmware too? We've had a number of people report issues with RC1 comms and each time it is because they didn't update the V2 firmware as well. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Okay carry over from P12 section post.
Yes RC1 installed and firmware updated too. When you open the software it prompts you to update the firmware, I always do.

When I first opened V8 software got a message stating that controller section had a checksum error with one of the controllers and did I want to check for new checksum, I did so and it cleared the red "X" from the list of controllers. The controller was not the P12 but a "E" series I don't remember exactly which one but 100% sure it was further down the list and was not the P12. Did not get a warning not to use any updated checksum controller then, just when I did the checksum on the P12 tune file. I have an older tune file with the correct checksum which I posted within the body of the OP.

Blacky
March 26th, 2015, 09:01 AM
When I first opened V8 software got a message stating that controller section had a checksum error with one of the controllers and did I want to check for new checksum, I did so and it cleared the red "X" from the list of controllers. The controller was not the P12 but a "E" series I don't remember exactly which one but 100% sure it was further down the list and was not the P12. Did not get a warning not to use any updated checksum controller then, just when I did the checksum on the P12 tune file. I have an older tune file with the correct checksum which I posted within the body of the OP.

Not sure I understand this part correctly:

When I first opened V8 software got a message stating that controller section had a checksum error with one of the controllers and did I want to check for new checksum, I did so and it cleared the red "X" from the list of controllers.

I'm not sure what this means: "controller section had a checksum error with one of the controllers". I don't know what a controller section is. Do you mean to say "segments" instead of "controllers"? If you really did mean "controllers", then unfortunately I don't know what you are referring to.

The V8 software does not warn about segment checksum errors when opening a tune file (at least I don't think it does).
The V8 software does not ask you to correct the checksum errorrs (again, I don't think it does).

The V8 software should not have asked you or prompted you to correct anything, it should have just displayed the red X next to each segment that had an incorrect checksum detected. You can only correct them in V8 by right clicking on the segment with the incorrect checksum and selecting "Force Checksum to be Correct".

So before I can continue investigating this in detail, I really need a more accurate description of what steps you performed and what the EFILive software did and/or displayed that you think is not correct.

Also, if you can send me any files that have incorrect checksums that would help (I didn't see any files attached to the original post in the P12 section).
And please send me any *.htx trace files from the failed P12 read attempts.
Send to paul@efilive.com

Thanks
Paul

Chevy366
March 27th, 2015, 06:07 AM
Already sent trace files (5838-UHCB-8296 --- 81c9f9d7), doesn't PCM stand for Power Control Module? So PCM = controller, isn't a controller a PCM? Semantics. Is there an "E" segment? Maybe an "E" as in E67 controller (PCM)? ;-)

"that you think are not correct" -- really? A red "X" is a indicator of something being incorrect, correct, that I am 100% certain. :-)

I can't send the file with incorrect checksums as I stated they have been corrected and saved through the software, I can send the file that has been corrected thought. Tell me how to revert back to original and I will gladly send to you. Don't ask me to reread the file again unless you offer a faster way of doing that without errors. :-)

Out of my frustration of having to do a read several times I did take out my phone and snap a few shots.

Again a Linux user so not always in Winders.

ScarabEpic22
March 27th, 2015, 06:42 AM
PCM= Powertrain Control Module
ECM= Engine Control Module
TCM= Transmission Control Module

So they're all related as a PCM can function as both an ECM and TCM, but the reverse is not true. Similar to a square is a rectangle, but a rectangle is not a square.

I havent read a P12 in a while unfortunately so I cant tell you if it's a new issue.

GMPX
March 27th, 2015, 08:10 AM
Chevy366, your posts are very hard to follow, I've read through them three times and I feel a bit like Paul, just left trying to figure out exactly what you are trying to say, eg, this....

When I first opened V8 software got a message stating that controller section had a checksum error with one of the controllers and did I want to check for new checksum, I did so and it cleared the red "X" from the list of controllers.
Please don't get frustrated at those trying to assist when what you wrote makes no sense at all.
FWIW we were able to read a P12 on the bench no problem with this release, so it must be an issue when on a vehicle which is why Paul asked for the trace files, not sure why you had to bold and big font that point.


doesn't PCM stand for Power Control Module? So PCM = controller, isn't a controller a PCM? Semantics. Is there an "E" segment? Maybe an "E" as in E67 controller (PCM)? ;-)
What has this got to do with not reading your P12? If you are trying to describe a problem you don't say something like this....
I selected the thing from the list and clicked that button then the other message popped up about something else and I clicked the red thing when I should have chosen the other thing from the list.........(hard to figure out isn't it). Correct terminology reduces frustration for everyone involved.

Blacky
March 27th, 2015, 09:17 AM
I didn't mean to make things even more confusing, sorry here's why I am confused...
I've quoted your post word-for-word...

When I first opened V8 software got a message
The V8 software does not give you messages about checksum errors when the software is "first opened". (At least I don't think it does. If it really does, then I need to investigate that).
So my confusion for that statment: Was it really a checksum error? Was it some other error unrelated to a checksum? Is the software showing a checksum error for some other reason (i.e. a checksum fault in the V8 software executable itself)? I was just trying to clarify the answers to those questions.


stating that controller section had a checksum error with one of the controllers
I don't know what a controller section is. I simply wanted to clarify that you meant to say "segment" or "controller segment".
I also got confused by your term with one of the controllers (again you probably mean with one of the segments). But the way you worded it got me thinking of the list of controllers (i.e. list of tune files) that appear on the front screen of EFILive as soon as you start the V8 software. Maybe the software is somehow reporting an error that one of the controllers (i.e. tune files) in that list is somehow faulty, I thought maybe it could be showing a summary of segment checkusm faults for each file and popping up a warning that one of the controllers (i.e. the tune files) in that list has a bad checksum. I don't think the software does that but I can't be entirely sure, just asking for clarification.


and did I want to check for new checksum
You should never ever get asked by the V8 software to check for new checksum. Yes, a red X is displayed next to each segment that has an incorrect checksum but the software will never ask you to correct them. You must right click on one or more segments and select "Force Checksum to be Correct". So if the software really did ask you to correct the checksums I need to know that because that is not how it should work.


Already sent trace files (5838-UHCB-8296 --- 81c9f9d7), doesn't PCM stand for Power Control Module? So PCM = controller, isn't a controller a PCM? Semantics. Is there an "E" segment? Maybe an "E" as in E67 controller (PCM)? ;-)

You said this in the previous post

I have an older tune file with the correct checksum which I posted within the body of the OP.
There is no file attached to the body of the OP, which I assume means Original Post. I was just asking for you to send me that file. Or maybe your statement meant that you have a file that used to have a bad checksum but that you've now corrected it. And that you posted that fact/information (not the actual file) in the original post. Its not clear to me which of those two meanings is correct. I assumed you meant that you had attached the file to the original post, my assumption may have been wrong.

And this:

(5838-UHCB-8296 --- 81c9f9d7)
Is that meant to be a link to the help desk ticket that you have logged? If so, that is not a valid link. If you have logged a help desk ticket can you please send a proper link to your ticket so I can look up your ticket.

I have no idea why you're discussing the differences between ECM and PCM. Did I say something that confused those two terms in my original post? Maybe the confusion has to do with you using the term "controller" when I think you meant to use the term "segment".


Tell me how to revert back to original and I will gladly send to you. Don't ask me to reread the file again unless you offer a faster way of doing that without errors. :-)
You can't revert a checksum that has been corrected back to its incorrect state.
If you really want this solved, then the only way would be to re-read the controller and send me the *.ctz tune file (that has the bad checksum segments in it) and matching *.htx trace file.
I too wish there was a faster way to read it, but at 41,600bps it is slower than most dial up Internet connections were back in the 90's :)

I understand you're frustrated with something not working properly in the software. But I really am confused about what you've posted. I don't want to rush off trying to fix something if I've misunderstood the problem that you're describing. I've done that before, I've assumed I knew what the problem was only to find out days later and much wasted time later that I was wrong. The more you can help me, the sooner I can get the correct fix done.

Regards
Paul

Chevy366
March 28th, 2015, 06:03 AM
Here you go slowly and as concise as I can say it -- Tried reading P12 controller (PCM) after the RC1 update, now listen very carefully so there is no more confusion, controller (PCM) would not read got about 1/3, that is one third if segmented in thirds it was one of those segments, stopped for several minutes, dash lights were all on before stoppage, meaning all warning lights not back lights, got it so far?
After a few seconds, didn't watch to see exact amount of time sorry, the dash lights began an on and off sequence then stopped, only 2 lights lit (don't remember the exact ones) after that, software showed a stoppage of progress, meaning the progress bar stopped (progress bar-- a bar indicating progress of a software process), got it so far? Not trying to be curt just hoping no more confusion occurs.
After the software set unresponsive for a few seconds, again not certain how much time passed, was given an error of $0101 (no data received) 3 times, then $0311 with an $11 in a balloon box window. I tired starting the truck (Trailblazer is considered a truck in my state) it did start, I did this in fear that the no read unresponsive software may have harmed the controller (PCM), it did, somehow the failed read left some parts of the controller (PCM) unresponsive meaning the computer controlled clutch fan was stuck in a always on state (which was functioning properly before failed read), the A/C clutch would not engage (worked properly before failed read) are the 2 known items of the failed read caused to malfunction, now got it so far? So I tried reading the controller (PCM) again same thing, and again, and again, (sent trace files) finally the software made a complete read, the the computer controlled clutch fan worked properly, and the A/C as well. This started the whole thing and is my main concern, that and why one of the checksum errors in the OS was encountered.

After updating to RC1, opened Scan and Tune (meaning opened V8 software at this point was prompted), plugged in the V2 and was prompted to update firmware of the V2, did so, saw a balloon button that allowed me to format the config files and rewrite them into the the V2.
The first checksum error seemed harmless and gave no warning about corrupting the controller (PCM).
However the second checksum error (OS checksum) after the final reading of the controller (PCM) did give such a warning (may corrupt the controller, EFILive will not allow a reflash with this tune file), this one gives me concern.

So in retrospect the 2 concerns are not the first checksum error, please stop fixating on it, the failed reading of the controller (PCM) and the error and component problems followed by the bad checksum in the read OS file are the 2 concerns I have at present. I tend to work through problems to quickly sometimes and brush off the method I used to achieve the fix sorry.


Here is the response I received from support -- can you please point out the correct number --

========= Please enter your reply ABOVE this line =========



Hello
gilbert,



Thank you for submitting your question to our staff. We will
respond to your question by email.



Anytime you wish you can view your
question
online:

https://support.efilive.com/view.php?ticketref=5838-UHCB-8296&pass=RMwQp4gg



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~

This
message was sent by the EFILive helpdesk.



Have a question we can help you
with? Visit our knowledgebase for a list of questions and
answers:

https://support.efilive.com/kb.php



Alternatively, ask our staff
a question:

https://support.efilive.com/newticket.php
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
From support page -- Question Ref
5838-UHCB-8296
One I posted 5838-UHCB-8296 --- 81c9f9d7

Seems if you take the last few number/letters off it is correct, sad your site and you didn't know that.

Think confusion-- just go to the support page of EFILive or all the iteration of updates by the programmer. :-)

I am not going to risk a failed read again and the fan and A/C problems that come from that.
I will send you the corrected file, and as you can see I have sent the trace files from that read session.
I don't know how I can help you any more than I have, I can send you photos of the OS checksum error I took with my phone but it is not the corrupted file.

"You said this in the previous post" [Paul]
I have an older tune file with the correct checksum which I posted within the body of the OP.

Not file but checksum says so in the quoted text. And I did put the old checksum values in the OP, here it is again -- It use to work fine what happened? Old checksum in an older tune is $D14F1F23, seems "engine operation" and OS are different, old "engine operation" checksum $2E10FFAA, new checksum $A5570DD4, when I say old it is still a .ctz file.
Said nothing about including a file just checksum, I think you are confusing yourself.

In the past I have voiced my concerns about the P12 reading and the difficulty of it.

Chevy366
March 28th, 2015, 06:09 AM
PCM= Powertrain Control Module
ECM= Engine Control Module
TCM= Transmission Control Module

So they're all related as a PCM can function as both an ECM and TCM, but the reverse is not true. Similar to a square is a rectangle, but a rectangle is not a square.

I havent read a P12 in a while unfortunately so I cant tell you if it's a new issue.

Yeah missed the Powertrain, I knew that just was livid about the treatment I am receiving.

Could you try one and see? Be careful if it doesn't read it will render components inoperative. The TB is stock no aftermarket anything.

Trust me this has been an ongoing problem, I even preached about it when another person had a difficult time flashing a P12 a few months ago.

Chevy366
March 28th, 2015, 07:05 AM
Chevy366, your posts are very hard to follow, I've read through them three times and I feel a bit like Paul, just left trying to figure out exactly what you are trying to say, eg, this....

Please don't get frustrated at those trying to assist when what you wrote makes no sense at all.
FWIW we were able to read a P12 on the bench no problem with this release, so it must be an issue when on a vehicle which is why Paul asked for the trace files, not sure why you had to bold and big font that point.


What has this got to do with not reading your P12? If you are trying to describe a problem you don't say something like this....
I selected the thing from the list and clicked that button then the other message popped up about something else and I clicked the red thing when I should have chosen the other thing from the list.........(hard to figure out isn't it). Correct terminology reduces frustration for everyone involved.

I think both of you are confusing yourselves. Or just don't believe me.

Here -- tried reading P12 controller (PCM) several times, between failed reads the computer controlled fan was stuck "on" and the A/C computer controlled clutch would not engage both of which worked before failed reads, after a successful read the fan and A/C clutch work properly again.
Read tune file finally has checksum error in the OS segment, found in a drop down in the open window with a way to attempt to fix wrong checksum, did so, get error that file may be corrupt, the end.

Go try and read from a Trailblazer, you will see it for yourself, I suspected a bench read was all that was happening and not a in vehicle read with data bus involvement.

Not confusing to me. Read failed, causes vehicle component problems, checksum in OS bad after successful read, tried to fix, get error.

What confuses me is the owners of a company are confused about their own product.

Do you think I am lying or making this up?

I am sorry I can't name every button or dropdown selection used, I only had one chance at it not repeated attempts, now the failed reads I remember because there were several of them and I bet you can't name all of the buttons/windows in the software either.

Blacky
March 28th, 2015, 07:05 AM
Here you go slowly and as concise as I can say it
Thanks, I appreciate the detailed description. It really does help.


From support page -- Question Ref
5838-UHCB-8296
One I posted 5838-UHCB-8296 --- 81c9f9d7

Seems if you take the last few number/letters off it is correct, sad your site and you didn't know that.
My mistake, I should have realized that, sorry.


Think confusion-- just go to the support page of EFILive or all the iteration of updates by the programmer. :-)
Yes, I agree :)


I am not going to risk a failed read again and the fan and A/C problems that come from that.
The failed read will not (cannot) cause any permanent changes in the PCM. If a read fails and something goes wrong causing a non-start, you can safely remove/restore power to the PCM to reboot it. You may need to remove power from the entire vehicle to cause all the other modules to reboot, just in case it is one of the other moudles that is causing the problem.
THe only time you cannot (must not) remove battery power from the PCM is if a full-flash fails. In that case the only way to recover is to re-attempt the full-flash until it succeeds.


I will send you the corrected file, and as you can see I have sent the trace files from that read session.
I don't know how I can help you any more than I have, I can send you photos of the OS checksum error I took with my phone but it is not the corrupted file.
The trace files are all I need to see so far, I don't need the tune file yet, thanks.


"You said this in the previous post" [Paul]
I have an older tune file with the correct checksum which I posted within the body of the OP.
Not file but checksum says so in the quoted text. And I did put the old checksum values in the OP, here it is again -- It use to work fine what happened? Old checksum in an older tune is $D14F1F23, seems "engine operation" and OS are different, old "engine operation" checksum $2E10FFAA, new checksum $A5570DD4, when I say old it is still a .ctz file.
Said nothing about including a file just checksum, I think you are confusing yourself.
Yes, I interpreted your sentence in the way that you did not mean it.


In the past I have voiced my concerns about the P12 reading and the difficulty of it.
I think it may be something else in the vehicle causing the problem.


One thing about the checksums. They should never, ever be wrong in a file that has just been read out of a controller. The only time they would be wrong is if:



The controller's flash memory has failed meaning it should be replaced.
The read process failed or was interrupted causing some data being sent from the controller to FlashScan/AutoCal to become corrupted (I think this is what is happening in your case).
The controller has been retuned/reflashed using a tuning tool other than EFILive and that tuning tool did not set the checksums correctly.
The controller is a T42 (some T42's had incorrect checksums from the factory - we don't know why GM did that).


In the first two instances the checksums in the corrupted files must never ever be corrected and re-flashed into the controller. It will almost certainly destroy the controller.
In the thrid instance it may be ok to correct the checksums and flash the file back into the controller. It is impossible to know. The best thing to do is to discard the corrupt file that was created by a different tuning package and to re-start with a stock/good tune file.
In the fourth instance, if you know beyond doubt that the data in the TCM is a stock tune then the checksum can be corrected and the file re-used.

The checksum correction feature is not meant to be used to correct checksums that occur for "no apparent reason". That feature is ONLY provided so that tuners who want to (and know how to) make modifications to a *.bin file (binary image) can make those modifications and then recompute the checksums to force the controller to accept their changes. We do not recommend doing that, it is so easy to make a mistake and wreck the controller.

Now back to the actual problem...

All the trace files show clearly that one or more modules on the VPW bus is/are resetting the bus halfway through the read process. Even the one that succeeded shows that it was temporarily interrupted midway through the read. When the VPW bus is reset it reverts from 4x speed back to 1x speed so if the read attempt was being done in high-speed mode (i.e. 4x mode) then the read will fail. If the read was being done in 1x mode then there's a chance the EFILive software can recover and continue.

There is no easy way to tell which module is resetting the bus and causing the read to fail. As far as I can tell your vehicle has the following modules (other than the PCM) fitted:

Electronic Brake Control Module (EBCM)
Body Control Module (BCM) or Dash Integration Module (DIM)
Instrument Panel Cluster (IPC)
Radio (RAD)
Digital Radio Receiver (DRR)
Mobile Communication System (Onstar)
HVAC Control Module
Driver Door Module (DDM)
Front Passenger Door Module (FPDM)


The only one of those modules that behaves differently to all the others is the EBCM. Can you please try removing the fuse for that module before reading the PCM? Does that help the read process complete successfully? If it does help, then does it also clear up the checksum issue with the file that is read?

P.S. I've also posted this response in your the help desk ticket.

Regards
Paul

Blacky
March 28th, 2015, 07:19 AM
I think both of you are confusing yourselves. Or just don't believe me.

Here -- tried reading P12 controller (PCM) several times, between failed reads the computer controlled fan was stuck "on" and the A/C computer controlled clutch would not engage both of which worked before failed reads, after a successful read the fan and A/C clutch work properly again.
Read tune file finally has checksum error in the OS segment, found in a drop down in the open window with a way to attempt to fix wrong checksum, did so, get error that file may be corrupt, the end.

Go try and read from a Trailblazer, you will see it for yourself, I suspected a bench read was all that was happening and not a in vehicle read with data bus involvement.

Not confusing to me. Read failed, causes vehicle component problems, checksum in OS bad after successful read, tried to fix, get error.

What confuses me is the owners of a company are confused about their own product.

Do you think I am lying or making this up?

I am sorry I can't name every button or dropdown selection used, I only had one chance at it not repeated attempts, now the failed reads I remember because there were several of them and I bet you can't name all of the buttons/windows in the software either.

It is not that we don't believe you its just that we didn't understand what you were trying to explain.

The bad checksum is a big, big concern. I needed to know as much information about what caused it, why, how, when etc. From your original post I wasn't sure if you were describing a problem in the V8 software that was somehow causing the checksum error or if the checksum error already existed in the file before it was opened in the V8 software. Knowing which, makes huge difference to how the problem is dealt with here. The trace files helped a lot, thank-you.

Also some of what you explain as errors/faults are not really errors or faults. The issues with the fans, A/C and other modules are all standard behaviour on vehicles like yours if/when the modules controlling those components cannot communicate with the PCM. While a PCM is being read or re-flashed it will not (and cannot) communiate with any other module. For example, when the fan controller cannot communicate with the PCM, it cannot know the engine coolant temperature. In that case it defaults to on just in case the engine is hot (and that would appear as if the fans were stuck on). Once the read has completed successfully and the PCM has been rebooted successfully all the modules can resume communicating normally on the bus and they all start operating properly again. If the PCM does not complete the read successfully (because in your case it was interrupted by another badly behaved module) then the PCM will not reboot immediately and other modules will still not be able to communicate with it. The remove/restore power option I explained in the previous post will reboot the PCM and restore normal operations. In some cases it may be necessary to reboot all controllers by removing/restoring power from the entire vehicle.

Regards
Paul

joecar
March 28th, 2015, 02:06 PM
The posts in this thread are too long to be able to be digested.

From what I see here, the solution may be to only read/flash the ECM in isolation (i.e. bench harness), since the rest of the vehicle (other modules) is interfering (getting upset that ECM is busy).

LPDTuning
March 29th, 2015, 12:21 AM
Tuned 3 LB7's this weekend. Using V8 when the flash was complete I kept getting error $0548. Flashes were exceptionally long compared to normal. Almost 8 min for DSP5 flash on an LB7 controller. Trucks would not start after reflash. First truck (01 LB7) ended up taking a flash with 7.5 and worked fine. Second truck (01 LB7) did the same thing. After failed flash with V8 I attempted to read the PCM info and there was no VIN and no OS number. Again, flashed with 7.5 and all was well. The third truck on the other hand, (03 LB7) failed flash with V8 with error $0548. No Crank issue this time, with dim check engine light. Tried to reflash with 7.5 and could not confirm PCM status. Bricked ECM. Ended up installing another ECM and reflashing with 7.5. All issues have arrived after installing this latest update. Bootblock 2.07.07 and Firmware 2.07.80 V8.2.2 Build 273

Chevy366
March 30th, 2015, 06:11 AM
Thanks joecar that is a good suggestion, but to have to go to those lengths to appease a $750 piece of equipment that's job is to read a controller in a vehicle without removal is ludicrous.
Not trying to be difficult, just being honest. (my point of observation)

GMPX
March 30th, 2015, 07:17 AM
Not trying to be difficult, just being honest. (my point of observation)
You are being very difficult......just being honest. In fact I was very surprised to see a long time member carry on like you did.

For those following along Chevy366 was told the following via the help desk (which wasn't good enough apparently).

The GM class-2 VPW bus uses a co-operative architecture which means all modules must cooperate when transmitting on the bus and all modules must respect all other modules' transmissions (especially when reading/flashing). If a module on the bus is interfering then there is nothing the EFILive software or the FlashScan hardware can do about it. The modules used in GM vehicles (in all vehicles really) are made by many different suppliers. Sometimes the suppliers don't get the level of co-operation correct and those modules interfere with the read/flash process. Top tier suppliers who supply factory fitted modules usually do get it right. Its mostly the aftermarket devices, usually radios, that get it wrong. However, even factory fitted devices can and do get it wrong. The Duramax LLY uses a very similar ECM to the P12 and that controller is riddled with such problems. Don't forget, that GM's tech2 device does not and cannot read the controller like EFILive does. So GM do not test their systems to ensure that all modules operate correctly when the controller is being read.

When flashing vehicles using GM's own Tech2 equipment even GM advise to isolate other modules from the VPW bus on some platforms. Obviously I didn't want you having to pull the PCM out of the vehicle and purchase a bench harness so I recommended pulling the fuse for the ABS module. I was just trying to provide you with the simplest and least intrusive method to remove the ABS from the equation.

slows10
March 30th, 2015, 09:34 AM
Pull the radio fuse. If that does not work pull the abs fuse. I have done 350 flashes on my PO8 pcm im my 1998 S10, and I have to pull the radio fuse everytime. Or it will not read or flash. It is 100 % stock factory original radio and all, nothing added on. This is your only problem. Pull the correct fuse and read/flash away. P12 and P08 are very similiar pcm's in alot of ways.

GMPX
March 30th, 2015, 10:37 AM
Have you ever flashed your S-10 with TechII? As Paul had stated earlier, GM even says that on some vehicles fuses MUST be pulled prior to flashing or isolated using a very expensive tool, you will see warnings like this...

18184

That warning is what you get prior to flashing a C5 Corvette, you need a box plugged in to isolate certain modules from the VPW bus. You don't need to do this with EFILive on all VPW vehicles, but some can be really stubborn and timing is critical with them to make everything go smoothly.
http://www.corvetteactioncenter.com/tech/knowledgebase/print-427.html
(http://www.corvetteactioncenter.com/tech/knowledgebase/print-427.html)

slows10
March 30th, 2015, 12:06 PM
Yes on the techII. A shop I hang around at has one. They have had to use a tool made by OTC i think it was on a few cars. In my last post I meant that it is just the nature of some of these GM cars to be stubborn. I know 5 years ago it drove me crazy when my pcm refused to flash. You and paul told me to start pulling fuses until it worked. And that was it. No more trouble. So I just pull that fuse when I flash now everytime. Wasnt complaining about efilive this time. Lol.

GMPX
March 30th, 2015, 12:14 PM
In my last post I meant that it is just the nature of some of these GM cars to be stubborn.
Yes, just one of the shortcomings of the VPW comms bus as you've discovered.

wesam
April 5th, 2015, 09:20 AM
E92 OS # 12663390 and OS # 12660065
still has wrong MAX and MIN values for B0169 and B0170

Thanks in advance

Chevy366
April 6th, 2015, 04:45 AM
You are being very difficult......just being honest. In fact I was very surprised to see a long time member carry on like you did.

For those following along Chevy366 was told the following via the help desk (which wasn't good enough apparently).

The GM class-2 VPW bus uses a co-operative architecture which means all modules must cooperate when transmitting on the bus and all modules must respect all other modules' transmissions (especially when reading/flashing). If a module on the bus is interfering then there is nothing the EFILive software or the FlashScan hardware can do about it. The modules used in GM vehicles (in all vehicles really) are made by many different suppliers. Sometimes the suppliers don't get the level of co-operation correct and those modules interfere with the read/flash process. Top tier suppliers who supply factory fitted modules usually do get it right. Its mostly the aftermarket devices, usually radios, that get it wrong. However, even factory fitted devices can and do get it wrong. The Duramax LLY uses a very similar ECM to the P12 and that controller is riddled with such problems. Don't forget, that GM's tech2 device does not and cannot read the controller like EFILive does. So GM do not test their systems to ensure that all modules operate correctly when the controller is being read.

When flashing vehicles using GM's own Tech2 equipment even GM advise to isolate other modules from the VPW bus on some platforms. Obviously I didn't want you having to pull the PCM out of the vehicle and purchase a bench harness so I recommended pulling the fuse for the ABS module. I was just trying to provide you with the simplest and least intrusive method to remove the ABS from the equation.
Ah the old blame GM game, at some point you go F#$% this S%*$. :-(

So I suggest you put in the selling points that the P12 is not supported fully but only in a bench harness operation. "Trailblazer not supported"
I have in the years past voiced my opinion about the P12 quirkness (flashing, and now reading) yet went unnoticed or ignored this is not a new issue by any means, been going on for years. :-)

I emailed you agian with no response so I came here.



Pull the radio fuse. If that does not work pull the abs fuse. I have done 350 flashes on my PO8 pcm im my 1998 S10, and I have to pull the radio fuse everytime. Or it will not read or flash. It is 100 % stock factory original radio and all, nothing added on. This is your only problem. Pull the correct fuse and read/flash away. P12 and P08 are very similiar pcm's in alot of ways.

P08 and P12 may be close but it is the body platform and the data buses that may vary. Might work, might not.



Have you ever flashed your S-10 with TechII? As Paul had stated earlier, GM even says that on some vehicles fuses MUST be pulled prior to flashing or isolated using a very expensive tool, you will see warnings like this...

18184

That warning is what you get prior to flashing a C5 Corvette, you need a box plugged in to isolate certain modules from the VPW bus. You don't need to do this with EFILive on all VPW vehicles, but some can be really stubborn and timing is critical with them to make everything go smoothly.
http://www.corvetteactioncenter.com/tech/knowledgebase/print-427.html
(http://www.corvetteactioncenter.com/tech/knowledgebase/print-427.html)

So where is the warning in EFILive that a P12 requires (a) fuse/s to be pulled and which one/s to pull?
Just saying, might have been a bad example there on your part.

I would be fine if I was informed in the sotware that (a) fuse/s have to be pulled and which one/s that needed to be pulled, just give me the correct answer and details on how to make the V2 and sotware work with my controller "in the vehicle". To much to ask? To difficult of a request?

Again just being honest.

GMPX
April 6th, 2015, 04:50 PM
I would be fine if I was informed in the sotware that (a) fuse/s have to be pulled and which one/s that needed to be pulled, just give me the correct answer and details on how to make the V2 and sotware work with my controller "in the vehicle". To much to ask? To difficult of a request?
It was suggested to you to try to pull some fuses to figure out which module was causing the problems, Paul said that in Post 34 (https://forum.efilive.com/showthread.php?25313-Known-issues-with-March-2015-Release-Candidate-1&p=217494&viewfull=1#post217494) , another user suggested the radio fuse in Post 40 (https://forum.efilive.com/showthread.php?25313-Known-issues-with-March-2015-Release-Candidate-1&p=217569&viewfull=1#post217569), did you try any of those?

With no direct access to any P12 Trailblazers we will be working with some others who have access with the correct logging equipment to try to solve the problem if they can replicate it. I agree it is not a good situation but the VPW bus isn't very good, no other way to say it, unfortunately that does mean we are playing 'the old blame GM game', well they designed the thing. If you can try the fuses listed in those post that would be great, if not we just ask that you please wait until some other testers have the chance to.

joecar
April 7th, 2015, 03:17 AM
Flash in isolation using bench harness.

minytrker
April 7th, 2015, 04:22 PM
Correct way to handle remote (email tuning) when customer updates their V2 to latest release candidate and my V2 is not. Can they go back to previous update or am I forced to update my V2 and then have all my customers update also? I do not like running release candidates due to possible issues.

cindy@efilive
April 7th, 2015, 11:39 PM
Correct way to handle remote (email tuning) when customer updates their V2 to latest release candidate and my V2 is not. Can they go back to previous update or am I forced to update my V2 and then have all my customers update also? I do not like running release candidates due to possible issues.

There are some significant file format changes between the July public release and the current RC1 software. It is necessary to have both FlashScan and AutoCal on the same version. Firmware cannot be downgraded even if the end user makes a mistake.

There is another release scheduled in the coming days. It contains very minor changes to RC1, that we expect will become the next public release.

Cheers
Cindy

GMC-2002-Dmax
April 8th, 2015, 07:18 AM
I have found a small anomaly with respect to LML VIN Changes.

If I use V8 Scan and Tune to change the VIN the V8 program displays it correctly.

If I use the V7.5 to open the tune from V8 using the "EDIT" feature the VIN is garbled up.

If I enter the VIN again in V7.5 tune tool and resave the tune file/close/reopen it remains correct.

Thanks

mpdtune
April 9th, 2015, 01:45 AM
Ah the old blame GM game, at some point you go F#$% this S%*$. :-(

So I suggest you put in the selling points that the P12 is not supported fully but only in a bench harness operation. "Trailblazer not supported"
I have in the years past voiced my opinion about the P12 quirkness (flashing, and now reading) yet went unnoticed or ignored this is not a new issue by any means, been going on for years. :-)

I emailed you agian with no response so I came here.




P08 and P12 may be close but it is the body platform and the data buses that may vary. Might work, might not.




So where is the warning in EFILive that a P12 requires (a) fuse/s to be pulled and which one/s to pull?
Just saying, might have been a bad example there on your part.

I would be fine if I was informed in the sotware that (a) fuse/s have to be pulled and which one/s that needed to be pulled, just give me the correct answer and details on how to make the V2 and sotware work with my controller "in the vehicle". To much to ask? To difficult of a request?

Again just being honest.

Apparently you've never tried to flash an LB7 Duramax ECM. They will literally brick themselves because you looked at them wrong. Myself, along with everyone else that tunes them, keep a rebuilt ECM or 5 on hand for when it happens. And it's not EFILive's fault at all. Just a bad design from GM. But GM also never designed this controllers to flashed by the end user with non-GM hardware. And the GM hardware leaves a lot to be desired. I would even put money on your Trailblazer not taking a flash from a GM MDI or Tech 2.

So either pull some fuses like you've been told, buy a bench harness, or go buy hptuners and have the same problem.

THEFERMANATOR
April 9th, 2015, 05:35 AM
Apparently you've never tried to flash an LB7 Duramax ECM. They will literally brick themselves because you looked at them wrong. Myself, along with everyone else that tunes them, keep a rebuilt ECM or 5 on hand for when it happens. And it's not EFILive's fault at all. Just a bad design from GM. But GM also never designed this controllers to flashed by the end user with non-GM hardware. And the GM hardware leaves a lot to be desired. I would even put money on your Trailblazer not taking a flash from a GM MDI or Tech 2.

So either pull some fuses like you've been told, buy a bench harness, or go buy hptuners and have the same problem.

I'll take an LB7 any day over an LLY. NOTHING out there has caused me more grief than the friggen LLY's have. From flashes just not going, to the flash not taking, to the flash that does go through being something completely different than what I know I flashed into it. It's just how it goes with some of these trucks.

GMPX
April 9th, 2015, 07:24 AM
All VPW based controllers like what you guys talk about are on knifes edge when flashing, unfortunately the VPW bus is not tolerant of misbehaving modules. It is why many of the vehicles GM made have the 'star' connector so you can quickly isolate modules from other modules. It is usually the BCM in the LLY as the cause of problems, I think GM must have used different suppliers who didn't always follow the rules. I remember when we started working on the LLY all those years ago Paul was lucky enough to have access to a vehicle in NZ, on that truck reading and flashing was rock solid, unfortunately that doesn't always mean the same on every other LLY out there.
The LB7 is a crazy one for sure, TIS2WEB will lock those up if it is a 2001, they are very fussy. It is a shame that GM didn't switch to CAN earlier.

GMC-2002-Dmax
April 9th, 2015, 07:45 AM
All VPW based controllers like what you guys talk about are on knifes edge when flashing, unfortunately the VPW bus is not tolerant of misbehaving modules. It is why many of the vehicles GM made have the 'star' connector so you can quickly isolate modules from other modules. It is usually the BCM in the LLY as the cause of problems, I think GM must have used different suppliers who didn't always follow the rules. I remember when we started working on the LLY all those years ago Paul was lucky enough to have access to a vehicle in NZ, on that truck reading and flashing was rock solid, unfortunately that doesn't always mean the same on every other LLY out there.
The LB7 is a crazy one for sure, TIS2WEB will lock those up if it is a 2001, they are very fussy. It is a shame that GM didn't switch to CAN earlier.

The Drewtech Mongoose GM/Pro will not even flash them...........Drewtech won't even address the issue.

I have to use the older VPW Silver cable on LB7's even on a bench the drewtech blue cable will not flash without hosing the LB7 ecm up

GMPX
April 9th, 2015, 08:18 AM
It's not the 'cable', it is the poorly written code in the LB7 ECM.

Blacky
April 9th, 2015, 12:46 PM
I have found a small anomaly with respect to LML VIN Changes.

If I use V8 Scan and Tune to change the VIN the V8 program displays it correctly.

If I use the V7.5 to open the tune from V8 using the "EDIT" feature the VIN is garbled up.

If I enter the VIN again in V7.5 tune tool and resave the tune file/close/reopen it remains correct.

Thanks

I tried the same thing here with both E86A and E86B and after changing the VIN using V8, the VIN showed correctly in V7.
Do you have screen shots and/or step-by-step instructions to reproduce the issue?

Regards
Paul

GMC-2002-Dmax
April 9th, 2015, 10:42 PM
Paul, as requested

Thanks

1) Open tune in V8
2) Select Properties/Controller Info/VIN/Change VIN/Save
3) Select EDIT
4) Open file in V7.5

Garbled up VIN

I did upgrade from July 19th to the current RC1 and did not do an UN-INSTALL first ?

I also am running Windows 7

Blacky
April 10th, 2015, 06:32 AM
Paul, as requested

Thanks

1) Open tune in V8
2) Select Properties/Controller Info/VIN/Change VIN/Save
3) Select EDIT
4) Open file in V7.5

Garbled up VIN

I did upgrade from July 19th to the current RC1 and did not do an UN-INSTALL first ?

I also am running Windows 7

Its most likely being caused by the file's NVRAM areas. The VIN is stored in the NVRAM which is duplicated in two places in the file, one active and the other inactive. EFILive V7 and V8 are possibly using different banks to retrieve the VIN from the file, V8 is probably using the correct bank, V7 is probably using the wrong bank.
Can you send me the file that you are using so I can verify that and fix the problem in V7?

Regards
Paul

GMC-2002-Dmax
April 10th, 2015, 06:50 AM
Yes Sir,

Its every file, and no matter what VIN I change it to it still displays the same wrong garbled VIN, quite strange.

You have an email

Blacky
April 10th, 2015, 09:03 AM
New update "Release Candidate 2" posted here:

https://forum.efilive.com/showthread.php?25402-April-2015-EFILive-Release-Candidate-2

We plan on promoting this RC2 version to the full public release on Monday Australian time, which is Sunday night US time.

Regards
Paul