Current Public Release (Updated - Feb 2019)

[Blacky]

Release Notes:
Whats New (http://download.efilive.com/Software/whatsnew_8_2_23.htm)


Version Numbers:
After installing this release you should have the following software, boot block, firmware versions installed:



[*=1]EFILive V7 software: V7.5.27 To view the installed version, select Help->About (in the V7 Scan or Tune software).
[*=1]EFILive V8 software: V8.2.23 To view the installed version, select Help->About (in the V8 Scan and Tune software).
[*=1]Boot Block: V2.07.008 (Jul 4, 2018) To view/update the Boot Block, click the [Check Firmware] button in the V8 Scan and Tune software.
[*=1] Firmware: V2.07.139 (Nov 26, 2018) To view/update the Firmware, click the [Check Firmware] button in the V8 Scan and Tune software.


Download here:
Download EFILive V7.5 (http://download.efilive.com/Software/V7.5/EFILiveV7.5.27_Setup.exe)
Download EFILive V8 (http://download.efilive.com/Software/V8/EFILiveV8.2.23_Setup.exe)


Known Issues:
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 and fully integrated with the V8 tuning tool software.


Issue #2:
When logging DMA PIDs (i.e. PIDs whose names end with "_M" or "_DMA"), if the ignition is switched off for an extended period while data logging but data logging is not terminated, then when the ignition is switched on again the data log automatically continues. However the DMA PIDs may no longer return valid data.
Workaround:
EFILive recommends stopping the data log and restarting the data log when switching off the ignition for extended periods.


Issue #3:
When displaying logged data in the V8 Scan Tool on the [F3: Data] page, the PID values always display in their base/metric units - regardless of the user selected display units. The Minimum, Average, Maximum and Std Dev values correctly display in the user selected display units.

Workaround:
Ensure the user selected units are always the PID's default metric units.
Will be fixed in the next update.


.

[Chavez91]

Sweet! Thanks!!! :D

Question,

Trying to define a User Defined PID, When I hit "Generate" in the compiler, it gives me the error "Invalid DMA Address: 'D0001480'"

Im assuming there are limitations on the addresses? Is there a way to get them raised as I know the address is valid and able to call it via other tools. :)

[Blacky]

Sweet! Thanks!!! :D

Question,

Trying to define a User Defined PID, When I hit "Generate" in the compiler, it gives me the error "Invalid DMA Address: 'D0001480'"

Im assuming there are limitations on the addresses? Is there a way to get them raised as I know the address is valid and able to call it via other tools. :)

I'm pretty sure there is no numerical limit on the DMA address value (other than the 32 bit limit).
That error occurs when there is a mismatch between the number of OS numbers listed in the "OS=" line v's the number of addresses listed in the <DMA_PID>= line.

Regards
Paul

[Blacky]

I'm pretty sure there is no numerical limit on the DMA address value (other than the 32 bit limit).
That error occurs when there is a mismatch between the number of OS numbers listed in the "OS=" line v's the number of addresses listed in the <DMA_PID>= line.

Regards
Paul

My bad, the DMA address is handled as a signed value. 0xD0001480 is negative when treated as a signed 32 bit value. That is triggering the "BAD Address" error.
I'll look into a solution...

Regards
Paul

[Blacky]

Sweet! Thanks!!! :D

Question,

Trying to define a User Defined PID, When I hit "Generate" in the compiler, it gives me the error "Invalid DMA Address: 'D0001480'"

Im assuming there are limitations on the addresses? Is there a way to get them raised as I know the address is valid and able to call it via other tools. :)

Updated version of EFILive_UserPID.exe that handles DMA addresses as unsigned 32 bit values. Available here: http://download.efilive.com/Software/V8/EFILive_UserPID.rar

Also, please see the comment in the LS1B.ini file in the "User Defined PIDs" folder. (Ignore the part about 24 bits, I have just increased it to 32 bits, unsigned)
But be aware that for the named controllers the most significant byte is automatically ORed into the address by the EFILive software.


; __________________________________________________ ________________________
;
[Dma_Addr]
; __________________________________________________ ________________________
; The [Dma_Addr] section describes the memory addresses for each DMA PID
; for each supported operating system.

; DMA PID addresses are specified as hexadecimal WITHOUT any '$' or '0x' prefix.
; Any address defined as . means that the DMA PID is not defined/available for the corresponding operating system.

; These are just sample address values (not real address values) to show how the address values for each PID
; are placed in the same column as the OS for which they are intended.

; NOTE:
; Some controllers use 32 bits for DMA addresses, EFILive only allows 24 bit addresses to be specified in this file.
; EFILive automatically adds the most significant byte as follows:
; - For E39, E39A, E78, E92, E98, E80, E81, E82, E84, T87, E83A and E83B EFILive ORs the DMA address provided with 0x40000000
; - For E20 and E40 EFILive ORs the DMA address provided with 0xFF000000

[Chavez91]

Awesome!

Ill give it a shot!

[Chavez91]

Everything compiled correctly. Gonna run out and test.

Second Thing.

Running on the new software and have a customer trying to flash an E86B. Its making it to around 55-60% full flash and we are getting an $0311 code bbx. Unfortunately they cant pass through.

22614

[GMPX]

Josh, is this the first time the customer has tried to flash that vehicle?
The error indicates the ECM is not in the correct mode for programming, not sure why which is why I asked is this the first time for the vehicle or just since the update.

[Chavez91]

This customer has been running tunes for about 2 years now with no issues. He requested the most updated tunes we had today, so he updated to this release, and that's when the issues started. The files we sent him today, nor any of his old files will Full Flash. He can cal flash any of the files with an 80% or so success ratio, but the truck is in a no start condition.

[Chavez91]

Updated version of EFILive_UserPID.exe that handles DMA addresses as unsigned 32 bit values. Available here: http://download.efilive.com/Software/V8/EFILive_UserPID.rar

Also, please see the comment in the LS1B.ini file in the "User Defined PIDs" folder. (Ignore the part about 24 bits, I have just increased it to 32 bits, unsigned)
But be aware that for the named controllers the most significant byte is automatically ORed into the address by the EFILive software.


; __________________________________________________ ________________________
;
[Dma_Addr]
; __________________________________________________ ________________________
; The [Dma_Addr] section describes the memory addresses for each DMA PID
; for each supported operating system.

; DMA PID addresses are specified as hexadecimal WITHOUT any '$' or '0x' prefix.
; Any address defined as . means that the DMA PID is not defined/available for the corresponding operating system.

; These are just sample address values (not real address values) to show how the address values for each PID
; are placed in the same column as the OS for which they are intended.

; NOTE:
; Some controllers use 32 bits for DMA addresses, EFILive only allows 24 bit addresses to be specified in this file.
; EFILive automatically adds the most significant byte as follows:
; - For E39, E39A, E78, E92, E98, E80, E81, E82, E84, T87, E83A and E83B EFILive ORs the DMA address provided with 0x40000000
; - For E20 and E40 EFILive ORs the DMA address provided with 0xFF000000

So made it a little further. The PIDS compile. When I try to validate them, it seems to be pulling the Speedo System Segment # as the OS #?

Not trying to be a pain in the ass.... Just pushing extra buttons today i guess. :angel_innocent:

22615

[GMPX]

This customer has been running tunes for about 2 years now with no issues. He requested the most updated tunes we had today, so he updated to this release, and that's when the issues started. The files we sent him today, nor any of his old files will Full Flash. He can cal flash any of the files with an 80% or so success ratio, but the truck is in a no start condition.
Bench testing now so see if everything is still good with our setup.

[GMPX]

Using the new public release, Black Box flashing bench test resulted in the cal flash and full flash working fine.
The cal flash I did twice without a hitch.
The full flash did fail once with an $0281 error (FlashScan did not receive valid data from the connected vehicle) which is usually caused by the ECM taking too long to erase the flash and Flashscan times out.
Just retrying the full flash after that initial failure and it worked fine so I don't think there is anything fundamentally wrong with the update as it is.
Not that it should make any difference but the ECM OS I was using is 12669774.

As you guys know all too often errors can happen when people update software but not the firmware and/or scripts to match the release, given the customer is remote can you be 100% sure they did the FW/Scripts update too?

[Chavez91]

Using the new public release, Black Box flashing bench test resulted in the cal flash and full flash working fine.
The cal flash I did twice without a hitch.
The full flash did fail once with an $0281 error (FlashScan did not receive valid data from the connected vehicle) which is usually caused by the ECM taking too long to erase the flash and Flashscan times out.
Just retrying the full flash after that initial failure and it worked fine so I don't think there is anything fundamentally wrong with the update as it is.
Not that it should make any difference but the ECM OS I was using is 12669774.

As you guys know all too often errors can happen when people update software but not the firmware and/or scripts to match the release, given the customer is remote can you be 100% sure they did the FW/Scripts update too?

Yes, I am 100% sure that the customer has updated firmware and scripts to match as we did this through a remote support. Unfortunately the customer only has desktop access where the truck is located, so pass through flashing is not an option currently.

Are there any other files that you would need from me to help? Im going to do a little bit of testing on the bench this morning.

[Chavez91]

Using the new public release, Black Box flashing bench test resulted in the cal flash and full flash working fine.
The cal flash I did twice without a hitch.
The full flash did fail once with an $0281 error (FlashScan did not receive valid data from the connected vehicle) which is usually caused by the ECM taking too long to erase the flash and Flashscan times out.
Just retrying the full flash after that initial failure and it worked fine so I don't think there is anything fundamentally wrong with the update as it is.
Not that it should make any difference but the ECM OS I was using is 12669774.

As you guys know all too often errors can happen when people update software but not the firmware and/or scripts to match the release, given the customer is remote can you be 100% sure they did the FW/Scripts update too?


Just and Update. Did remote support with the customer, the customer was able to obtain access to a laptop. Double checked the current firmware and all the config files, they were all up to date. Also formatted the Autocal and updated everything as well. Still getting the $0311. Attached screen shots.

As far as my bench testing goes, I have slightly differing results. On ALL Pass-Through full flashes, the flash will fail EVERY TIME. I get an $0101 code after the first segment erase and program. (attached screenshot as well) But if I use BBX on the autocal, the flash will complete successfully.

On my bench flashes, I was able to get you Vehicle Spy logs, I can email you those if they will help as they have complete timestamps and everything you should need to figure out what is going wrong.

If there is anything else you need, let me know. I will be grabbing the new trace files off the customers laptop and I can get you the trace files for my bench flashes as well if you would like.

But if the $0311 is for it not being in the correct mode for programming, Its still does make it quite a ways through the flash before throwing the error


22616226172261822619

[GMPX]

Unfortunately it is now a long weekend public holiday here in Aus and NZ and I am away from my PC all weekend so we won't get a chance to look at this until the 29th (our time).
If you could please send over what you have logged to our support Email address one of us will look at it when we get back from holiday.
It all sounds like timing issues to me, I don't know why my E86B flashes fine here in pass-through and BBx but yours and your customers is failing.
One of the downsides of the Bosch ECM's is the flash tool has very little control over the process, you just send the commands and data to flash and hope the ECM handles it correctly. Makes it easy for flash tools to implement but when things go wrong it is a pain to figure out what is going wrong when things go wrong.
I'm sure the traces will show it but did it seem to just stop for a while then error out? If so that would indicate to me the erase portion is taking too long (it does multiple erases during the flash).

"But if I use BBX on the autocal, the flash will complete successfully." - Does this mean the customer is now up and running or was this just your bench testing results?

[joecar]

My bad, the DMA address is handled as a signed value. 0xD0001480 is negative when treated as a signed 32 bit value. That is triggering the "BAD Address" error.
I'll look into a solution...

Regards
Paul
Good find... signed vs unsigned is the programmer's curse (almost as bad as off-one)

:cheers:

[aaronc7]

I have a software question / possibly small request. Not sure if this is the right place for it, but it seems to be the active conversation for the latest software.

I'm probably in the minority, but I use BBX most often for street logging and I'm trying to optimize the process of configuring the BBX and ensuring V8 / V7.5 software is talking the best it can.

I have a lot of custom defined "calculated" PIDs. I have all these defined for the V7.5 scan software which is where most of the real work is done of course. I know in the V8 BBX menu you can define up to 8 "v7" calc params to automatically log, but sometimes I exceed that and I also like to actually see the calculated PID in the log list vs the "v7" menu.

Which led me try and define all the same custom PIDs in V8 software. The problem I've had with the V8 software is the custom created PIDs you have to pick some other prefix... I.E. it might have to be USER.FUELPRES vs CALC.FUELPRES (how it's defined in v7). My fix has been to manually edit the EFILive calculated PIDs .ini file (don't have PC with me, forget exact name). This works fine, but the equation editor function within V8 software won't let you edit the EFILive / CALC. params and sometimes that ini file gets overwritten when a new version is installed. (I make backups before an update)

Is it possible to allow user created PIDs to start with a CALC. prefix or allow the user to edit the efilive defined calculated PIDs within the software? I am doing the latter now, via notepad++, but would prefer the GUI.

Anyways, just throwing an idea out.

[Blacky]

I have a software question / possibly small request. Not sure if this is the right place for it, but it seems to be the active conversation for the latest software.

I'm probably in the minority, but I use BBX most often for street logging and I'm trying to optimize the process of configuring the BBX and ensuring V8 / V7.5 software is talking the best it can.

I have a lot of custom defined "calculated" PIDs. I have all these defined for the V7.5 scan software which is where most of the real work is done of course. I know in the V8 BBX menu you can define up to 8 "v7" calc params to automatically log, but sometimes I exceed that and I also like to actually see the calculated PID in the log list vs the "v7" menu.

Which led me try and define all the same custom PIDs in V8 software. The problem I've had with the V8 software is the custom created PIDs you have to pick some other prefix... I.E. it might have to be USER.FUELPRES vs CALC.FUELPRES (how it's defined in v7). My fix has been to manually edit the EFILive calculated PIDs .ini file (don't have PC with me, forget exact name). This works fine, but the equation editor function within V8 software won't let you edit the EFILive / CALC. params and sometimes that ini file gets overwritten when a new version is installed. (I make backups before an update)

Is it possible to allow user created PIDs to start with a CALC. prefix or allow the user to edit the efilive defined calculated PIDs within the software? I am doing the latter now, via notepad++, but would prefer the GUI.

Anyways, just throwing an idea out.

The CALC. prefix is reserved for EFILive defined calculated PIDs so that user changes are not overwritten by the next update - which always replaces/overwrites the files containing the EFILive calculated PIDs.
Any reason why you must use the CALC. prefix? What's wrong with using some other prefix?

Regards
Paul

[Blacky]

So made it a little further. The PIDS compile. When I try to validate them, it seems to be pulling the Speedo System Segment # as the OS #?

Not trying to be a pain in the ass.... Just pushing extra buttons today i guess. :angel_innocent:

22615

Well that is strange. I'll look into it.
Paul

[Chavez91]

Unfortunately it is now a long weekend public holiday here in Aus and NZ and I am away from my PC all weekend so we won't get a chance to look at this until the 29th (our time).
If you could please send over what you have logged to our support Email address one of us will look at it when we get back from holiday.
It all sounds like timing issues to me, I don't know why my E86B flashes fine here in pass-through and BBx but yours and your customers is failing.
One of the downsides of the Bosch ECM's is the flash tool has very little control over the process, you just send the commands and data to flash and hope the ECM handles it correctly. Makes it easy for flash tools to implement but when things go wrong it is a pain to figure out what is going wrong when things go wrong.
I'm sure the traces will show it but did it seem to just stop for a while then error out? If so that would indicate to me the erase portion is taking too long (it does multiple erases during the flash).

"But if I use BBX on the autocal, the flash will complete successfully." - Does this mean the customer is now up and running or was this just your bench testing results?

Got a little occupied, Files will be on their way to support here in the next hour or so.

But no, the customer is not up and running. Truck is still down. He is still receiving the $0311 error. The successful autocal flash was on my end on my bench setup. But the similar method was a no go for the customer.

[Blacky]

So made it a little further. The PIDS compile. When I try to validate them, it seems to be pulling the Speedo System Segment # as the OS #?

Not trying to be a pain in the ass.... Just pushing extra buttons today i guess. :angel_innocent:

22615

Turns out the E86A.pmm file is mis-configured to retrieve the OS using $1A,$C2 (which is the speedo segment). E86B suffers the same problem.

I've attached updated *.pmm files to correct the problem.
22627
Download and unzip the two files into the folder: \Program Files (x86)\EFILive\V8\Config

Note: The 12641475 speedo number can be manually removed from the drop down list by editing the file: \Documents\EFILive\V8\Config\PIDs\E86A.pxl

[aaronc7]

The CALC. prefix is reserved for EFILive defined calculated PIDs so that user changes are not overwritten by the next update - which always replaces/overwrites the files containing the EFILive calculated PIDs.
Any reason why you must use the CALC. prefix? What's wrong with using some other prefix?

Regards
Paul

Paul, I think I found my fix. For some reason I had it in my head that V7 calculated PIDs had to have a CALC prefix (probably from following the various guides on here and PDFs, I think they all use CALC). But I think the easy fix for me is to just name all of my calculated PIDs with the USER (or whatever) prefix in calc_pids.txt and that will ensure V7/V8 software is on the same page. V7 scan software doesn't seem to acknowledge any custom defined params other than CALC as (calculated), but that's no biggie.

Thanks for the reply.

[Chavez91]

Turns out the E86A.pmm file is mis-configured to retrieve the OS using $1A,$C2 (which is the speedo segment). E86B suffers the same problem.

I've attached updated *.pmm files to correct the problem.
22627
Download and unzip the two files into the folder: \Program Files (x86)\EFILive\V8\Config

Note: The 12641475 speedo number can be manually removed from the drop down list by editing the file: \Documents\EFILive\V8\Config\PIDs\E86A.pxl

Sweet! Thankyou Very Much! Closer! haha Next issue seems to be that it is still handling the address as 24bit. I saw your warning as you stated above...


; NOTE:
; Some controllers use 32 bits for DMA addresses, EFILive only allows 24 bit addresses to be specified in this file.
; EFILive automatically adds the most significant byte as follows:
; - For E39, E39A, E78, E92, E98, E80, E81, E82, E84, T87, E83A and E83B EFILive ORs the DMA address provided with 0x40000000
; - For E20 and E40 EFILive ORs the DMA address provided with 0xFF000000

If it helps any, here is V8 calling for the DMA. It looks to be missing the $DO Hi-Byte.
22628

And here is the pid being called with Mode $23 manually, granted it isnt 100% the same as the Mode $2D, $2C, $2A combo, but it should show what Im talking about. :)
22629

[Blacky]

Sweet! Thankyou Very Much! Closer! haha Next issue seems to be that it is still handling the address as 24bit. I saw your warning as you stated above...


; NOTE:
; Some controllers use 32 bits for DMA addresses, EFILive only allows 24 bit addresses to be specified in this file.
; EFILive automatically adds the most significant byte as follows:
; - For E39, E39A, E78, E92, E98, E80, E81, E82, E84, T87, E83A and E83B EFILive ORs the DMA address provided with 0x40000000
; - For E20 and E40 EFILive ORs the DMA address provided with 0xFF000000

If it helps any, here is V8 calling for the DMA. It looks to be missing the $DO Hi-Byte.
22628

And here is the pid being called with Mode $23 manually, granted it isnt 100% the same as the Mode $2D, $2C, $2A combo, but it should show what Im talking about. :)
22629

What controller are you trying to do this for?
A40, A50, E46, E35A, E35B, E86A and E86B are ECMs that the software defaults to 3 byte addressing - is it one of those?

On closer inspection, it appears that the E35A and E35B only support 3 byte addressing, the E86A and E86B appear to support 4 byte addressing.

It was most likely a copy/paste error when setting up the E86A/B config files (based off of the E35 config files) that they got set to 3 byte addressing instead of 4.
So if it is E86A/E86B that you are working on (I presume it is based on previous posts) then try the attached/updated *.pmm files - which allow for 4-byte addressing.

22631

Regards
Paul

[ScarabEpic22]

I'm adding FlexFuel to my Sonic (Ross your write up from 2012 for your Cruze was very helpful!) and it appears I'm missing the FlexFuel Diagnostic enabler (B0186) in my OS (12655493). I believe this only enables/disables the FF sensor diagnostics to lookup the 2 DTCs related to the sensor, it'd be a nice-to-have if it's not much work.

[nm2769]

After this latest update it has left V7 & V8 completely unusable. Tried doing a complete uninstall and deleting all files and registry entries and reinstalling. Same issues V7 gets a Stream Write Error and V8 get 10 to 15 Access Violation Errors. Have to use task manager to force quit the program. Please help.
22666
22667

[Blacky]

After this latest update it has left V7 & V8 completely unusable. Tried doing a complete uninstall and deleting all files and registry entries and reinstalling. Same issues V7 gets a Stream Write Error and V8 get 10 to 15 Access Violation Errors. Have to use task manager to force quit the program. Please help.


At what stage do these errors occur? What steps do you perform after the software starts before the errors show up?

Some detective work you can try:

For V8, hold down the Ctrl key on the PC keyboard and double click the V8 Scan and Tune icon to start the software. That should create trace/log files in the \Documents\EFILive\V8\Trace folder. Look in those files (using Notepad) to see if you can see any reason for the errors.

For V7: Change the properties of the desk top icon so that the "Target" field has a space, forward slash, lowercase L after it, like this:
22668

Then run the V7 software, that will create a log file in the folder: \Program Files (x86)\EFILive\V7.5 called StartupLog.txt.
You will need to right click on the desktop icon and select "Run as Administrator" otherwise V7 won't have permission to create the log file in the "Program Files (x86)" folder.
Again, check that log file for any clues as to why those errors occur.

Regards
Paul

[nm2769]

At what stage do these errors occur? What steps do you perform after the software starts before the errors show up?

Some detective work you can try:

For V8, hold down the Ctrl key on the PC keyboard and double click the V8 Scan and Tune icon to start the software. That should create trace/log files in the \Documents\EFILive\V8\Trace folder. Look in those files (using Notepad) to see if you can see any reason for the errors.

For V7: Change the properties of the desk top icon so that the "Target" field has a space, forward slash, lowercase L after it, like this:
22668

Then run the V7 software, that will create a log file in the folder: \Program Files (x86)\EFILive\V7.5 called StartupLog.txt.
You will need to right click on the desktop icon and select "Run as Administrator" otherwise V7 won't have permission to create the log file in the "Program Files (x86)" folder.
Again, check that log file for any clues as to why those errors occur.

Regards
Paul

Paul, the errors occur at startup. Both V7 & V8 get the errors immediately after the program starts. V8 has what seems like an endless Access Errors at startup and I have to use task manger to force close it. V7 error pops up and when you click ok V7 closes on it own. I checked the trace/log files and I don't see anything that points to the issue. I broke out an older laptop that still has windows 8 on it and have been using it for now. I'm not sure if there are some issues with windows 10 or what that may be causing issues with EFILive. I'm going to reset the windows 10 laptop and see if that helps. I'm not sure what else to do.

Thanks
Nick

[Blacky]

Paul, the errors occur at startup. Both V7 & V8 get the errors immediately after the program starts. V8 has what seems like an endless Access Errors at startup and I have to use task manger to force close it. V7 error pops up and when you click ok V7 closes on it own. I checked the trace/log files and I don't see anything that points to the issue. I broke out an older laptop that still has windows 8 on it and have been using it for now. I'm not sure if there are some issues with windows 10 or what that may be causing issues with EFILive. I'm going to reset the windows 10 laptop and see if that helps. I'm not sure what else to do.

Thanks
Nick

It just might be a driver issue since both V7 and V8 attempt to use the USB driver to detect any FlashScan/AutoCal devices on startup. You could try completely removing the drivers and re-installing them as per the first post in this thread.
https://forum.efilive.com/showthread.php?22760-Uninstalling-and-reinstalling-FlashScan-AutoCal-USB-drivers

Regards
Paul

[Bdirtymax]

I'm getting an error when V8 tries to update. Haven't tried 7.5 yet. Screenshots attached. I tried it closing V8 before trying to update and with leaving V8 open.

[Blacky]

I'm getting an error when V8 tries to update. Haven't tried 7.5 yet. Screenshots attached. I tried it closing V8 before trying to update and with leaving V8 open.

If any "key" files have been changed since the installation of the previous public release, then you will see that message. That can happen if you've downloaded and installed a beta version or even a pre-release version from this forum. Or if any of the kye files have been modified/damaged since they were installed.
What it means is the patch engine can't find a recognized set of files that it can patch. The patch engine can't update any files until/unless it is 100% certain of the contents of those key files and that the contents of those key files match exactly one of the previous versions that it is configured to patch.

In any case the solution is to download and install the entire installation instead of just trying to apply the latest patch using the "Check for Updates" option.
Download V7.5 and V8 from here: http://www.efilive.com/latest/cat/download-efilive

P.S. To avoid confusion, the error message dialog box should explain that - it will be updated in the next release.

Regards
Paul

[Bdirtymax]

If any "key" files have been changed since the installation of the previous public release, then you will see that message. That can happen if you've downloaded and installed a beta version or even a pre-release version from this forum. Or if any of the kye files have been modified/damaged since they were installed.
What it means is the patch engine can't find a recognized set of files that it can patch. The patch engine can't update any files until/unless it is 100% certain of the contents of those key files and that the contents of those key files match exactly one of the previous versions that it is configured to patch.

In any case the solution is to download and install the entire installation instead of just trying to apply the latest patch using the "Check for Updates" option.
Download V7.5 and V8 from here: http://www.efilive.com/latest/cat/download-efilive

P.S. To avoid confusion, the error message dialog box should explain that - it will be updated in the next release.

Regards
Paul

Ok thanks Paul. Not sure how it happened. The only files I've downloaded were sent from you when we were trying to figure out the error code with v7.5. I'll download the setup again.
Thanks

[comnrailpwr]

Don't know if this pertains to this update or not as it is a feature I rarely use. When setting security restrictions with v8 to " can be viewed and modified" and that being the only restriction, the end user still cannot open the file with the v7.5 tune editor. Gives the following errors. Any ideas or possible a bug?
https://uploads.tapatalk-cdn.com/20190328/ff1451551d43838792d44f8f90bd1191.jpg
https://uploads.tapatalk-cdn.com/20190328/031599a8afdfd33357bb09b8335d29d9.jpg

[Blacky]

Don't know if this pertains to this update or not as it is a feature I rarely use. When setting security restrictions with v8 to " can be viewed and modified" and that being the only restriction, the end user still cannot open the file with the v7.5 tune editor. Gives the following errors. Any ideas or possible a bug?


Are any other security options set? V7 does not fully support the V8 security settings and so it will not open any file if any security options are set.
To edit the file, first remove all security options using the V8 software.

When the V8 editor is released it will support the security settings fully.

Regards
Paul

[comnrailpwr]

I apologise, it had a VIN restriction as well. I thought I had done this in the past but maybe not.

[RDLLC]

getting a $0101 wrong ecm type on a 2018 CME when trying to license. is there a later beta software i should be using

[GMPX]

An $0101 error and wrong ECM type don't really correlate, however I think what it is will be because that is a 2018 you will need to purchase a Security Gateway bypass harness, on the 2018+ these ECM's cannot be reflashed directly through the OBD-II port as Dodge have a module that acts like a firewall on the CAN port.
I'm sorry I don't have a link to send you to, but if you just Google "Dodge Ram SGM Bypass" you'll see what I mean.

[Boost]

I am having an issue with the latest update where my PCM is behaving like it is unlicensed. I will start a new thread about it in Gen III.

[Hib Halverson]

Is the Scan application going to support the GM E99 PCM?

If so, when might that happen.

[GMPX]

Hib, the V8 Scantool supports the E99 ECM (in fact all of GM's current ECM's). However V7 scantool does not have an E99 option, if you still wanted to use V7 scan on the E99 you could select a controller like the E92 and log the E99.

Cheers,
Ross

[Hib Halverson]

Thanks, Ross!

[wesam]

Hib, the V8 Scantool supports the E99 ECM (in fact all of GM's current ECM's). However V7 scantool does not have an E99 option, if you still wanted to use V7 scan on the E99 you could select a controller like the E92 and log the E99.

Cheers,
Ross

Any plans to support tuning for E99 in the near future ?

[zfuller123]

Is there kind of a rollup to this software release and the bug fixes that have been found/added to this thread? Asking for a friend :wave:

Main reason I'm asking is because we've had a pattern on one particular type of CME trucks that even older base files are having the same problems with (I haven't really seen much in the thread about CME's) - and we're not sure if it's since the newer software or a combination of us using newer and customer using older (because firmware is the same back to November 2018)... just trying to see if we can figure out the 'link' on our end before raising an alarm. That's the main reason asking for an updated build if there is one ready or available so we for sure have all the fixes for everything in one download since we're troubleshooting remote trucks and want to take the guesswork out of what they may or may not have applied from this thread... not that what I've read should affect CME's, but I feel that something else might be at play on the C&C trucks in particular just not sure what and trying to systematically rule things out.