Pages: [1]
Author Topic: KWP2000 Len Byte starts with 0x80 question  (Read 5806 times)
zxcv
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 19


« on: March 24, 2018, 05:24:23 PM »

Hi all,

i have an issue i cannot find any docs on - its communication from a single convenience module accessed by can (no other hardware)
in some cases i get a strange 0x80 high byte in the len-header field ? what does this mean ?
in other cases its normal.

any ideas ?

Here is my log, from own software

[Open Channel] open sent...
[Open Channel] wait for response...
*<- ID: 214 - 00 D0 00 03 80 07 01
[Open Channel] got answer...
[Send Params] params sent...
*<- ID: 300 - A1 0F 8A FF 4A FF
[Send Params] parameter response from 0x300 ...
[Main] TP20 channel opened successfully
<- ID: 300 - A1 0F 8A FF 4A FF
<- ID: 300 - A1 0F 8A FF 4A FF
<- ID: 300 - A1 0F 8A FF 4A FF
[KWP2000] cmd sent...
-> ID: 780 - 10 00 02 1A 90
*<- ID: 65F - 00 00 00 00 00 00 00 00
*<- ID: 373 - 40 00 14 00 00 00
*<- ID: 401 - 05 01 00 00 00 00
*<- ID: 300 - B1
[KWP2000] ACK received
*<- ID: 300 - 20 00 13 5A 90 58 58 58
*<- ID: 300 - 21 58 58 58 58 58 58 58
*<- ID: 300 - 12 58 58 58 58 58 58 58
-> ID: 780 - B3
[Main] KWP answer: 5A 90 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58
[Main] KWP answer (text): Z.XXXXXXXXXXXXXXXXX
<- ID: 300 - A1 0F 8A FF 4A FF
[KWP2000] cmd sent...
-> ID: 780 - 11 00 02 1A 9B
*<- ID: 401 - 05 01 00 00 00 00
*<- ID: 300 - B2
[KWP2000] ACK received
*<- ID: 300 - 23 80 30 5A 9B 33 43 30
*<- ID: 300 - 24 39 35 39 34 33 33 20
*<- ID: 300 - 25 20 20 B0 33 34 37 00
*<- ID: 300 - 26 00 00 00 F7 7B 7A EF
*<- ID: 300 - 27 FF FB 20 20 20 49 4D
*<- ID: 373 - 40 00 14 00 00 00
*<- ID: 300 - 28 4D 4F 20 20 20 20 20
*<- ID: 300 - 29 20 20 20 20 30 33 38
*<- ID: 300 - 1A 20
-> ID: 780 - BB
[Main] KWP answer: 5A 9B 33 43 30 39 35 39 34 33 33 20 20 20 B0 33 34 37 00 00 00 00 F7 7B 7A EF FF FB 20 20 20 49 4D 4D 4F 20 20
 20 20 20 20 20 20 30 33 38 20
[Main] KWP answer (text): Z.3C0959433   .347.....{z...   IMMO         038
*<- ID: 401 - 05 01 00 00 00 00
*<- ID: 300 - 1B 80 01 5A
-> ID: 780 - BC
[Main] KWP answer: 5A
Logged
jcsbanks
Full Member
***

Karma: +19/-3
Offline Offline

Posts: 146


« Reply #1 on: March 26, 2018, 05:10:16 AM »

ISO 14230-2 specifies a format byte that contains 6 bit length information and 2 bit address mode information.

A1 A0 L5 L4 L3 L2 L1 L0

A1 and A0 define the form of header which will be used by the message in accordance with the TABLE;
L5...L0 define the length of a message from the beginning of the data fields (ServiceIdentification
byte included) to checksum byte (not included). A message length of 1 to 63 bytes is
possible. If L0 to L5 = 0 then the additional length byte is included.

TABLE:
A1 A0 Mode
0 0 no address information
0 1 Exception mode (CARB)
1 0 with address information, physical addressing
1 1 with address information, functional addressing

Length byte
This byte is provided if the length in the header byte (L0 to L5) is set to 0. It allows the user to
transmit messages with data fields longer then 63 bytes. With shorter messages it may be omitted. This byte
defines the length of a message from the beginning of the data field (service identification byte included) to
checksum byte (not included). A data length of 1 byte to 255 bytes is possible. The longest message consists of a
maximum of 260 bytes. For messages with data fields of less than 64 bytes there are two possibilities: length may
be included in the format byte or in the additional length byte. An ECU does not need to support both possibilities,
the tester is informed about the capability of an ECU through the keybytes.
Logged
zxcv
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 19


« Reply #2 on: March 26, 2018, 07:08:30 AM »

Many Thanks for your answer - i read this spec, but did not get it aligned to it.

[KWP2000] ACK received
*<- ID: 300 - 23 80 30 5A 9B 33 43 30

the KWP header/length in my dump is 0x80 0x30 (so two bytes)

0x30 is the len of the answer, and we have the topmost bit of the upper byte set
so how does this connect to the spec, cause they talk about one byte ?

or you mean the 0x80 is A1 A0 L5 L4 L3 L2 L1 L0 and due to the fact we have L5 to L0 set to zero
we have the len in the next (additional) byte ?

so 0x80 0x30 would mean "with address information, physical addressing"
and
    0x00 0x?? would mean "no address information"

so last question left: if 0x80 means "with address information" where is the address byte then ?!?

i will try to understand in the spec :-) tnx for all


Kind Regards
« Last Edit: March 26, 2018, 07:20:06 AM by zxcv » Logged
jcsbanks
Full Member
***

Karma: +19/-3
Offline Offline

Posts: 146


« Reply #3 on: March 26, 2018, 09:05:06 AM »

Usually I use a Kvaser and Bosch Busmaster, or a DCAN cable to do all this for me so I'm a bit rusty Smiley

I did notice huge similarities between KWP and UDS whether over K line or CAN, and between BMW and VAG. I think the only real difference was that BMW used a different addressing mode to VAG - I cannot remember which way around it was physical vs extended, but the BMW uses an extra byte in the packet rather than as a CAN ID to give the source and destination of the packet to which it added 0x600 to give CAN IDs of 0x6F1 tester and 0x612 ECU.

You appear to have KWP over CAN, and it is using ISO TP (15765) to wrap up the packets to the larger KWP frames.

I cannot seem to find the 14230-2 PDF I was referring to in my earlier answer again.
Logged
zxcv
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 19


« Reply #4 on: March 26, 2018, 02:29:07 PM »

yes this is KWP over CAN, and i have the 14230-x specs but for me it looks more like if this topmost byte means something like
"there is more data coming" instead of the specified use in the standard. according to the standard 0x80 would mean, we have
some destination address byte, which i do not see...

and the KWP seems to be wrapped in TP2.0 cause it looks nearly 100% like SAE J2819

very strange
« Last Edit: March 26, 2018, 02:32:35 PM by zxcv » Logged
Pages: [1]
  Print  
 
Jump to:  

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