September 2019, Beta Release - Update 2

Printable View

August 28th, 2019
Blacky

September 2019, Beta Release - Update 2
ATTENTION - BETA SOFTWARE RELEASE

We strongly recommend that you do not install the beta software over the top of your production systems. It is possible that the beta test software may fail and your production system may not be recoverable. lf you conduct a tuning business, please take the necessary precautions to protect your business. EFILive recommends beta testers use a separate FlashScan V2 device (when installing the latest beta firmware) and only install the EFILive beta test software on a separate PC, laptop or virtual machine.

The current public release is available here.

Release Notes:

Whats New

Version Numbers:
After installing this beta release you should have the following software, boot block, firmware versions installed:
- EFILive V7 software: V7.5.29 To view the installed version, select Help->About (in the V7 Scan or Tune software).
- EFILive V8 software: V8.2.25 To view the installed version, select Help->About (in the V8 Scan and Tune software).
- 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.
- Firmware: V2.07.141 (Sep 19, 2019) To view/update the Firmware, click the [Check Firmware] button in the V8 Scan and Tune software.
Download here:

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.
.
September 13th, 2019
Chavez91

Paul,

Has the 32 bit limit on PKT PIDs been lifted yet?

I also might have a problem with E98 DMA pids as welll.

Example.

If requesting address 0x400134E8, when its verifying the PIDS, it seems to only be requesting 0x40000000. It doesent send the rest of the address.

I will 100% verify this later this afternoon with some logs for you as I forgot to save when I tested yesterday, unless you beat me to it. lol

If you would like me to send you a copy of my Custom List, Id be more than glad to PM it to you.

One more... It seems that when I use a CAX with 32bit FLT and use the 'Inv' function. (Its for the EQ AFR table on cummins) it breaks everything and just displays 0's... but set that back to zero and it displays again. Factor is set to '1'. I can send you an example of this as well if you'd like.

Thanks!
September 13th, 2019
Blacky

Quote:

Originally Posted by Chavez91

Paul,
Has the 32 bit limit on PKT PIDs been lifted yet?

Not in this release. Working on it for the next major release of V8.

Quote:

Originally Posted by Chavez91

I also might have a problem with E98 DMA pids as welll.

Example.

If requesting address 0x400134E8, when its verifying the PIDS, it seems to only be requesting 0x40000000. It doesent send the rest of the address.

I will 100% verify this later this afternoon with some logs for you as I forgot to save when I tested yesterday, unless you beat me to it. lol

If you would like me to send you a copy of my Custom List, Id be more than glad to PM it to you.

One more... It seems that when I use a CAX with 32bit FLT and use the 'Inv' function. (Its for the EQ AFR table on cummins) it breaks everything and just displays 0's... but set that back to zero and it displays again. Factor is set to '1'. I can send you an example of this as well if you'd like.

Thanks!

I'll take a look into both of those issues.
Regards
Paul
September 17th, 2019
Blacky

Quote:

Originally Posted by Chavez91

One more... It seems that when I use a CAX with 32bit FLT and use the 'Inv' function. (Its for the EQ AFR table on cummins) it breaks everything and just displays 0's... but set that back to zero and it displays again. Factor is set to '1'. I can send you an example of this as well if you'd like.
Thanks!

The problem is:

When a calibration definition is loaded the software figures out the hard min and hard max values based on the bit size, the factor, the offset and the inverse settings. That makes sense for SNM and UNM type calibrations that have fixed raw/hex ranges but it makes no sense for FLT type calibrations.

Unfortunately, the "auto-generate hard min and hard max values" routine is being called when the data type is FLT and inverse (it should not be called - it should just use the values supplied by the cax file) . That causes the hard min to be set to 1E-35 and the hard max to be set to -1E-35. Those values are wrong and the min is actually greater than the max. That is what is causing the calibration to display zeros. I cannot see any workaround to the problem so a fix will be in the next beta update (which is due out this week sometime).

Still working on the user defined DMA PID address issue...

Regards
Paul
September 17th, 2019
Chavez91

Quote:

Originally Posted by Blacky

The problem is:

When a calibration definition is loaded the software figures out the hard min and hard max values based on the bit size, the factor, the offset and the inverse settings. That makes sense for SNM and UNM type calibrations that have fixed raw/hex ranges but it makes no sense for FLT type calibrations.

Unfortunately, the "auto-generate hard min and hard max values" routine is being called when the data type is FLT and inverse (it should not be called - it should just use the values supplied by the cax file) . That causes the hard min to be set to 1E-35 and the hard max to be set to -1E-35. Those values are wrong and the min is actually greater than the max. That is what is causing the calibration to display zeros. I cannot see any workaround to the problem so a fix will be in the next beta update (which is due out this week sometime).

Still working on the user defined DMA PID address issue...

Regards
Paul

Ahhh.... That makes sense! haha. Well thanks for figuring it out! :D

If there is anything you need from me for the DMA issue, let me know.

Thanks again Paul!
September 17th, 2019
Blacky

Quote:

Originally Posted by Chavez91

I also might have a problem with E98 DMA pids as welll.

Example.

If requesting address 0x400134E8, when its verifying the PIDS, it seems to only be requesting 0x40000000. It doesent send the rest of the address.

If the controller's operating system against which you are verifying the DMA PID(s) is not defined for the DMA PID, then it will try to verify with the address $40000000 - and obviously fail and mark the PID as unverified.
So make sure that the OS in the controller is the same* OS listed in the [Dma_OS] section and that it matches the same "column" as the DMA PID's address in the [Dma_Addr] section.

*Same means the same GM stock OS, so if you have a custom OS in the ECM then you should use the matching GM stock OS in the *.ini definition file.

Regards
Paul
September 22nd, 2019
Blacky

Quote:

Originally Posted by Chavez91

One more... It seems that when I use a CAX with 32bit FLT and use the 'Inv' function. (Its for the EQ AFR table on cummins) it breaks everything and just displays 0's... but set that back to zero and it displays again. Factor is set to '1'. I can send you an example of this as well if you'd like.
Thanks!

That should be fixed with the latest beta-2 update released today.
Regards
Paul
September 22nd, 2019
Highlander

Quote:

Originally Posted by Blacky

That should be fixed with the latest beta-2 update released today.
Regards
Paul

V8 Editor V8 Editor V8 Editor V8 Editor........ I almost forgot...V8 Editor.. how can i use it????
September 25th, 2019
honduh

I am trying to license and tune a 2019 Cummins 6.7 and the bypass switch in slots 6,14 on the OBD2 port don't power the OBD2 port. With the factory wires in slots 6, 14 i receive the error code $0333: Security Access Denied ($33). How should I proceed? I am using version V8.2.25 with Firmware 2.07.141
September 25th, 2019
GMPX

If you are still getting the "SGM Detected" message then you need to recheck the instructions for your bypass wiring.
September 25th, 2019
honduh

Quote:

Originally Posted by GMPX

If you are still getting the "SGM Detected" message then you need to recheck the instructions for your bypass wiring.

Thank you for the reply—

I tried connecting the bypass wire into all the different slots and none of them seem to provide power. However, I put the factory wires back into the obd2 port and it powers the port.

Can anyone verify how many volts the bypass switch provides to the obd2 port?
September 25th, 2019
GMPX

Quote:

Originally Posted by honduh

Can anyone verify how many volts the bypass switch provides to the obd2 port?

I think you REALLY need to contact the company that makes the bypass kit for guidance, the OBD-II port needs 12V.
September 25th, 2019
honduh

Will do! Thank you.
October 10th, 2019
Highlander

V8 is not copying the flash scripts onto the autocals. No matter what I do always returns Error $0502
December 13th, 2019
Chavez91

Hey Paul,

Here's a funny bug.

Lets say you are building a CAX. If you use windows calculator in programmer mode (windows 10), type in an address, (using just your keyboard) hit '+' and add your offset hit 'Enter' then 'Ctrl+C' and then paste that address into your CAX.

When you go to load the CAX into 7.5... It errors out saying that the 'PCM is unrecognizable and to send the file in. Backspace that address and retype the same exact address in by hand and boom... works perfectly fine. lol
December 13th, 2019
Blacky

1 Attachment(s)

It's a known bug (I mean feature) in the Windows calculator. The calculator tries to be "smart" and add the Unicode characters:

E280AC Pop directional formatting
E280AD Left-to-right override

So it ends up looking like this in the cax file:

Attachment 23128

Not sure what Microsoft was thinking when they chose to make that brain-dead decision.
Lots of complaints online... Google for: windows calculator clipboard error

Regards
Paul
December 13th, 2019
Chavez91

Lol you just beat me to the punchline. I was just writing about that. Gotta love windows programmers lol that definitely got annoying quick
December 14th, 2019
GMPX

That Windows 10 calculator is a major step backwards, I use (daily) a port of the old Windows 7 calculator and never run in to those issues.
https://winaero.com/blog/classic-cal...s-10-creators/
December 20th, 2019
joecar

lol, Microsoft, lol :rotflmao:
January 22nd, 2020
Chavez91

Paul, another bug...

When Caxing 1D table that is 8 bit, if its a single ROW, it decides to skip bytes for fun. lol
Here is where it gets odd, define the 2nd row and now you can see the skipped bytes in the 2nd row

Do it as columns and you're fine. No skipped bytes, lol
January 22nd, 2020
Chavez91

Quote:

Originally Posted by GMPX

That Windows 10 calculator is a major step backwards, I use (daily) a port of the old Windows 7 calculator and never run in to those issues.
https://winaero.com/blog/classic-cal...s-10-creators/

Thats much better!

Thanks! :D
January 23rd, 2020
Blacky

Quote:

Originally Posted by Chavez91

Paul, another bug...

When Caxing 1D table that is 8 bit, if its a single ROW, it decides to skip bytes for fun. lol
Here is where it gets odd, define the 2nd row and now you can see the skipped bytes in the 2nd row

Do it as columns and you're fine. No skipped bytes, lol

Some (many) controller types are defined with a byte-alignment of 2 bytes. That means if a calibration is defined with a data size of 8 bits or less and with an odd number of rows, then the last byte of each column is skipped. That ensures that each column starts on a word boundary.

You can't change that byte alignment with a setting in the cax file - it's hard coded into the software.

In the new V8 editor it is user define-able.
Also in V8, you can simply transpose the table so that rows become columns and columns become rows which makes it easy to view/edit/copy/paste the data in the same format as "other software" :)

Regards
Paul
May 6th, 2020
ATPCummins

2 Attachment(s)

I just uninstalled the current public software and downloaded/installed this beta release. I get this error message when attempting to open any of the 2019-2020 6.7L files from the Mega.nz file link. Any ideas?

Attachment 23282

Attachment 23283

Thanks,
Mike
May 6th, 2020
GMPX

2 Attachment(s)

Mike, the issue is that V7 & V8 have not been updated to load those OS's in any public release.
You can try to extract the attached rar into the Calibrations folder for V7 and the dat file for V8 and then see if your files load up.

CMF_Calz.rar extract to:
C:\Program Files (x86)\EFILive\V7.5\Calibrations\CMF

CMF.dat save to:
C:\Program Files (x86)\EFILive\V8\Controllers\Identify

Cheers,
Ross
May 7th, 2020
2006Cummins

Thanks for the reply Ross. I guess I am a little confused. I see in the release notes that this beta software that I installed supports CMF. I checked to be sure that the CMF .inx and .dat files were installed. I will try uninstalling and reinstalling the software.

Mike
May 8th, 2020
GMPX

It is beta software but it was released in September 2019, the .ctz files you are possibly trying to use came out after that beta was released. The couple of files I posted above contain the updates to support 19/20 files that came out after the beta.
May 12th, 2020
Chavez91

Any Idea why when I bring in a bone stock IA80012.04 file into V7.5.... I get an incorrect checksum? Even converted from XCAL using yalls tool... same problem... V8 too using the files from above.
May 13th, 2020
GMPX

Sorry I'm not sure Josh, the IA80012.04 file I have loads up just fine. I've just sent a PM.
May 13th, 2020
Chavez91

Thanks! Investigating. :thumb_yello:
May 13th, 2020
GMPX

Probably should mention that they are up to IA80012.07 now (released mid April), your file was released Nov 2019 (no clue what they've been changing).