14cux question

[FFMan]

I know there are a lot of people out there getting into the detail of the 14 cux and I need a little help.

When reading memory locations H49-H4E I can see the fault codes as documented, but when I remove the fault the code is still present, I think I need to clear it.

How do I do this. Can I overwrite the actual fault memory location eg H4A to clear the coolant error or is there some other technique ?

thanks

[blitzracing]

You have to remove the power (unplug the ECU), send a reset via RoverGauge or ECU mate, or if you have one of the original fault code readers you have to

1. Switch On ignition.
2. Disconnect serial link mating plug, wait 5
seconds, reconnect.
3. Switch OFF ignition, wait for main relay to
drop out.
4. Switch ON ignition. The display should now
reset. If no other faults exist, and the original
fault has been rectified, the display will be
blank.
5. If multiple faults exist repeat Steps 1. to 4. as
each fault is cleared the code will change,
until all faults are cleared. The display will now
be blank.

[FFMan]

the question was more about how do I reset the codes by doing reads/writes to the 14cux. for sure I can kill the battery power and that will do it, but Rovergauge can do it without powering down the ecu, so there is a way, I just wondered what it was.

thanks

[cmb]

Yes, RoverGauge just writes 0x00 to locations $0049 through $004E. That's all there is to it.

[FFMan]

thanks colin. I was just trawling through some old posts and understand your involvement in all this now. I've reverse engineered a few protocols in my time and wish I had been involved back then, but clearly you've covered a lot of ground. I have rovergauge and a cable and its very nice.

As a hobby I am making a 14cux interface to sit permanently connected and flag when a fault is raised or some other value goes out of spec. It'll have a Bluetooth interface and hardwired interface for an optional LCD. I'll write an android GUI that will talk over the Bluetooth to my interface also. Cheap Android hardware (i.e. defunct mobiles) means it would be viable to dedicate a device to display duties only.

Have you ever tried rovergauge over Bluetooth? The RN41 looks like it supports non-standard baud rates and I've used it before in SPP mode in an RFI noisy race car and its solid and quick. I was toying with making a Bluetooth rovergauge interface but I think Android for semi-permanent use in the car gives more options.

Reading the older posts there are clearly a lot of lessons to be derived from the data and various versions of eprom. I wonder now if my development ecu will be substantially different to the tornado chip in my actual griff when I come to live testing. I think I wasn't aiming for all the features of rovergauge, just a subset of values and fault codes.

Would it be terribly cheeky to ask where you get the lamda trim values from ? These don't appear to be documented.

thanks

[robertf03]

I couldn't get the rn41 to do non standard baud rates. I ended up using an atmel chip to convert 8192 bps to 9600. That worked fine when wired, the bluetooth dropped the packet rate to around 60%.

[cmb]

FFMan said:

Have you ever tried rovergauge over Bluetooth? The RN41 looks like it supports non-standard baud rates and I've used it before in SPP mode in an RFI noisy race car and its solid and quick. I was toying with making a Bluetooth rovergauge interface but I think Android for semi-permanent use in the car gives more options.

I'm afraid I have no experience with Bluetooth interface chips, but remember that the nonstandard baud rate is just one characteristic of the unusual signalling -- the device must also attenuate the 12V signal that it receives from the ECU and transmit to the ECU using TTL levels (0V/5VDC). Of course, if you're building an interface circuit that would incorporate one of these RN41 parts, you could certainly take care of these concerns in the design.

FFMan said:

Would it be terribly cheeky to ask where you get the lamda trim values from ? These don't appear to be documented.

The lambda trim values are read from a set of memory locations written by the main ICI (input capture interrupt) in the firmware. It was possible to identify the odd vs even bank locations by correlating them to code that reads the value from the O2 sensor for a particular side of the engine.

I'm not sure what you mean when you mention documentation; is there a document that describes how the various parameters are stored in the ECU? The RoverGauge project is the result of the reverse-engineering effort that my dad started several years ago when he first disassembled a 14CUX firmware image and began analyzing the code.

[FFMan]

Re RN41 - I see - the documentation suggests it can do any baud rate, but maybe it doesn't work as it should.

Colin - thanks for the reply. Today I found the source code for the library routines and this has been really helpful in getting sensible answers from the memory locations when read. Looks like a lot of effort went into getting it to that stage and my little project is progressing nicely.

thanks