Pages: [1]
Author Topic: ECU "5 baud" init returing ISO 9141-2 instead of KWP  (Read 19684 times)
trichard3000
Full Member
***

Karma: +6/-1
Offline Offline

Posts: 57


« on: June 17, 2013, 11:49:34 AM »

I'm trying to write a simple python script that bit bangs the 0x33 @ 5-baud slow init sequence and then allows for some basic interaction with the ECU. 

If I understand the documentation correctly, the 0x33@5 sequence is the same for both ISO 9141-2 and KWP.  The ECU either responds with "0x55 0x08 0x08" for ISO 9141-2 support or "0x55 0x8F 0xEF" for KWP support.

I have it to the point where the bit banging occurs, the port switches over to 10400bps, and waits for a reply.  I'm then getting the "0x55 0x08 0x08" response.

I noticed that a couple of other tools get the ECU to respond with the KWP reply.  Is there a trick to getting the ECU to init using KWP instead of ISO 9141-2?

Thanks!

*edit:  FWIW, this is an m-box B5/S4. 
« Last Edit: June 17, 2013, 11:59:57 AM by trichard3000 » Logged
prj
Hero Member
*****

Karma: +1072/-485
Offline Offline

Posts: 6041


« Reply #1 on: June 18, 2013, 06:37:16 AM »

You need to send 0x01 if you want KWP.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
trichard3000
Full Member
***

Karma: +6/-1
Offline Offline

Posts: 57


« Reply #2 on: June 18, 2013, 02:27:53 PM »

You need to send 0x01 if you want KWP.

Ah, right!  I thought I was trying this earlier and not getting any reply.  Then I realized that I was banging the bits in the wrong order.  If I send 0x11, I get the reply of 0xEF 0x8F that I'm looking for.

However, now the next step is failing.  I believe I should reply with the inverse of 0x8F, or 0X70, and expect a response of 0xEE.

I'm sending the reply but in return I'm getting junk.  (0x31 0x31 0x32)

Any pointers?

Thanks!
Logged
prj
Hero Member
*****

Karma: +1072/-485
Offline Offline

Posts: 6041


« Reply #3 on: June 19, 2013, 03:12:32 AM »

Code:
void slowInit(unsigned char address) {
unsigned long len = 128;
// The K-Line must be high for at least 300ms
DeviceIoControl(comport, IOCTL_SERIAL_SET_BREAK_OFF, NULL, 0, NULL, 0, &len, NULL);
Sleep(300);

DeviceIoControl(comport, IOCTL_SERIAL_SET_BREAK_ON, NULL, 0, NULL, 0, &len, NULL); // Start bit (low)
Sleep(200);

for (UINT i = 0; i < 8; i++) {
if (((0x01 << i) & address) > 0) {
DeviceIoControl(comport, IOCTL_SERIAL_SET_BREAK_OFF, NULL, 0, NULL, 0, &len, NULL); // 1
} else {
DeviceIoControl(comport, IOCTL_SERIAL_SET_BREAK_ON, NULL, 0, NULL, 0, &len, NULL); // 0
}
Sleep(200);
}

DeviceIoControl(comport, IOCTL_SERIAL_SET_BREAK_OFF, NULL, 0, NULL, 0, &len, NULL);
}

Code:
void KWP2000Init(unsigned char address) {
slowInit(address);
while (readByte() != 0x8F) {}
Sleep(25);
writeByte(0x70);
while (readByte() != 0xFF - address) {}
}

Code:
	KWP2000Init(0x11);
cout << "KWP2000 Init complete.\n";

StartDiagnosticSession(DEVELOPMENT_SESSION, BAUD_56000);
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
prj
Hero Member
*****

Karma: +1072/-485
Offline Offline

Posts: 6041


« Reply #4 on: June 19, 2013, 03:13:07 AM »

And yeah, sorry, it's 0x11.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
trichard3000
Full Member
***

Karma: +6/-1
Offline Offline

Posts: 57


« Reply #5 on: June 19, 2013, 09:51:31 AM »


Great info, thanks for sharing!

   while (readByte() != 0x8F) {}
   Sleep(25);
   writeByte(0x70);
   while (readByte() != 0xFF - address) {}

This is very similar to what I'm trying.  I just can't seem to elicit a response after sending 0x70.  I'm reading okay but maybe I'm not writing properly.  I'm thinking that I may have some kind of mismatch with databits/stopbits/parity or msb vs lsb. 

A few docs reference 7/O/1 for the 5-baud part and then switching to 8/N/1.  Could I be doing that at the wrong time? 
Logged
trichard3000
Full Member
***

Karma: +6/-1
Offline Offline

Posts: 57


« Reply #6 on: June 19, 2013, 11:22:17 AM »

Maybe a little progress...  Instead of getting junk back when I "send" 0x70, I'm now getting 0x70 back.  (I had a type mismatch and was sending the byte's decimal value as a string.  Oops!)

This echoing back of the request seems consistent with the protocol but still no reply of 0xEE.  My timing looks okay. Grrr!
Logged
trichard3000
Full Member
***

Karma: +6/-1
Offline Offline

Posts: 57


« Reply #7 on: June 19, 2013, 02:02:23 PM »

Okay, I got it.  I'm seeing the 0xEE now.  I think that there was some junk hanging around in the buffer that I fixed with a timely flush.

Now on to hacking up some KWP2000 commands!

*Thanks*
Logged
prj
Hero Member
*****

Karma: +1072/-485
Offline Offline

Posts: 6041


« Reply #8 on: June 20, 2013, 12:41:00 AM »

Note, that you do not need to switch baud rate.
I don't know which platform you are using this on, but it is easier to use break on and off to bit bang the line with sleep, and set the line up correctly immediately.
Logged

PM's will not be answered, so don't even try.
Log your car properly - WinOLS database - Tools/patches
trichard3000
Full Member
***

Karma: +6/-1
Offline Offline

Posts: 57


« Reply #9 on: June 20, 2013, 10:34:27 AM »

I'm writing this in python running on a Raspberry Pi with Wheezy/Debian. 

I'm using pylibftdi to handle the serial stuff which offers basic IO as well as a bitbang object.  The slow-0x11 init is working fine now and I'm getting in a few basic ECU ID kinds of reads out.  Any kind of baud changes to incorporate at this point would be at the KWP2000 level to support faster repeating reads. 

I'm 100% sure that there are better/easier/more elegant/more standardized/etc. ways of doing what I'm doing.  Once I get to the point where I have something interesting, I'll be happy to share. 

Thanks again!
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.018 seconds with 17 queries. (Pretty URLs adds 0s, 0q)