14cux misadventure
Discussion
I'll admit I'm way behind the many people who've tinkered with the fuel maps on the 14cux used in EFi Rover V8's but here's my tale of woe.
I had a good spare 1995 ECU which two years ago a skilled colleague modified to fit the PROM in a socket. Recently I had the opportunity to program a new PROM so I did this and plugged the ECU in to run the engine. Nothing happened. It runs with the original standard ECU. I checked the new chip and found that somehow I'd filled it with FFs. With the standard PROM still nothing happens, the EFi relay energises but no pulse of the fuel pump relay.
I'm confident it was OK so how did I manage to kill the PCB with all FFs in the PROM?
Presume I'm better off buying a replacement to tinker with rather than getting this repaired (cost/benefit)?
I had a good spare 1995 ECU which two years ago a skilled colleague modified to fit the PROM in a socket. Recently I had the opportunity to program a new PROM so I did this and plugged the ECU in to run the engine. Nothing happened. It runs with the original standard ECU. I checked the new chip and found that somehow I'd filled it with FFs. With the standard PROM still nothing happens, the EFi relay energises but no pulse of the fuel pump relay.
I'm confident it was OK so how did I manage to kill the PCB with all FFs in the PROM?
Presume I'm better off buying a replacement to tinker with rather than getting this repaired (cost/benefit)?
100SRV said:
I checked the new chip and found that somehow I'd filled it with FFs.
Assuming you are using a 32KB Prom, have you taken into account the Prom offsets with regard to program and data mapping. See SteveSprint's explanation here: http://www.remap-14cux.uk/addresses.htmlIt could be you flashed the program and data to $0000 - $3FFF and $4000 - $7FFF is packed with $FFs, I think RoverGauge does this when it dumps a Save Prom Image.
As for the ECU not working when you put the original Prom back in, I'd look for the obvious (bent chip pins, etc). These ECUs are pretty robust, putting a Prom in with $FFs in the address range shouldn't cause it to go US.
When I was changing fuel maps and other parameters onto a fresh IC, I once didn't fully engage and lock in the EEPROM into the writer and so corrupted my IC. I didn't realise this and when I tried the 14CUX in the car nothing happened. Going back to a previous chip and everything worked OK. I think the 14CUX is quite robust in this manner. I used AT28C256-15PU (RS part 127-6570) that are re-writeable and they have been great.
I ended up making a hybrid bin file from my original rolling road map and the latest firmware from Steve Sprint's site (R3652). I found that worked really well and didn't hold the revs as much when you came up to a junction. My car was a 1995 Chimaera 4L with cats.
I ended up making a hybrid bin file from my original rolling road map and the latest firmware from Steve Sprint's site (R3652). I found that worked really well and didn't hold the revs as much when you came up to a junction. My car was a 1995 Chimaera 4L with cats.
Hello, thank you for the replies!
That's exactly what I've done; I didn't offset the new map so have an EPROM with no "BIOS". That's fairly easily rectified.
Brilliant!
EXCEPT:
I refitted the ORIGINAL unmodified PROM into the ECU and the fuel pump relay isn't cycled at key on. Checking the PCB from the two pins serving this relay's coil there are no obvious component failures.
Any ideas what's gone wrong here?
That's exactly what I've done; I didn't offset the new map so have an EPROM with no "BIOS". That's fairly easily rectified.
Brilliant!
EXCEPT:
I refitted the ORIGINAL unmodified PROM into the ECU and the fuel pump relay isn't cycled at key on. Checking the PCB from the two pins serving this relay's coil there are no obvious component failures.
Any ideas what's gone wrong here?
Edited by 100SRV on Saturday 22 February 09:42
SUCCESS!
I wanted first to understand why the ECU didn't appear to work so I took the original PROM, put it in the programmer to read the data and it failed. The software identified a "pin failure" which happened to be where the solder had dulled. A quick rub with an eraser and I could read the data.
I then got the EPROM I had flashed a little while ago, read the data off it to check it was the "LR_R3652_3.9_HighCR_OpPride" - yes it was!
I put this into the modified ECU, connected to the engine and...
Key on - MIL illuminated, EFi ignition relay on but no fuel pump relay
Key off.
Key on - MIL illuminated, EFi ignition relay on, fuel pump relay pulses
Crank
Engine runs and quickly settles to idle
Eager to give it a road test now.
Am I correct in thinking main changes in the "Pride" coding are:
I wanted first to understand why the ECU didn't appear to work so I took the original PROM, put it in the programmer to read the data and it failed. The software identified a "pin failure" which happened to be where the solder had dulled. A quick rub with an eraser and I could read the data.
I then got the EPROM I had flashed a little while ago, read the data off it to check it was the "LR_R3652_3.9_HighCR_OpPride" - yes it was!
I put this into the modified ECU, connected to the engine and...
Key on - MIL illuminated, EFi ignition relay on but no fuel pump relay
Key off.
Key on - MIL illuminated, EFi ignition relay on, fuel pump relay pulses
Crank
Engine runs and quickly settles to idle
Eager to give it a road test now.
Am I correct in thinking main changes in the "Pride" coding are:
- MIL works
- Idle control improvement (what has changed?)
- Leaner cold start and idle
The MIL is lit and having found my Rovergauge the fault code is 45 which is (I think) O/S Lambda out of range.
I was running a non-lambda map on my older ECU without problems, no lambda sensors.
Is the Pride dataset for closed-loop systems only?
Might need to do some tinkering with the settings on the new EPROM.
I was running a non-lambda map on my older ECU without problems, no lambda sensors.
Is the Pride dataset for closed-loop systems only?
Might need to do some tinkering with the settings on the new EPROM.
The tune resistor will dictate what map/tune you will be running, for OPEN loop this will be #2 or 3 (with 0, 4 & 5 being closed loop)
What map number does RG indicate you are using?
If I've read the code correctly the lambda input is read even when an open loop map is used, the result just doesn't go anywhere but the value may get tested for viability. On my system there isn't even any wires connected to the Lambda sensor pins so obviously no voltage going in.
I wonder if you're are somehow feeding a voltage which is not viable, may be worth checking them out.
What map number does RG indicate you are using?
If I've read the code correctly the lambda input is read even when an open loop map is used, the result just doesn't go anywhere but the value may get tested for viability. On my system there isn't even any wires connected to the Lambda sensor pins so obviously no voltage going in.
I wonder if you're are somehow feeding a voltage which is not viable, may be worth checking them out.
CGCobra said:
The tune resistor will dictate what map/tune you will be running, for OPEN loop this will be #2 or 3 (with 0, 4 & 5 being closed loop)
What map number does RG indicate you are using?
If I've read the code correctly the lambda input is read even when an open loop map is used, the result just doesn't go anywhere but the value may get tested for viability. On my system there isn't even any wires connected to the Lambda sensor pins so obviously no voltage going in.
I wonder if you're are somehow feeding a voltage which is not viable, may be worth checking them out.
The older ECU with the R3383 tune Rovergauge says it's on Map 2 - 470 ohm UK non-CATWhat map number does RG indicate you are using?
If I've read the code correctly the lambda input is read even when an open loop map is used, the result just doesn't go anywhere but the value may get tested for viability. On my system there isn't even any wires connected to the Lambda sensor pins so obviously no voltage going in.
I wonder if you're are somehow feeding a voltage which is not viable, may be worth checking them out.
The ECU with the R3652 PRIDE tune Rovergauge says it's on Map 5.
I haven't changed the "tune" resistor so what have I missed?
100SRV said:
The older ECU with the R3383 tune Rovergauge says it's on Map 2 - 470 ohm UK non-CAT
The ECU with the R3652 PRIDE tune Rovergauge says it's on Map 5.
I haven't changed the "tune" resistor so what have I missed?
The later 14CUX tunes (destined for markets requiring stringent emissions controls) were programmed to use Map 5 (closed loop) only, disregarding the tune resistor value.The ECU with the R3652 PRIDE tune Rovergauge says it's on Map 5.
I haven't changed the "tune" resistor so what have I missed?
So it could be your 'older' ECU is coded to allow map selection via the tune resistor, and the PRIDE ECU is as above.
davep said:
The later 14CUX tunes (destined for markets requiring stringent emissions controls) were programmed to use Map 5 (closed loop) only, disregarding the tune resistor value.
So it could be your 'older' ECU is coded to allow map selection via the tune resistor, and the PRIDE ECU is as above.
Are you thinking that I have bought an NAS ECU here in the UK?So it could be your 'older' ECU is coded to allow map selection via the tune resistor, and the PRIDE ECU is as above.
Interesting idea, here's some evidence to help solve this:
LH ECU (XT) has the PRIDE map in a socketed EPROM, date code Sept '94
RH ECU is the standard one which uses map 2, has a later build date of July '95
No idea why it's an inverted photo, sorry.
Edited by 100SRV on Tuesday 4th March 19:03
Take a look at SteveSprint's firmware settings table and check the Tune Lock status for the two tunes you are using.
http://www.remap-14cux.uk/LR-TVR-settings.html
R3652 is a NAS tune only (North American Specification) and has tune locked to Map 5, irrespective of the case date.
R3383 is more than likely a NAS/UK tune that has the tune Locked and Unlocked, respectively. Again this holds true irrespective of what case it's in, or its date.
http://www.remap-14cux.uk/LR-TVR-settings.html
R3652 is a NAS tune only (North American Specification) and has tune locked to Map 5, irrespective of the case date.
R3383 is more than likely a NAS/UK tune that has the tune Locked and Unlocked, respectively. Again this holds true irrespective of what case it's in, or its date.
Edited by davep on Tuesday 4th March 20:32
davep said:
Take a look at SteveSprint's firmware settings table and check the Tune Lock status for the two tunes you are using.
http://www.remap-14cux.uk/LR-TVR-settings.html
R3652 is a NAS tune only (North Americal Specification) and has tune locked to Map 5, irrespective of the case date.
R3383 is more than likely a NAS/UK tune that has the tune Locked and Unlocked, respectively. Again this holds true irrespective of what case it's in, or its date.
Thank you DaveP - that makes sense.http://www.remap-14cux.uk/LR-TVR-settings.html
R3652 is a NAS tune only (North Americal Specification) and has tune locked to Map 5, irrespective of the case date.
R3383 is more than likely a NAS/UK tune that has the tune Locked and Unlocked, respectively. Again this holds true irrespective of what case it's in, or its date.
Edited by davep on Tuesday 4th March 19:36
Time to do some thinking about what to do next.
Gassing Station | General TVR Stuff & Gossip | Top of Page | What's New | My Stuff