Instructions to change fuel maps on 14CUX Griffith, Chimaera

[davep]

Dan, not that it matters but could it be that the MPU mode is set by programming portdata2 with $02 on the rising edge of RESET. It's too much of a coincidence that the Mode 2 selection code on P22, P21 and P20 is L H L ($02), and this is what is loaded at the very start of initialisation.

Also the port2ddr register is loaded very near the end of initialisation and I can find only one instance of this:

;----------------------------
; Init some hardware regs
;----------------------------
                ldd         #$050A
                std         sciModeControl          ; init SCI for 7812 baud (1 MHz/128)
                ldaa        #$FE
                staa        port2ddr                ; set port 2 data dir (again)
                ldaa        timerStsReg             ;
                ldd         icrHigh                 ; clears something?

[danbourassa]

Dave, I believe this IS just a coincidence. Look at Figure 16 (Typical Mode Programming Circuit) in the MC6803U4 data sheet. This shows the mode selection using 10K resistors. This example is probably for a development board since it has select switches, but I'm sure the 14CUX board has a version of this that is fixed to Mode 2.

[Chuffmeister]

Gguys, will the Checksum error facility on the new version of Rovergauge actually reset the checksum or does it need to be written by a different device?

[cmb]

Chuffmeister said:

Gguys, will the Checksum error facility on the new version of Rovergauge actually reset the checksum or does it need to be written by a different device?

If you're referring to the "checksum fixer" display, then this only shows the value of the byte in the ROM that is adjusted to force the expected checksum of 0x01. I added this because there are some different ROMs that do not differ in either the 'tune' or 'ident' fields, but they do have a different checksum fixer byte.

The ECU cannot write any new data to the PROM, and therefore RoverGauge cannot change the PROM contents either.

[stevesprint]

Dave
Unfortunately the MIL code mod didn't work and I've now decided it's time to start running and working on the correct revision for Dan's next release. You never know the MIL lamp may actually work correctly in the later code. It's been very useful as I've learnt an awful lot about the code and we could still try and fix it.

I've rebuild my Griff Growl rolling road (2967) revision that contains the extended fuel table to 6200 but with the standard road speed comparitor so anyone with a Griffith 430 can use it. It can be download from
www.stevesprint.com/remap-14cux/bins/R2967_430-620...



Dan
What revision is your version 3 going to be based on. Basically I want to start running the correct revision in preparation for your next release, I don't want to be left behind. I will obviously apply and test everything we've learnt so far on the revision you suggest. I’m a little hesitant to use the final Operation Pride Revision R3562 as it’s the special NAS Cold weather upgrade. Please can you advise.

[FlipFlopGriff]

Steve,
No idea what its all about but I see the benefit.
Thanks to all you geeks (no offence) for all the hard work.
FFG

[stevesprint]

FlipFlopGriff said:

Steve,
No idea what its all about but I see the benefit.
Thanks to all you geeks (no offence) for all the hard work.
FFG

Paul,
Don’t thank me thank our America friends. As a result of their hard work Jools (spitfire4v8) can now remap the 14cux plus my Griff now runs much smooth at slow speed and I’ve sorted my fuelling at high RPM’s.

Thanks for organising another successful Growl and best wishes for the next one.
It was good to see you at Silverstone Classic.
Cheers Steve

[davep]

stevesprint said:

Dave
Unfortunately the MIL code mod didn't work and I've now decided it's time to start running and working on the correct revision for Dan's next release. You never know the MIL lamp may actually work correctly in the later code. It's been very useful as I've learnt an awful lot about the code and we could still try and fix it.

I've rebuild my Griff Growl rolling road (2967) revision that contains the extended fuel table to 6200 but with the standard road speed comparitor so anyone with a Griffith 430 can use it. It can be download from
www.stevesprint.com/remap-14cux/bins/R2967_430-620...

Steve I've checked the revision above and you've set the MIL lamp function as disabled:

The instruction ldaa XC7C2 loads the contents of memory address $C7C2, which is set with a value of $00 or $FF (the value of the MIL control flag discussed above), into Accumulator A.

Was this intentional? MIL lamp will not work if set for $00.

[stevesprint]

davep said:

Steve I've checked the revision above and you've set the MIL lamp function as disabled:
Was this intentional? MIL lamp will not work if set for $00.

Yes,
I’ve been asked offline for various proms and therefore I’ve posted my tried and tested 430 prom with the extended rpm fuel table that I used at the Growl and ever since. As you know it uses TVR's later code that has the better idle control plus the target idle is displayed in RoverGauge. I deliberately rebuilt it for a standard 430 with a standard road speed sensor.

I’ve emailed you my current version on test with the MIL lamp enabled (R2967_430-MIL-ON.bin and my original Growl version for you to compare. Don’t run these emailed proms as they are for my non standard road speed sensor, if you want to try my version then pleased see the link above.


Dan.
Is their any chance you can add the road speed comparitor to data.asm.
Thank you in anticipation

[danbourassa]

stevesprint said:

Dan
What revision is your version 3 going to be based on. Basically I want to start running the correct revision in preparation for your next release, I don't want to be left behind. I will obviously apply and test everything we've learnt so far on the revision you suggest. I’m a little hesitant to use the final Operation Pride Revision R3562 as it’s the special NAS Cold weather upgrade. Please can you advise.

I haven't done much on version 3 for awhile. The plan is to have the same basic format as before with 10 or so tune choices. Since you figured out the overrun, the version after that will probably start to drop some of the older tunes to simplify things a bit.

There are actually a number of Operation Pride tunes. R3652 and R3653 differ only in the data (3.9 vs. 4.2), however, R3654, which is for the Defender, also has an optimized approach for measuring the road speed sensor. I would have to consider R3654 the last and best of the Land Rover tunes. There should be no problem using an Op-Pride tune. All they did was lower the RPM threshold for the running state from 505 to 375 RPM. There are two cranking fuel algorithms in the code. One for below 0 Fahrenheit and one for above 0 F. This code calculates the fuel until RPM reaches the threshold and then the normal fuel mapping takes over. I'm not sure but this may have been a way to reduce the fuel sooner to minimize flooding.

By the way, there is a flowchart on the Google drive (14CUX_Cold_Start_Fueling) that shows what happens when you crank a
14CUX Rover V8 when the temperature is below zero F. On the last page, the picture shows the normal injector pulse being broken up into 11 small pulses. This seems to be an attempt to better break up or atomize the fuel under extreme cold. This is not new for Op-Pride. TVR has this as well.

[stevesprint]

danbourassa said:

I haven't done much on version 3 for awhile.

Quite right too, at this precious time of year I hope you’ve outside playing with your big toys.

danbourassa said:

Since you figured out the overrun, the version after that will probably start to drop some of the older tunes to simplify things a bit.

After an initial quick spin of R3526 with the TVR overrun I’m finally starting to feel more confident to move forward from the TVR code. I’ll next put R3652 into daily use and let you know how it goes.

danbourassa said:

There are actually a number of Operation Pride tunes. R3652 and R3653 differ only in the data (3.9 vs. 4.2), however, R3654, which is for the Defender, also has an optimized approach for measuring the road speed sensor. I would have to consider R3654 the last and best of the Land Rover tunes. There should be no problem using an Op-Pride tune.

Do you have a copy of R3653 and R3654 you can upload to your google drive. Having a Griff 4,280cc I’m interested to see the 4,275cc data in R3653, I'm interested in more than just map2 and 5 data.

danbourassa said:

All they did was lower the RPM threshold for the running state from 505 to 375 RPM. There are two cranking fuel algorithms in the code. One for below 0 Fahrenheit and one for above 0 F.

Thanks for the explanation; it puts my mind at rest with operation pride. It’s interesting about lowering the running RPM threshold when you consider the main fuel table starts at 200rpm. I don't plan to exercise the below zero F code as I try to avoid using my Griff below 0 celsius. It makes sense to run R3654 for the optimised road speed sensor code, I’m interested to see if it reduces the strobing effect my configuration suffers from.

danbourassa said:

By the way, there is a flowchart on the Google drive (14CUX_Cold_Start_Fueling) that shows what happens when you crank a 14CUX Rover V8 when the temperature is below zero F. On the last page, the picture shows the normal injector pulse being broken up into 11 small pulses. This seems to be an attempt to better break up or atomize the fuel under extreme cold. This is not new for Op-Pride. TVR has this as well.

Thanks they are great, the more I study your flow diagrams the more sense I make of them.

Edited by stevesprint on Monday 4th August 23:06

[stevesprint]

davep said:

stevesprint said:

;---------------------------------------------------------------------------
; 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

I'd just comment out the beq line to test the lamp.

Dan, I'm having a few problems getting the 'logic' to work on the setup and initialisation of portdata1 and portdata2....

Dave,
You’ll be pleased to hear the MIL test code above does work and I now have a prom that permanently activates the MIL lamp in RoverGauge even after an ECU reset. BUUUUT !!!!! Not in the latest RG version 7, it works in RoverGauge 6 but not in 7. It didn’t help that my dash MIL lamp doesn’t work which will be a nice little project for the winter as I’m not going to pull my dash out at this time of year.

You can see the MIL lamp is on while there is no fault codes,




Colin
When you are next working on RoverGauge please can you check the MIL warning indicator as I’m sure it doesn’t work in the latest version, it’s not urgent as it works in the previous versions, Thanks.

[davep]

That explains why the MIL function worked in my screenshots on page 17, re our conversation last night, I used an earlier version of RG.

Perhaps it has been a test to see if we really are paying attention!

[cmb]

Well, that was embarrassing. Yes, there was indeed a bug in versions 0.7.0 and 0.7.1 that prevented the MIL display from updating. I've just fixed it, built version 0.7.2, and uploaded that.

https://drive.google.com/folderview?id=0B83FOZ5t1n...

Apologies -- I hope you all weren't led too far astray by bad data!

[davep]

Colin, that's good news. We can now bring the 'MIL Lamp not working in some TVRs' issue to a conclusion, as follows:

said:

Steve has reported that when he changed the MIL_CONTROL flag from $00 to $FF in a TVR revision of the code there was still no MIL EFI lamp On when a fault was induced. Looking at the logic above the possible causes for this may be:

-port1data’s value of $03 has not been re-initialised or cleared to $02,
-the result of the fault scan codes procedure is always zero for some reason,
-the fault fell outside of the fault scan range, the scan is a bit flakey.

So more analysis is needed.

Also verify that:

-the MIL lamp in the dash is correctly wired in,
-for MIL lamp test or diagnostic purposes RoverGauge version 0.7.2 is run.

[davep]

On to the next action point on the list, sustained high rev's and over-fuelling at start-up; Steve I think Dan's given us a good lead in here:

danbourassa said:

There is never "simultaneous operation" although there IS a short period of double rate injector pulsing. During this time, there is no non-fuel interrupt, so each bank is fired every 2 sparks instead of every 4 sparks. This period of time can easily be changed. The 16-bit variable at $009D/9E is initialized to 192 decimal at power on. The 14CUX software double injects for this many sparks after start-up. This is equivalent to 48 engine revolutions and lasts about 3 seconds. If you want to reduce fuel a little quicker at start-up, you might want to try reducing this number. It is not in the data section but can be found under reInitVars in file reset.asm.

[stevesprint]

cmb said:

Apologies -- I hope you all weren't led too far astray by bad data!

Colin,
I'm very grateful and impressed you fixed it so fast, thanks. I won’t be demanding my money back, lol. I bet you were just trying to get me back for leading your father astray when I copied a map2 adcmux table into map5. Seriously, I don't mind being led astray as I learnt a lot from Dave on the way.

danbourassa said:

There are actually a number of Operation Pride tunes. R3652 and R3653 differ only in the data (3.9 vs. 4.2), however, R3654, which is for the Defender, also has an optimized approach for measuring the road speed sensor. I would have to consider R3654 the last and best of the Land Rover tunes. There should be no problem using an Op-Pride tune.

Dan & Mark
I'm pleased to report my first impression of R3652 with the TVR data is excellent like R2967 plus I've noticed the MIL gives a reassuring flash each time the ignition is turned on.

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.

Mark,
We’re ready when you are ready; I hope the garage is going according to plan.


Mark or anyone
Does anyone know the ECU output voltage on pin 10 for the MIL and please don't say test it as I have and I don't like what I'm seeing.

davep said:

On to the next action point on the list, sustained high rev's and over-fuelling at start-up; Steve I think Dan's given us a good lead in here:

Dave
Sir! Yes! Sir! I'll test it straight away, plus it will be interesting to monitor the stepper motor at the same time to see if it also reduces the stepper motor extra air quicker. I would of thought the main issue is the stepper motor is wound back during shut down and some how we need to close it quicker once the engine is running. I'll have a look at idleControl.asm and steperMtr2.asm or it could be one of those mystery down counters.
P.S. You know I always wanted to be chief tester.

Edited by stevesprint on Friday 8th August 23:40

[davep]

stevesprint said:

Mark or anyone
Does anyone know the ECU output voltage on pin 10 for the MIL and please don't say test it as I have and I don't like what I'm seeing.

Steve, I've checked for voltage levels on pin 10 (Black/Yellow btw) and all I see is a low residual of 20mV with MIL lamp On in RoverGauge (but no dash MIL lamp On), not what I'd expect really.

Also, to induce a fault I pulled the Tune Resistor with just ignition On and the MIL lamp in RG came On, plus the fuel map changed immediately from map 2 to map 0, which was the map used when cranking the engine. Lots of over-fuelling smells as expected, I reconnected the Tune Resistor and map 2 was immediately displayed and normal fuelling resumed. The MIL lamp in RG stayed On even when I cleared fault codes and was only reset after several ignition off/on sequences.

Now here's what is really doing my head in: I dumped out the PROM contents and thought I'd back check with a previous BIN file of the same PROM, I've made no changes to this PROM as it's used as my fallback reference, for some reason in today's dump version a line of code is missing (D2B0 58 aslb).

stevethetester said:

Sir! Yes! Sir! I'll test it straight away, plus it will be interesting to monitor the stepper motor at the same time to see if it also reduces the stepper motor extra air quicker. I would of thought the main issue is the stepper motor is wound back during shut down and some how we need to close it quicker once the engine is running. I'll have a look at idleControl.asm and steperMtr2.asm or it could be one of those mystery down counters.
P.S. You know I always wanted to be chief tester.

Very good chief, carry on, no slacking now.

[blitzracing]

The MIL lamp is switched to ground by the ECU- so you need 12 volts on one side of the warning lamp, and the MIL connection to the ECU on the other. Im happy to test out a .bin for you if you want to mail it to me, but it may not be for a week or so.

[stevesprint]

davep said:

Steve, I've checked for voltage levels on pin 10 (Black/Yellow btw) and all I see is a low residual of 20mV with MIL lamp On in RoverGauge (but no dash MIL lamp On), not what I'd expect really.

Dave,
Thanks you’re a star, your results sounds familiar to mine. It's confusing and worrying because when I disconnect the ECU and apply +12 Volts to pin 10 the dash MIL illuminates.

blitzracing said:

The MIL lamp is switched to ground by the ECU- so you need 12 volts on one side of the warning lamp, and the MIL connection to the ECU on the other. I’m happy to test out a .bin for you if you want to mail it to me, but it may not be for a week or so.

Mark, Thanks for clearing up the MIL wiring mystery; I wonder if all Precat’s have the MIL lamp's polarity reversed behind the dash like mine. Luckily I wouldn’t of thought having negative on both sides of the MIL lamp would of damaged the ECU.
Mark, if you email me your prom I’ll happily copy your fuel data into the R3652 and change the rpm limiter, idle speed etc. Ahhh I’ve haven’t yet removed the road speed limiter from R3652, we’ll need Lez to test the road speed limiter.

davep said:

Also, to induce a fault I pulled the Tune Resistor with just ignition On and the MIL lamp in RG came On, plus the fuel map changed immediately from map 2 to map 0, which was the map used when cranking the engine. Lots of over-fuelling smells as expected, I reconnected the Tune Resistor and map 2 was immediately displayed and normal fuelling resumed. The MIL lamp in RG stayed on even when I cleared fault codes and was only reset after several ignition off/on sequences.

Well done, at least we now know how to quickly and easily activate the MIL lamp.

davep said:

Now here's what is really doing my head in: I dumped out the PROM contents and thought I'd back check with a previous BIN file of the same PROM, I've made no changes to this PROM as it's used as my fallback reference, for some reason in today's dump version a line of code is missing (D2B0 58 aslb).

Strange, was all the code after the missing command shifted or was the command just blanked, if it was a data corruption I’m sure you would have had bigger problems.

Edited by stevesprint on Saturday 9th August 08:41