Instructions to change fuel maps on 14CUX Griffith, Chimaera
Discussion
blitzracing said:
On a completely separate note- do we know where the location and value for the bits that disable or enable the MIL lamp?
As Dan is probably celebrating Independence Day, I'll have a stab at answering. The MIL Service and Fault Scan code for TVR variants (not sure if this applies to Ginetta) is located within the ICI Re-entry point routine block in the Main Loop (do you want actual offsets), as shown here (code examples courtesy of DB):
;---------------------------------------------------------------------------
; This is the way the fault checking is done in older code (including TVR).
; This method is not as good since unused bits can get through the mask
; and set the MIL.
;---------------------------------------------------------------------------
; scan for set fault bits
.LCA6F ldaa faultBits_4D
anda #$EF ; mask out bit 4 (DTC 59 -- Group Fault)
oraa faultBits_4B ; OR in all bits from faultBits_4B
oraa faultBits_4C ; OR in all bits from faultBits_4C
anda #$F0 ; low nibble unused for all three
oraa faultBits_49 ; OR in all bits from faultBits_49
oraa faultBits_4A ; OR in all bits from faultBits_4A
beq Write9x00 ; if zero, no faults, branch ahead
ldaa port1data
anda #$FE ; EFI warning light ON
staa port1data
Within Dan's ASM files there is a lot of so-called NEW_STYLE_MIL_CODE which looks to be used in NAS variants only.
There is a MIL_DELAY control flag at $C7C2 which turns the MIL light off at the start of the MIL Service routine.
If wired in, the MIL EFI warning light is switched On in the event of a TPS, ECT, EFT, and Tune Resistor errors. For Build R3360 and later there are also six fault bit masks available in the code.
I had this post ready to go when Dave posted and I'm too lazy to go back over it, so please excuse any repeated points.
Mark, if you are talking about how individual fault bits get enabled or disabled, there is a major difference between earlier code (such as TVR) and later code (such as NAS). Early code handled this very clumsily. It was hard to understand and even harder to tailor to future changes, such as disabling fault codes that didn't work as intended. As you know, There were a number of these abandoned fault codes such as low fuel pressure, air leak, lean mixture and the group fault.
Later code handles fault codes in a much more elegant way and if I were to argue a case for using later code, this would be one of the reasons. There are two levels of bit masking. The first level either allows the fault bit to be stored in memory or to be completely ignored. The second masking level enables the fault to light the MIL. Fault codes 02 and 03 are masked out at this level, so they are stored in memory but do not light the MIL.
If looking at the ASM files, the first masking list can be seen as the 6 bytes at the top of faults.asm. The second level of masking is coded in-line at 'checkFaultBits' in mainLoop.asm. In both cases, software does a Boolean AND between the 6 mask values and the 6 faults bytes which are defined in table 2 here:
http://alum.wpi.edu/~colinb/14cux.html
By the way, each bit in the 6-bytes from address 0049 through 004E has an assigned fault code number. The full list can be seen as the 48 byte table called 'faultCodes' in faults.asm. Most of these are unused, of course, but I wonder what the reasons were for assigning numbers to them. You may also notice that a fault codes's assigned place in memory is also its priority. This is the order in which they would be clocked out to the on-board fault display. Fault bit 0049.0 is the highest priority (code 29 -- ECU failure) and fault bits 004E.6 and 004E.7 are the lowest (codes 02 and 03).
Mark, if you are talking about how individual fault bits get enabled or disabled, there is a major difference between earlier code (such as TVR) and later code (such as NAS). Early code handled this very clumsily. It was hard to understand and even harder to tailor to future changes, such as disabling fault codes that didn't work as intended. As you know, There were a number of these abandoned fault codes such as low fuel pressure, air leak, lean mixture and the group fault.
Later code handles fault codes in a much more elegant way and if I were to argue a case for using later code, this would be one of the reasons. There are two levels of bit masking. The first level either allows the fault bit to be stored in memory or to be completely ignored. The second masking level enables the fault to light the MIL. Fault codes 02 and 03 are masked out at this level, so they are stored in memory but do not light the MIL.
If looking at the ASM files, the first masking list can be seen as the 6 bytes at the top of faults.asm. The second level of masking is coded in-line at 'checkFaultBits' in mainLoop.asm. In both cases, software does a Boolean AND between the 6 mask values and the 6 faults bytes which are defined in table 2 here:
http://alum.wpi.edu/~colinb/14cux.html
By the way, each bit in the 6-bytes from address 0049 through 004E has an assigned fault code number. The full list can be seen as the 48 byte table called 'faultCodes' in faults.asm. Most of these are unused, of course, but I wonder what the reasons were for assigning numbers to them. You may also notice that a fault codes's assigned place in memory is also its priority. This is the order in which they would be clocked out to the on-board fault display. Fault bit 0049.0 is the highest priority (code 29 -- ECU failure) and fault bits 004E.6 and 004E.7 are the lowest (codes 02 and 03).
blitzracing said:
I was hoping for if you go to location xxx hex, and put in yyy hex it will enable the lamp, Im not good at Klingon programming over a soldering Iron 
. I have TVR chipping.
Some questions: . I have TVR chipping.Can you confirm that you want to make the Hex value changes directly to a BIN file and not make the changes at the ASM level? If so, SteveSprint would be your best bet as he's the HexEditor expert.
What tune version are you using? If I have the BIN for it I may be able to help.
Are you looking to reassign the MIL EFI light to some other function or simply force the lamp On?
danbourassa said:
I had this post ready to go when Dave posted and I'm too lazy to go back over it, so please excuse any repeated points.
Mark, if you are talking about how individual fault bits get enabled or disabled, there is a major difference between earlier code (such as TVR) and later code (such as NAS). Early code handled this very clumsily. It was hard to understand and even harder to tailor to future changes, such as disabling fault codes that didn't work as intended. As you know, There were a number of these abandoned fault codes such as low fuel pressure, air leak, lean mixture and the group fault.
Later code handles fault codes in a much more elegant way and if I were to argue a case for using later code, this would be one of the reasons. There are two levels of bit masking. The first level either allows the fault bit to be stored in memory or to be completely ignored. The second masking level enables the fault to light the MIL. Fault codes 02 and 03 are masked out at this level, so they are stored in memory but do not light the MIL.
If looking at the ASM files, the first masking list can be seen as the 6 bytes at the top of faults.asm. The second level of masking is coded in-line at 'checkFaultBits' in mainLoop.asm. In both cases, software does a Boolean AND between the 6 mask values and the 6 faults bytes which are defined in table 2 here:
http://alum.wpi.edu/~colinb/14cux.html
By the way, each bit in the 6-bytes from address 0049 through 004E has an assigned fault code number. The full list can be seen as the 48 byte table called 'faultCodes' in faults.asm. Most of these are unused, of course, but I wonder what the reasons were for assigning numbers to them. You may also notice that a fault codes's assigned place in memory is also its priority. This is the order in which they would be clocked out to the on-board fault display. Fault bit 0049.0 is the highest priority (code 29 -- ECU failure) and fault bits 004E.6 and 004E.7 are the lowest (codes 02 and 03).
I did try Dan. Oh, well. Mark, if you are talking about how individual fault bits get enabled or disabled, there is a major difference between earlier code (such as TVR) and later code (such as NAS). Early code handled this very clumsily. It was hard to understand and even harder to tailor to future changes, such as disabling fault codes that didn't work as intended. As you know, There were a number of these abandoned fault codes such as low fuel pressure, air leak, lean mixture and the group fault.
Later code handles fault codes in a much more elegant way and if I were to argue a case for using later code, this would be one of the reasons. There are two levels of bit masking. The first level either allows the fault bit to be stored in memory or to be completely ignored. The second masking level enables the fault to light the MIL. Fault codes 02 and 03 are masked out at this level, so they are stored in memory but do not light the MIL.
If looking at the ASM files, the first masking list can be seen as the 6 bytes at the top of faults.asm. The second level of masking is coded in-line at 'checkFaultBits' in mainLoop.asm. In both cases, software does a Boolean AND between the 6 mask values and the 6 faults bytes which are defined in table 2 here:
http://alum.wpi.edu/~colinb/14cux.html
By the way, each bit in the 6-bytes from address 0049 through 004E has an assigned fault code number. The full list can be seen as the 48 byte table called 'faultCodes' in faults.asm. Most of these are unused, of course, but I wonder what the reasons were for assigning numbers to them. You may also notice that a fault codes's assigned place in memory is also its priority. This is the order in which they would be clocked out to the on-board fault display. Fault bit 0049.0 is the highest priority (code 29 -- ECU failure) and fault bits 004E.6 and 004E.7 are the lowest (codes 02 and 03).
Mark, I was still in bed this morning when the meaning of your question dawned on me. A good night's sleep can really clear your thinking. I was aware of the non-working MIL in TVRs but never thought it was the ECU. I never noticed the MIL disabling in the TVR code, although I don't remember specifically looking for it. When I get a chance (not today), I will swap ECUs between my Griff (tune R2967-55) and my Range Rover (NAS tune R3526) to try to confirm what you suspect. If this is the case, there will most certainly be a way to re-enable the MIL. But why would they ever disable it??
Mark, Dan, I thought the control flag was the one I described in my response i.e.:
There is a MIL_DELAY control flag at $C7C2 which turns the MIL light off at the start of the MIL Service routine.
In R2967 it's set to $00, in tunes where the EFI MIL lamp is enabled it's set to $FF.
All that needs to be done is convert $C7C2 to the standalone PROM offset and at that address change the code to $FF, isn't it?
In any case, as a RoverGauge power user with a laptop permanently connected what would having a functional MIL lamp achieve?
I think TVR turned the MIL lamp permanently Off at the request of dealers to deter concerned/bemused owners knocking at their doors every 5 minutes.
Just checked R2422 and the MIL control flag is at $C79A, and is set for $00.
There is a MIL_DELAY control flag at $C7C2 which turns the MIL light off at the start of the MIL Service routine.
In R2967 it's set to $00, in tunes where the EFI MIL lamp is enabled it's set to $FF.
All that needs to be done is convert $C7C2 to the standalone PROM offset and at that address change the code to $FF, isn't it?
In any case, as a RoverGauge power user with a laptop permanently connected what would having a functional MIL lamp achieve?
I think TVR turned the MIL lamp permanently Off at the request of dealers to deter concerned/bemused owners knocking at their doors every 5 minutes.
Just checked R2422 and the MIL control flag is at $C79A, and is set for $00.
Edited by davep on Saturday 5th July 15:17
Dave, I think you've got it! Years ago, I decided that byte $C7C2 was used to delay turning off the MIL after engine start. I thought that this was a lamp test and may have been a Federal requirement which accounted for the difference between NAS and TVR. This is why I labeled the build option in the source code as MIL_DELAY.
I just looked at the code again and I think I was wrong about this. Your answer was more to the point. Byte $C7C2 probably is the magic byte Mark is looking for. If this is the case, $00 disables the MIL and $FF enables it. I'll also have to correct my code comments for the next version of source files. This reminds me of how much I still don't understand.
Pretty soon, I'll be able to retire and hand this job off to you!
I just looked at the code again and I think I was wrong about this. Your answer was more to the point. Byte $C7C2 probably is the magic byte Mark is looking for. If this is the case, $00 disables the MIL and $FF enables it. I'll also have to correct my code comments for the next version of source files. This reminds me of how much I still don't understand.
Pretty soon, I'll be able to retire and hand this job off to you!
Mark to enable the MIL lamp try the following:
Open the BIN file with a Hex Editor and go to offset Hex 07C2 or Hex 47C2. Basically the code pattern you're looking for is 64 00 00 64, where the second 00 is the value needed.
For older tune versions (R2422) try Hex 079A.
If the value is 00 change to FF.
Open the BIN file with a Hex Editor and go to offset Hex 07C2 or Hex 47C2. Basically the code pattern you're looking for is 64 00 00 64, where the second 00 is the value needed.
For older tune versions (R2422) try Hex 079A.
If the value is 00 change to FF.
Dan and Colin,
I hope you see my two posts in the Griffith Growl 2014 Rolling Road thread as I've finally put into practise everything you have taught us. My Griff is running much smoother in traffic and cleaner up the top with your extended rpm table. I've also now lowered my rpm limit and improved the RoverGauge speedo.
Although I'm addicted to learning about the internals of the 14CUX at this time of year I'm more addicted to the loud pedal. However, I won't be able to resist the temptation of some RoverGauge & AFR logging so I have more data to play with in the winter. I'm also looking forward to version 3 and testing a Hamlin speed sensor.
You already know how grateful I am.
Mark
I'm very interested to hear how you are getting on with the MIL lamp? I've previously tried turning it on with MIL_DELAY in Dan's version 2 code for R2967 & R3833 without much success. Hopefully see you at the next Berkshire meeting.
Dave
I'm really impressed you are getting your head around the code, I hope one day we can meet up so you can give me a 14CUX programming lesson.
I hope you see my two posts in the Griffith Growl 2014 Rolling Road thread as I've finally put into practise everything you have taught us. My Griff is running much smoother in traffic and cleaner up the top with your extended rpm table. I've also now lowered my rpm limit and improved the RoverGauge speedo.
Although I'm addicted to learning about the internals of the 14CUX at this time of year I'm more addicted to the loud pedal. However, I won't be able to resist the temptation of some RoverGauge & AFR logging so I have more data to play with in the winter. I'm also looking forward to version 3 and testing a Hamlin speed sensor.
You already know how grateful I am.
Mark
I'm very interested to hear how you are getting on with the MIL lamp? I've previously tried turning it on with MIL_DELAY in Dan's version 2 code for R2967 & R3833 without much success. Hopefully see you at the next Berkshire meeting.
Dave
I'm really impressed you are getting your head around the code, I hope one day we can meet up so you can give me a 14CUX programming lesson.
It would be nice to do own own TVR super chip along the following lines:
Use the latest "operation pride" base tune with the better stepper and cold start control.
Enable the MIL lamp.
Raise the idle to 850 RPM (over the Range Rover setting)
Put both Cat and Non cat maps for any given engine size for those running decatted manifolds.
It would be really good to use Dans extended and smoothed RPM banding to take the fueling to 6200 rpm instead of 5400 rpm (or so) but that needs time on the rollers with example engines thats a whole new ball game, so it would just be a case of sticking with the TVR map as is at the moment. Im sure this is all do able. Im a bit tied up at the moment with knocking down my garage and trying to get a new one built before the winter, so stuff like this is on the "to do" list at the moment.
Use the latest "operation pride" base tune with the better stepper and cold start control.
Enable the MIL lamp.
Raise the idle to 850 RPM (over the Range Rover setting)
Put both Cat and Non cat maps for any given engine size for those running decatted manifolds.
It would be really good to use Dans extended and smoothed RPM banding to take the fueling to 6200 rpm instead of 5400 rpm (or so) but that needs time on the rollers with example engines thats a whole new ball game, so it would just be a case of sticking with the TVR map as is at the moment. Im sure this is all do able. Im a bit tied up at the moment with knocking down my garage and trying to get a new one built before the winter, so stuff like this is on the "to do" list at the moment.
Edited by blitzracing on Friday 11th July 13:00
blitzracing said:
It would be nice to do own own TVR super chip along the following lines:
Use the latest "operation pride" base tune with the better stepper and cold start control.
Enable the MIL lamp.
Raise the idle to 850 RPM (over the Range Rover setting)
Put both Cat and Non cat maps for any given engine size for those running decatted manifolds.
It would be really good to use Dans extended and smoothed RPM banding to take the fueling to 6200 rpm instead of 5400 rpm (or so) but that needs time on the rollers with example engines thats a whole new ball game, so it would just be a case of sticking with the TVR map as is at the moment. Im sure this is all do able. Im a bit tied up at the moment with knocking down my garage and trying to get a new one built before the winter, so stuff like this is on the "to do" list at the moment.
Looking at the configure build list in Dan's Version 2 code I think the first two in the list can be done as of now:Use the latest "operation pride" base tune with the better stepper and cold start control.
Enable the MIL lamp.
Raise the idle to 850 RPM (over the Range Rover setting)
Put both Cat and Non cat maps for any given engine size for those running decatted manifolds.
It would be really good to use Dans extended and smoothed RPM banding to take the fueling to 6200 rpm instead of 5400 rpm (or so) but that needs time on the rollers with example engines thats a whole new ball game, so it would just be a case of sticking with the TVR map as is at the moment. Im sure this is all do able. Im a bit tied up at the moment with knocking down my garage and trying to get a new one built before the winter, so stuff like this is on the "to do" list at the moment.
Edited by blitzracing on Friday 11th July 13:00
;----------------------------------------------------------
; These flags control how the code section is built
; This section should not be altered.
;----------------------------------------------------------
BUILD_R3365 = 0
BUILD_R3383 = 1
BUILD_R3652 = 0
BUILD_R3360_AND_LATER = 0
BUILD_TVR_CODE = 0
NEW_STYLE_AC_CODE = 0
NEW_STYLE_FAULT_SCAN = 0
NEW_STYLE_FAULT_DELAY = 0
NEW_STYLE_MIL_CODE = 0
Raising the idle shouldn't be difficult.
Not sure I fully understand the 'Put both Cat and Non-cat maps ... for decatted manifolds' requirement. As you know there are five fuel map areas available for use (already set up for open and/or closed loop) then it's just a question of designating tune resistor values to their specific engine configurations (or use CRASM build control flags as above) and then lots of tweaking in the respective code paths.
Gassing Station | Griffith | Top of Page | What's New | My Stuff