Graphics interface for the 14CUX

[stevesprint]

Remapping the 14CUX

Colin & Dan - I have successfully altered my fuel map & the fuel adjustment factor and blown the changes to a spare EPROM. The engine drives flawlessly and the changed fuel map appears in RoverGauge correctly. BUT as expected, I now have a checksum error that the driver wouldn't even know about. The other fault codes seem to work correctly which I proved by disconnecting some sensors. Therefore the checksum error is NOT the code of death but merely an indication your tune chip has been altered.

Colin, from reading your notes & posts I understand the checksum must always be forced to 0x0001 by adjusting the first value in the PROM. Sadly that means I can't simply use the checksum calculator in my EPROM programmer software. Is their a formula or program to re-calculate the first value in the PROM.

Interestingly I had to change the second copy of map 2 ending at 43D0 and the adjustment factor at 43D1/43D2. I did trying changing the first copy of map 2 ending at 3D0 but the changes where ignored.

My early TVR Precat Griff runs map 2 on Revision 2422 and has always run far too rich across the whole rev range and especially at the top end. I could try turning the CO adjustment on the AFM anti clockwise or use an adjustable fuel pressure regulator but it's much more fun to experiment with the ECU fuel map.

Thank you in anticipation
Steve Sprint

Edited by stevesprint on Monday 26th August 23:21

[cmb]

stevesprint said:

RoverGauge Appreciation and Donation
Colin and Father Dan - I still can't believe how lucky we all are having your full blown real time diagnostic program, it's far more than just a fault code reader and it's free. Please PM me your paypal address so I can send you a small donation. I gave up hope on a PC based diagnostic program 12 years ago thinking the 14CUX only outputs fault codes and there was no real time diagnostics protocol. Now we have your easy to use fully featured graphical diagnostic program with free updates and full technical support provided by yourselves and Mark. For a 22 year old ECU it beggars belief.

Steve,

Thank you for the nice words! The software and documentation that my dad and I have put together is the result of a strong shared enthusiasm for British cars, and for TVR and Land Rover in particular. We started working on it purely out of personal interest, and as such, we can't accept any donations, although I sincerely appreciate the offer.

stevesprint said:

You may already know RoverGauge still doesn't shows the target idle for very early revisions (TVR 1992 - R2422) even though the ECU voltage is displayed correctly. It must be a nightmare writing RoverGauge to work with all the different EPROM revisions.

Yes, I had heard about the target idle problem with early tune revisions. I do have a 2422 image here, so I'll try to find the time to burn a PROM and check it out. I'm trying to build a collection of images so that I can update the software to support as many as possible. As you've guessed, universal compatibility is tricky because data offsets have changed a few times.

At one point I even contacted the owner of an Italian-market 2.0L supercharged V8S in the hope that I could get a copy of that ROM image (which should be pretty interesting), but alas, he had previously sold the car.

One thing to note about tune revision numbers: identical numbers do not guarantee identical images. I have a couple different Griffith 500 images, one from 1994 and one from 1995. The both identify themselves as R2967, but there are differences between them in the fuel maps, idle speed settings, and elsewhere.

stevesprint said:

Also let's not forget to thank Mark for all his free and very prompt technical support, he certainly has a very in-depth understanding of the 14CUX. I must also thank Mark for his very robust and reliable RoverGauge USB cables.

I'd also like to publicly thank Mark for his dedication to this project! RoverGauge would never have been as popular as it is without his hard work.

Cheers,
Colin

[cmb]

stevesprint said:

Remapping the 14CUX

Colin & Dan - I have successfully altered my fuel map & the fuel adjustment factor and blown the changes to a spare EPROM. The engine drives flawlessly and the changed fuel map appears in RoverGauge correctly. BUT as expected, I now have a checksum error that the driver wouldn't even know about. The other fault codes seem to work correctly which I proved by disconnecting some sensors. Therefore the checksum error is NOT the code of death but merely an indication your tune chip has been altered.

Colin, from reading your notes & posts I understand the checksum must always be forced to 0x0001 by adjusting the first value in the PROM. Sadly that means I can't simply use the checksum calculator in my EPROM programmer software. Is their a formula or program to re-calculate the first value in the PROM.

Interestingly I had to change the second copy of map 2 ending at 43D0 and the adjustment factor at 43D1/43D2. I did trying changing the first copy of map 2 ending at 3D0 but the changes where ignored.

My early TVR Precat Griff runs map 2 on Revision 2422 and has always run far too rich across the whole rev range and especially at the top end. I could try turning the CO adjustment on the AFM anti clockwise or use an adjustable fuel pressure regulator but it's much more fun to experiment with the ECU fuel map.

Thank you in anticipation
Steve Sprint

Edited by stevesprint on Monday 26th August 23:21

It's a modulus-based 8-bit checksum. To correct the file so that it has a checksum of 0x01, subtract one less than the current checksum from the first byte:

first_byte = first_byte - (current_checksum - 1)

If the result is negative, then it must of course be expressed as a two's-complement 8-bit value. For example, -47 (decimal) becomes 0xD1.

To determine the current checksum in the first place, I use the utility 'jacksum' (http://www.jonelo.de/java/jacksum/). You'll need to call it with a command line parameter to select the 'sum8' algorithm:

jacksum -a sum8 image.bin

Note: it sounds like you actually have a 32KB image with the code + data duplicated in the upper half. You'll probably want to work with one 16KB half, force the checksum to 0x01, and then re-duplicate it into a 32KB image.

--Colin

Edited by cmb on Tuesday 27th August 00:19

[danbourassa]

That Colin...what a freakin nerd.

Seriously, I would also like to say thanks, stevesprint, for the complement and thanks to Mark. We couldn't ask for a more capable person supporting this effort over there. Colin and I both support the concept of both knowledge and software being free. The interface cable? Well that's another matter.

We were in our element for 14CUX effort but the next one has me worried. A low pressure, constant flow, all mechanical system that reportedly even gives the experts a hard time.

[stevesprint]

Colin - SUCCESS !!!

I’ve finally changed my fuel map and fuel adjustment factor plus successfully cleared the checksum error; I never thought I would be able to change the fuelling myself. My friends will be queuing up for me to remap their cars.

I fully understand and respect you not accepting donations and I know exactly what your father means you both were in your element, sounds like myself with my TVR mods. If I can be of help in anyway please do hesitate to ask, I would welcome the opportunity to return the favour. Do you have a list of PROM revision numbers you have developed RoverGauge with so I can check if I have any you don’t have? Please don’t bust a gut on my account to resolve the target idle with my revision 2422 but I guess it would be good to resolve it one day for completeness.

It would be good one day to know my idle offset on the PROM in case I decide to change my idle to suit a different cam. I guess I can now copy my fuel map and adjustment factor to a later revision that you know the idle offset in the PROM. Do you have a favourite PROM revision that you can publish the popular offsets?

Thanks again for all your help and for jacksum, plus explaining how to set the checksum. Good luck with your next project, what is that engine from?

Cheers
Steve Sprint

[cmb]

stevesprint said:

Colin - SUCCESS !!!

I’ve finally changed my fuel map and fuel adjustment factor plus successfully cleared the checksum error; I never thought I would be able to change the fuelling myself. My friends will be queuing up for me to remap their cars.

I fully understand and respect you not accepting donations and I know exactly what your father means you both were in your element, sounds like myself with my TVR mods. If I can be of help in anyway please do hesitate to ask, I would welcome the opportunity to return the favour. Do you have a list of PROM revision numbers you have developed RoverGauge with so I can check if I have any you don’t have? Please don’t bust a gut on my account to resolve the target idle with my revision 2422 but I guess it would be good to resolve it one day for completeness.

It would be good one day to know my idle offset on the PROM in case I decide to change my idle to suit a different cam. I guess I can now copy my fuel map and adjustment factor to a later revision that you know the idle offset in the PROM. Do you have a favourite PROM revision that you can publish the popular offsets?

Thanks again for all your help and for jacksum, plus explaining how to set the checksum. Good luck with your next project, what is that engine from?

Cheers
Steve Sprint

Glad to hear that you got it working!

I don't yet have a single comprehensive list of data-segment offsets (and many of them are still a mystery to us), but I can quote from an email that I sent recently that might help:

cmb said:

There are actually a couple different locations at which the fuel maps are stored in the ROM, depending on the revision of the code. The offsets of the five maps for the older revision are:

Map 1: $023F, Map 2: $0351, Map 3: $0463, Map 4: $0575, Map 5: $0687

And for the newer revision:

Map 1: $0267, Map 2: $0379, Map 3: $048B, Map 4: $059D, Map 5: $06AF

A fuel map is selected by the value of the tune resistor input (with the exception of NAS vehicles, where it is locked to Map 5.)

Each map consists of a 16x8 matrix of values. To determine whether you have the 'old' versus 'new' revision of code, you can just look at one of the locations listed above in your ROM image. Fuel map data is pretty obvious because it consists of long runs of similar numbers (typically starting around $1F to $23 in the first row of a map.)

Also note that there is a 16-bit multiplier value immediately following each of the maps. This value is usually around $5400 to $5D00 for 3.9L engines and seems to change significantly for engines of different displacements. We haven't done any experimentation with it, so I can't say whether you would see any benefit by changing it.

As far as idle speed is concerned, you're probably just interested in changing the base value, which is at offset $0176. (This offset seems to be the same between the old and new code revisions.) It's set at 600 RPM for Land Rovers, but usually a little higher for TVR (770 or 800 RPM.)

When reviewing assembly code, we work with R3652, which is a very late Land Rover revision (~1995) that features a series of fixes performed by LR under a campaign they called "Operation Pride". This is referenced in a document (available here) that lists a number of other tunes in a table on the last two pages. I think that many (most?) of them are NAS-specific. I only have ROM images for a few of those listed, plus a couple from TVRs. At some point, I could post a list of what I have in the hope that we could nail down any remaining RoverGauge compatibility issues. It would definitely be nice to save images from some of the more rare and obscure tunes before they're lost forever.

The photo that my dad posted is the Rochester injection system on his 1957 Corvette. As it represents the early days of fuel injection on cars, it has quite a few quirks. Currently has a bad flat spot just off idle when cold... but a beautiful car!

[Ribol]

to all concerned ........

As it sounds like the brainy people are reaching the point where the 14CUX can finally be remapped by non Lucas humans will there ever be any way of "normal folk" being able to do it themselves through the excellent Rovergauge software?

[danbourassa]

Ribol,

Some time ago, I gave this a lot of thought and the answer is probably NO.

With the existing ECU and PROM firmware, the answer is a definite NO. The PROM type in every ECU I have opened (maybe 10 or so, all NAS) has been the OTP type (One Time Programmable). This type can be identified by a lack of round clear window on the top of the chip. This type cannot be re-written or even erased (so calling it an EPROM is technically incorrect).

Steve probably changed his PROM for a more common UV eraseable EPROM (with the window). But even then, it needs to be removed from the ECU, erased under UV light, reprogrammed and re-installed.

For programming in place, three things need to be done.

1) An Electrically Erasable PROM (EEPROM) would need to be installed. Maybe a 28C256.

2) Some cuts & jumpers would need to be done to the board. For example, the microprocessor's write signal would have to be routed to the EEPROM location. Currently, it doesn't go there since there is no need for it.

3) The EEPROM firmware would have to have a non-trivial patch. Not only would an erase/write routine have to be added but a small delay loop of code would have to be added to the RAM since code execution from the PROM is not possible while it's being altered. This means relocation of a number of values in RAM to free up a contiguous area plus a patch to download code to this space on start up.

The approach Steve took is much more practical. If you use an EEPROM instead of a UV EPROM, it's much quicker and you don't have to buy a UV light. Also Colin and I bought very nice German Batronix chip programmers that weren't much more expensive than the Made in China programmers. Of course, all this hinges on having your PROM in a socket in the ECU. If there is interest, maybe one of us can post step by step instructions.

[Ribol]

danbourassa said:

If there is interest, maybe one of us can post step by step instructions.

Thanks for the explanation

I am sure there would be plenty of interest in this from fellow 14CUX owners.

(Speaking for myself only) some of us simply don't have your kind of knowledge of this subject but would however still like to understand how it works a little better

[danbourassa]

danbourassa said:

Some time ago, I gave this a lot of thought and the answer is probably NO.

I don't know who this imposter is, but he's very negative. The real answer may be YES (It's amazing what a good night's sleep can do.)

Cuts & jumpers are really the deal killer. The goal is to just plug in something in place of the PROM (of course, you still need the PROM on a socket) and have an on-the-fly writable fuel map. Support could be added to RoverGauge as Ribol suggested or a new utility program could be developed. I'm trying not to get too excited yet since there may be a fatal flaw in my thinking. Colin may be coming over to my place this weekend, so we need to pour a few beers over this one. Right now I need to read up on the new non-volatile FPGAs (that's a hint).

-Dan

[spitfire4v8]

Dan .. have you ever thought of writing anything for the moates ostrich? being able to real time map from an emulator plugged into the prom socket whilst watching the real time lambda trimming off rovergauge is the way I'd want to be mapping the part throttle. It seems we're close to getting something up and working for live mapping but not quite got that last hurdle jumped

[danbourassa]

spitfire4v8 said:

Dan .. have you ever thought of writing anything for the moates ostrich? being able to real time map from an emulator plugged into the prom socket whilst watching the real time lambda trimming off rovergauge is the way I'd want to be mapping the part throttle. It seems we're close to getting something up and working for live mapping but not quite got that last hurdle jumped

I'm not too familiar with the Ostrich. If I'm not mistaken, it's a ROM emulator like my Romulator. I've used the Romulator on the bench for code changes but I don't think I would use it on the road. I never got the feeling that it was robust (partly because there are many more connections involved) and could be unsafe on the road. Anyway, a ROM emulator is not the right solution for everyone, although it is one way to solve the problem.

[Ribol]

danbourassa said:

I'm trying not to get too excited yet since there may be a fatal flaw in my thinking. Colin may be coming over to my place this weekend, so we need to pour a few beers over this one.

Are you saying the future of 14CUX mapping as we know it is entirely dependant on how much beer you two drink in a weekend

[danbourassa]

Ribol said:

Are you saying the future of 14CUX mapping as we know it is entirely dependant on how much beer you two drink in a weekend

I don't know if the beer helps or hurts the creative process, but lets not investigate that too closely and just assume it helps.

[Ribol]

danbourassa said:

I don't know if the beer helps or hurts the creative process, but lets not investigate that too closely and just assume it helps.

Just remember we're all counting on you ............ so no pressure

[spitfire4v8]

Thanks Dan .. yep the Ostrich is like your Romulator. I'd still like to try and go down this route for myself .. does anyone else on the thread have any knowledge in this area of writing something to get the Ostrich talking to the lucas ecu? If anyone can help or knows anyone who can please PM me , cheers.

[stevesprint]

I’ve created a new thread on the Griffith forums, see the link below, with an overview of my instructions to change the fuel map and a list of hardware required. I’m sure Colin won’t mind me reposting the fuel map offsets from his email.

http://www.pistonheads.com/gassing/topic.asp?h=0&a...

Colin - Thanks for posting your useful email outlining the offsets for the older and newer revisions and the idle speed offset, guess what I’ll be experimenting with over the weekend. Also thanks for the link to the ‘operation pride’ document, it’s interesting to see Land Rovers full list of revisions. I should have guessed the list wouldn’t include TVR’s Revisions e.g. R2422 for 1992 Precat Griffiths 4 & 4.3 & 4.3BV and R2967 - TVR Chimaera 450 & Griffith 500

Dan - Good luck with the new non-volatile FPGAs, I love your enthusiasm and tenacity, either way I’m very grateful I can now change my own fuel map. You may be interested to know all TVR EPROM’s I’ve seen have the ultraviolet quartz window and socket on the circuit board. I would always keep the original chip in a safe place as a backup and experiment with spare chips. My son and I have always loved the curves and white sides of the 1957 Corvette, what a cool car, best wishes.

Cheers, the beer certainly helps me except while driving.
Steve Sprint

[MuffDaddy]

I've said this once, and i'll say it again. Anyone fancy porting this code to work on a phone? The native code is QT based and the USB port can be in host mode. I can supply a test device.

Imagine Rover Guage, satnav and music all available on one device.

[robertf03]

spitfire4v8 said:

Thanks Dan .. yep the Ostrich is like your Romulator. I'd still like to try and go down this route for myself .. does anyone else on the thread have any knowledge in this area of writing something to get the Ostrich talking to the lucas ecu? If anyone can help or knows anyone who can please PM me , cheers.

Yes, you can read about my ostrich experience here http://www.pistonheads.com/gassing/topic.asp?h=0&a...

basically back then there was NO public data available for this vehicle and I got as far as discovering the fuel tables but could not find a checksum. All I could do with the ostrich was set the PROM ERROR code.

I saw this thread last night and now that there is an active interest in live tuning these things I'm back on this project. Even found my notebook from 6 years ago!

For live tuning, you must have a program that simultaneously updates the checksum while sending the updated bytes to the emulator. One could be written fairly easily, MOATES does publish his specs. An easier approach (the one I'll be taking this time) is to use TunerPro RT and create a custom XDF. The XDF stores the definition of the chip and the parameters of the checksum.

I'm still a little fuzzy on the checksum location for the 14cux. I do not believe it is the first byte of the ROM image as that is the first entry in fuel table 0. Changing it will work, but that is a kludge. IMO, the next step is find the true checksum byte location.

[danbourassa]

robertf03 said:

I'm still a little fuzzy on the checksum location for the 14cux. I do not believe it is the first byte of the ROM image as that is the first entry in fuel table 0. Changing it will work, but that is a kludge. IMO, the next step is find the true checksum byte location.

Although it's true that it could (and probably should) have been placed in the unused area of the PROM. Lucas did, in fact, use that location for the checksum. It's the limp home map location for 200 RPM and probably less load than the internal engine friction provides. If it ever comes into play, the checksum could actually help you get home.