Technical 6F/16F Cinque/Sei ECU Reader Project

[CinqSporting97]

I'm writing the software to run from Windows, minimum spec is not important as there isn't any really demanding processing.

However I may create the software using .NET so something that you can put v2.0 of the .NET framework on would be good. Something that can run Windows 98 up should do the trick, though maybe Windows 2000 would be a safer option.

See here for required specs:
http://www.microsoft.com/downloads/...CB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en


If anyone is interested here is what I am doing:

Stripping my working circuit (PIC, MAX232, etc) down to the bare minimum of a 0-12V to RS232 invertor / level shifter built from discrete components. I believe I have a circuit that will work.

Before I was concerned about the non standard 7812.5 baud rate and accurate timing required to do the ECU initialisation which is why I built the dedicated PIC circuit to take care of it all.

However, I have seen that some (not all) PC serial ports can be set to 7680 baud which is within 2% of what we need (the ECU has a published tolerance of 5%).

All I need now is to develop a reliable and repeatable why of producing a 110ms ± 10% for the ECU initialisation. This is more difficult than you would think in a multitasking operating system like Windows.

Any thoughts or comments would be appreciated - as always.

 

[EI4GGB]

possibly use the DTR or RTS line to also pull the K line low (thats what I'm doing), problem is that this wouldnt work with a generic K-line interface without modification. I think that the older dumb VAG COM interfaces with the L line used this..

 

[reddy4bed]

I

All I need now is to develop a reliable and repeatable why of producing a 110ms ± 10% for the ECU initialisation. This is more difficult than you would think in a multitasking operating system like Windows.

Any thoughts or comments would be appreciated - as always.

Just got to the final stages of making my simple program work on XP.
sets init baud ok
reads and displays iso code ok
but that damn 110ms delay is a problem, it seems that I cannot activate
timer2 from direct access.
changes to 7812 baud ok
assembles request byte ok and sends it, but of course no response!.
It might be possible to do successive reads from the rtc and test a timing loop over several secs then calculate the timer values.
I also belive that a reliable tick can be obtained from the video in XP, but thats not much help to me working in assembler.

 

[red]

I remember commenting in this thread in Dec-06. No-one posted in 2007 so I thought it had died (again) but then interest resumed this year. Have been reading avidly to catch up on development. Interesting stuff, particularly from CinqSporting97 and reddy4bed.

Sounds like the present stumbling block is the need for a 110mS gap between the 0F AA CC bytes. Two thoughts (neither particularly elegant nor thought through, just brainstorming as it were):

(a) Hardware timer (e.g. 555) triggered by each byte sent, with its output merged with K line so that port can listen for timeout. You'd need some way of only triggering it during init else it would interfere with normal K line data.

(b) Software loop (in assembler) counting down from a constant that was entered by the user. Obviously the constant value would depend on processor speed so how would user know what figure to enter? Theoretically it would be proportionate to processor speed. Also, only valid if you can stop Windows multitasking while you count down (I haven't programmed in Windows environment so I don't know whether possible).

Aside of that, how can I tell whether my laptop port can be set to 7680 Baud to work with a non-PIC solution? Do I need to find out what chipset it uses and look for data?

Red.

 

[CinqSporting97]

Hi Red,
You're right the problem is getting a reliable method of producing a 110ms delay for the ECU init.

I don't think the 555 timer solution would be workable as I want to make the hardware as minimal as possible. If you were using external circuitry to produce the delay and send the bytes, you would need a way to buffer the bytes in hardware. (The easiest way to do this would probably be with a PIC, etc)

A software loop in assembler would be the brute force way to do it, but if you're running it under Windows there is still the risk of it being interrupted by another process.

The solution (?) I've devised involves querying the CPU performance counter continuously in a loop until the desired 110ms has elapsed. The performance counter is driven by the CPU clock so it is super accurate and has a very high resolution, plus it ticks even when your process isn't running on the CPU so it should reflect how much time has actually past. The good points are that this approach will work in most high level languages however you still have the possiblity of being interrupted by the Windows process scheduler.

This will be the case no matter what solution we choose, what we must do is determine if the possiblity of being interrupted is actually a problem.

I have written a small utility which tests the accuracy of this method and it seems that on my computer it is well with 5% of 110ms. However this may be different on other machines.

Would anyone be willing to try it on their PCs and let me know the results?

I am not sure how you can tell if your serial port is capable of 7680 other than try it an see. There doesn't seem to be much documentation out there about non standard baud rates.

I could maybe incorporate a test into the timing utility (above) to set the serial port to 7680 and send some bytes to see if it is successful.

I am trying to oversimplify the hardware too much, is anyone interested in building the PIC based code reader?

You would need to be able to build an medium complexity electronic circuit and have / buy / build a PIC programmer.

 

[reddy4bed]

Think I have the answer to the 110ms problem, it seems to send the 3 bytes seperated accurately and repeatedly goes like this:-

read the rtc 10ms byte until its below say 30d
add 10 (for 100ms) and store it
send first byte
read rtc byte again and wait till its more than stored value
add 10 and store it
send second byte
etc etc
obviously you can adjust it to within 10 ms by adding 9 or 11
seems pretty close on the scope, with my test pc, but got to verify it on the xp.

 

[red]

CinqSporting97,

Personally, I wanted to avoid a PIC solution; I don't have a programmer.

What level of hardware simplification have you reached? I have some schematics for OBD2 that use only one or two transistors or an opto-isolator. I know that's a different protocol but it still interfaces an RS232 port to an ECU with K and L lines. I'll have another look at these schematics to see whether any would suit the 12V system for the 16F.

Incidentally, have you seen any documents that detail the electrical specifications of the 16F? (I have the Italian doc - and the excellent translation by arseofbox - that details the protocol but doesn't include electrical specifications).

red

 

[CinqSporting97]

Red,

If I can get the software to produce an accurate enough delay I am fairly certain that I can simplify the hardware right down to two FETs (Field Effect Transistors, see datasheet, http://www.nxp.com/acrobat_download/datasheets/2N7000-03.pdf) and a handful of resistors.

No optoisolators, etc required. Apologies for not getting a schematic or any source code for you guys to see, but I want to test everything first so I don't give out any bad info.

I haven't seen any electrical specifications for the 16F (I posted something along those lines a few months back), but what I have learned through experimentation is:

1. The signals to / from the ECU are 0-12V positive logic. i.e. Logic 0 is GND and Logic 1 is +12V.
2. The K and L lines seem to be pulled up by an internal pull up resistor inside the ECU.
3. The signalling is not NRZ (Non Return to Zero) as the italian document says as that would require the idle state (Logic 0) to be something other than 0V (GND).

As an aside, has anyone ever had to make up their own superseal connectors? I got a few the other day (for this reader) and crimped the terminals, etc but I can't get them to lock into the housing. I know you can get a special tool to make these up but I was wondering if anyone had a DIY alternative.

 

[reddy4bed]

To anyone whos interested.
Got the thing working at last on my XP .
The progworks for me, but you can try it and see if you get results.

 

[red]

reddy4bed,

Did you write this in VB? Can you post the source? I may need to use COM2 (2F8-2FF) instead of COM1 (3F8-3FF) or probably be able to choose between the two.

red

 

[reddy4bed]

Used assembler and A86 & D86 debug.
Its not very tidy, but you should be able to see what needs altering.

 

[red]

Thanks reddy4bed. Just the equ statements to change. I'm using a USB to serial adapter so it's a virtual serial port I'm dealing with. I need to determine whether that will be transparent or whether more software is needed.

red

 

[reddy4bed]

cant answer that one!

 

[brainsucker]

omg ty guys, i can't believe I've finally found a free piece of code to work with IAW.
One week ago my girlfriend bought a Punto (176) 1.1 1995 (IAW 16FF.EB), and it seems we already got something to diagnose
Some days before I've found forzavx site, with nice easy scheme (look at it here, really very simple one forzavx.com/gecu/monitor/tutorial-monitor.html), but it still missing links to any working piece of software for diagnostics (can't find mentioned IAWdiag or GECUmonitor anywhere at their site). I've tried to contact author, but still no reply.

However as I understand the same scheme will suit any 3-pin fiat diagnostic connector (don't think they will make them to use different voltage , and now I finally get your source. I'll try to assemble and test the scheme ASAP. The biggest problems i await from the USB2COM converter (ftdi based), i'm using to get com-port for my laptop, however some googling says it should work with 7680 baud rate right.

As soon as I will make this scheme and your sample work I'll try to convert it to any high level (C++/C#) language. Last problem I see here is the protocol description (beside the provided 0x70 and 0x71 codes). Have you got any information about other ECU answer / replies / memory cells / actuator tests, etc. IDs?

Anyway thanks for the already provided info, I think that should be enough for the start

 

[red]

Brainsucker,

There's a spec. document for the IAW 16F around on the net that was originally in Italian but translated to English kindly by arseofbox on this forum. Here's some of the data from it. After doing the initialisation, the following codes can be sent to ECU to glean data and to test actuators, etc. If any of it doesn't make sense you'll probably need to refer to the spec. document.

Some of the responses have to be entered into the given formulas to get meaningful results.

I've left a few question marks in where the document has ambiguous information.


01 Engine speed MSB (15 x 10^6) / $01$02 RPM
02 Engine speed LSB
03 Injector duration MSB (2 x $03$04) / 10^3 mS
04 Injector duration LSB
05 Ignition advance $05 / 2 Deg
06 Manifold absolute pressure $06 x 3 mmHg
07 Air temperature $07 - 40 Deg C
08 Water temperature $08 - 40 Deg C
09 Throttle angle $09 x 0.4234 - 2.9638 Deg
0A Battery voltage $0A x 0.0625 V
0B Lambda probe correction ($0B x 0.002656) + 0.66 %
0C Idle stepper motor position $0C Steps
0D Idle stepper integral gain $0D / 2 (2's complement) Steps
0E Idle stepper proportional gain $0E / 2 (2's complement) Steps
0F Trimmer position 00H = -127, 80H = 00, FFH = +127 TRIMRAM
10 Non-validated input errors. Coded byte ERR-CO-INP
11 Non-validated output errors. Coded byte ERR-CO-OUT
12 Non-validated functionality errors. Coded byte ERR-CO-FUN
13 FGSTAT. Coded byte
14 Validated input errors. Coded byte ERR-VA-INP
15 Validated output errors. Coded byte ERR-VA-OUT
16 Validated functionality errors . Coded byte ERR-VA-FUN
17 Repair code (xxH) ASCII char
18 Repair code + 1 (xxH) ASCII char
19 Repair code + 2 (xxH) ASCII char
1A Repair code + 3 (xxH) ASCII char
1B Repair code + 4 (xxH) ASCII char
1C Repair code + 5 (xxH) ASCII char
1D Repair code + 6 (xxH) ASCII char
1E Repair code + 7 (xxH) ASCII char
1F Repair code + 8 (xxH) ASCII char
20 Repair code + 9 (xxH) ASCII char
21 Repair code + 10 (xxH) ASCII char
22 Auto-calibration correction MSB $22$23
23 Auto-calibration correction LSB
24 Auto-calibration correction MSB with A/C $24$25
25 Auto-calibration correction LSB with A/C
26 Minimum engine speed (target) $26 x 8 RPM
27 Minimum offset turns $27 x 8 RPM
28 Stepper correction (delta) $28 - 128
29 Stepper correction from tester $29 - 128 ALFAFTR
2A FGSTAT2 Coded byte FGSTAT2
2B Sign of non-validated input errors. Coded byte SE-CO-INP
2C Sign of non-validated output errors. Coded byte SE-CO-OUT
2D Sign of non-validated functionality errors. Coded byte SE-CO-FUN
2E Sign of validated input errors. Coded byte SE-VA-INP
2F Sign of validated output errors. Coded byte SE-VA-OUT
30 Sign of validated functionality errors. Coded byte SE-VA-FUN
31 NOT USED
32 AC offset parameter MSB $32$33 ADOFFSET
33 AC offset parameter LSB
34 AC offset parameter MSB $34$35 ADOFFPURG
35 AC offset parameter LSB
36 AC offset parameter MSB $36$37 ADOFFPL
37 AC offset parameter LSB
38 AC gain parameter MSB $38$39 ADGAIN
39 AC gain parameter LSB
70 Immobilizer ID code NOT VIEWABLE
71 Immobilizer state - UNIVAS. Coded byte
72 Immobilizer errors - EEVAS. Coded byte
73 Immobilizer error meter - CRDVAS Max FF, Dec every Key-On unless errors

Meaning if set to 1 in ERR-CO-INP or ERR-VA-INP
1 - Throttle position sensor error
2 - MAP sensor error
3 - Lambda sensor error / K02 out of range
4 - Water temperature sensor error
5 - Air temperature sensor error
6 - Battery voltage error
7 - Stepper position estimation error (N/A)
8 - Not used

Meaning if set to 1 in ERR-CO-OUT and ERR-VA-OUT
1 - Injector error
2 - Error in ignition coil 1
3 - Error in ignition coil 2
4 - Idle stepper motor error
5 - Charcoal canister error
6 - Air conditioner relay error
7 - Fuel pump error
8 - Error in generic system relay

Meaning if set to 1 in ERR-CO-FUN and ERR-VA-FUN
1 - Auto-calibration parameter error
2 - RAM errors
3 - ROM errors
4 - EEPROM errors
5 - Microprocessor errors
6 - TDC / RPM sensor error
7 - Not used
8 - Not used

SE-CO-INP and SE-VA-INP Meaning if set to 1. Meaning if set to 0
1 - Throttle position shorted to GND. Throttle position sensor is O/C or shorted to Vbatt
2 - MAP sensor shorted to Vbatt. MAP sensor is O/C or shorted to GND
3 - Not used
4 - Water temp sensor shorted to GND. Water temp sensor is O/C or shorted to Vbatt
5 - Air temp sensor shorted to GND. Air temp sensor is O/C or shorted to Vbatt
6 - Vbatt above maximum limit. Vbatt below minimum / power latch error
7 - Not used
8 - Not used

SE-CO-OUT and SE-VA-OUT Meaning if set to 1. Meaning if set to 0
1 - Injector is shorted to GND or Vbatt or thermal shutdown. Injector is O/C
2 - Coil 1 is shorted to Vbatt. Coil 1 is O/C or shorted to GND
3 - Coil 2 is shorted to Vbatt. Coil 2 is O/C or shorted to GND
4 - Stepper is shorted to GND or Vbatt or thermal shutdown. Stepper is O/C
5 - Canister is shorted to Vbatt. Canister is O/C or shorted to GND
6 - Air conditioner relay is shorted to Vbatt. Air conditioner relay is O/C or shorted to GND
7 - Fuel pump relay is shorted to Vbatt. Fuel pump relay is O/C or shorted to GND
8 - Generic relay is shorted to Vbatt. Generic relay is O/C or shorted to GND

SE-CO-FUN and SE-VA-FUN Meaning if set to 1. Meaning if set to 0
1 - Auto-calibration parameters too rich. Auto-calibration parameters too lean
2 - Not used
3 - Not used
4 - Not used
5 - Not used
6 - Not used
7 - Not used
8 - Not used

FGSTAT Meaning if set to 1. Meaning if set to 0
1 - Diagnostics OK, TH2O OK, stepper in RUN
2 - Engine running Engine stopped
3 - Square wave signal OK with engine running. Square wave signal not OK
4 - Throttle at Min or Max. Throttle partially open
5 - Lambda sensor in closed loop. Lambda sensor in open loop
6 - Air conditioner on. Air conditioner off
7 - System auto-calibration OK. System auto-calibration not OK (TRIMRAM regulation OK)
8 - Executing stepper motor test

FGSTAT2 Meaning if set to 1. Meaning if set to 0
1 - Not used
2 - Not used
3 - Stepper auto-calibration OK. Stepper auto-calibration not OK (ALFAFTR regulation OK)
4 - Not used
5 - Not used
6 - Not used
7 - Power latch line not OK. Power latch line OK
8 - Not used


ACTIVE DIAGNOSTICS
Key ON, engine off
AA Enter Active Diagnostics mode (ECU echoes AA)
EE from ECU indicates fault
FF from ECU indicates test OK
80 Fuel pump relay operation. Operate for 30 seconds
81 Injector operation. Activate 4mS every second, 5 times
82 Ignition coil 1 operation. Activate for 2mS every second, 5 times
83 Ignition coil 2 operation. Activate for 2mS every second, 5 times
84 Error cancellation. Cancel all errors in EEPROM next Key-On
85 Charcoal canister operation. Activate for 20mS every second, 7 times
86 Engine rev limiter operation. Activate at 125Hz (3750rpm) for 2 seconds
87 Air conditioner relay operation. Operate for 30 seconds
88 Generic relay operation
89 Toggle system auto-calibration / trimmer CO (limp home). Enable / disable system auto-calibration
8C ?? ?? Stepper test
8E Stepper operation Activate 3 x +/- 32 steps (at 8 step / sec). Engine running
8F TRIMRAM regulation (inhibited from s/w V2A21). System trimming regulation. Engine running
90 ?? ?? System regulation
91 Toggle stepper auto-calibration (steps) / manual regulation Enable / disable trimmer auto-calibration
92 Stepper regulation (steps) (inhibited from s/w V2A21). Stepper regulation (steps) (ALFAFTR). Engine running
93 ?? ?? Stepper regulation
94 ?? ?? Stepper regulation
96 ?? ?? Engine speed regulation
97 ?? ?? Engine speed regulation
98 Unblock immobilizer $98 + 5 bytes, terminating in $FF
FF End test or exit diagnostic mode

red

PS if you have any info on whether USB2COM interface affects this project, please advise as that's my proposed route as well.

 

[brainsucker]

I've just searched google for "ftdi 7680" and met the "JBug11 - Version 5 Manual" document: describing some system working with HC11 mcu (core of IAW 16F) at baud rate of 7680 (instead of 7812). This document includes the following note about usb2com:

Many USB-to-serial adaptors will not work satisfactorily with JBug11... However, adaptors based on the FTDI chipset appear to work just fine. The author uses a US232B/LC USB to RS232 Laptop Companion' from EasySync in the UK.

However JBug11 seems to have more specific needs, so I think any USB2COM adapter capable of 7680 baud rate (and most of them should support it) will work with our cars

Thanks for sharing info about protocol. Btw: opendiag yahoo group has plenty fiat techdocs at files section.

 

[reddy4bed]

If you are working with the uP you need to pass into ram a sleeper program.
You can make this prog do what you like, including changing the baud rate to what you need, and talking to pc.
Working with the overhead prom system ie as a ecu, then you have to work with what the prom program has decided ie 7812 approx. Hope this helps.

 

[brainsucker]

Ok, I'm ready to post first results
Everything works ok for my Punto (16F.EB) with simpliest Will Hoult cable, the hardest part was to find required resistors in the shops of our city (I just can't believe that).
You can found binary (required unicode -> WinXP, may be will run at win2k), sources, and a detailed program description in attached file, I'll just say it works fine. And... don't use it if you are afraid of console, I haven't got enough time now to write full GUI and any additional functionality (custom configuration maps for other ECUs), so it is full console application. I hope I'll return to this later.

P.S. Program awaits for ISO code starting with D0 85 and ending with 55, this should work for any 16F ECUs AFAIK.

 

[reddy4bed]

Just run for the first time and com1 opens fine, just need to lash up an ecu, but all good so far, great effort.

BTW sure that my unit sends 55 first and then the code?.

 

[brainsucker]

y, you are right was writing post by memory, right order is 55 ..ISO CODE.., program works that way of course.