kuebk
Jr. Member
Karma: +3/-0
 Offline
Posts: 47
|
 |
« on: October 18, 2016, 11:29:35 AM »
|
|
|
While playing with TP2.0 over CAN I started to get duplicated frames or frames with incorrect sequence numbers. Wrong sequence number: can0 740 [8] 25 00 08 36 40 7C F0 00
can0 740 [4] 16 00 00 05
can0 300 [1] B7
can0 300 [8] 2D 00 06 76 00 00 01 00
can0 300 [2] 1E 00 <- seq=E
can0 740 [1] BF
can0 740 [8] 27 00 08 35 50 03 AC 00
can0 740 [4] 18 00 00 24
can0 300 [1] A3
can0 740 [1] A3
can0 300 [6] A1 0F 8A FF 4A FF
can0 300 [1] B9
can0 300 [6] 1E 00 00 02 75 FF <- seq=E, shouldn't be F?
can0 300 [6] 1E 00 00 02 75 FF
can0 300 [1] A8
can0 740 [1] A8
Duplicated frames: can0 740 [8] 2D 00 08 35 50 24 19 00
can0 740 [4] 1E 00 00 04
can0 300 [1] BF
can0 300 [5] 1B 00 02 75 FF <- first occurrence
can0 740 [1] BC
can0 740 [8] 2F 00 08 36 50 24 19 00
can0 740 [4] 10 00 00 04
can0 300 [1] B1
can0 300 [5] 1B 00 02 75 FF <- second occurrence
How should I handle both of these? Thanks. |
|
|
|
« Last Edit: October 18, 2016, 01:27:26 PM by kuebk »
|
Logged
|
VAG immo solutions (clone, immo off, repair) MEDC17, SIMOS, SDI, BCM2, ELV, DQ/DL/VL gearboxes, INVCON, MED9.x crypto
|
|
|
andrew
Newbie
Karma: +0/-0
Offline
Posts: 10
|
|
« Reply #1 on: October 19, 2016, 04:53:37 AM »
|
|
|
You should say something (ACK this or ACK older frame again ) otherwise peer it can drop connection as in 1st case,
if you respond it will continue with new data or retransmit contentious frame
in 2nd case you should ACK again obviously peer doesn't received your ACK
|
|
|
|
|
Logged
|
|
|
|
SKOLS
Newbie
Karma: +0/-1
Offline
Posts: 10
|
|
« Reply #2 on: October 19, 2016, 05:20:33 AM »
|
|
|
Hi kuebk....
Here is a typical frame from a TP2.0 MED9 (S3 8P) open session :
ID: 0x200 Len: 7 Data: 0x1F 0xC0 0x00 0x10 0x00 0x03 0x01
ID: 0x21F Len: 7 Data: 0x00 0xD0 0x00 0x03 0x2E 0x03 0x01
ID: 0x32E Len: 6 Data: 0xA0 0x0F 0x8A 0xFF 0x32 0xFF
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x32E Len: 5 Data: 0x10 0x00 0x02 0x1A 0x9B
ID: 0x300 Len: 1 Data: 0xB1
ID: 0x300 Len: 8 Data: 0x20 0x00 0x30 0x5A 0x9B 0x31 0x4B 0x30
ID: 0x300 Len: 8 Data: 0x21 0x39 0x30 0x37 0x35 0x33 0x30 0x4B
ID: 0x300 Len: 8 Data: 0x22 0x20 0x20 0x30 0x31 0x37 0x30 0x10
ID: 0x300 Len: 8 Data: 0x23 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ID: 0x300 Len: 8 Data: 0x24 0x18 0xAA 0x4A 0x35 0x33 0x33 0x5F
ID: 0x300 Len: 8 Data: 0x25 0x5F 0x47 0x61 0x74 0x65 0x77 0x61
ID: 0x300 Len: 8 Data: 0x26 0x79 0x20 0x20 0x20 0x48 0x31 0x32
ID: 0x300 Len: 2 Data: 0x17 0x20
ID: 0x32E Len: 1 Data: 0xB8
ID: 0x32E Len: 5 Data: 0x11 0x00 0x02 0x1A 0x91
ID: 0x300 Len: 1 Data: 0xB2
ID: 0x300 Len: 8 Data: 0x28 0x00 0x11 0x5A 0x91 0x0E 0x31 0x4B
ID: 0x300 Len: 8 Data: 0x29 0x30 0x39 0x30 0x37 0x39 0x35 0x31
ID: 0x300 Len: 6 Data: 0x1A 0x20 0x20 0x20 0x20 0xFF
ID: 0x32E Len: 1 Data: 0xBB
ID: 0x32E Len: 1 Data: 0xA8
ID: 0x300 Len: 1 Data: 0xA8
ID: 0x200 Len: 7 Data: 0x01 0xC0 0x00 0x10 0x00 0x03 0x01
ID: 0x201 Len: 7 Data: 0x00 0xD0 0x00 0x03 0x40 0x07 0x01
ID: 0x740 Len: 6 Data: 0xA0 0x0F 0x8A 0xFF 0x32 0xFF
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 5 Data: 0x10 0x00 0x02 0x10 0x89
ID: 0x300 Len: 1 Data: 0xB1
ID: 0x300 Len: 5 Data: 0x10 0x00 0x02 0x50 0x89
ID: 0x740 Len: 1 Data: 0xB1
ID: 0x740 Len: 5 Data: 0x11 0x00 0x02 0x1A 0x9B
ID: 0x300 Len: 1 Data: 0xB2
ID: 0x300 Len: 8 Data: 0x21 0x00 0x30 0x5A 0x9B 0x38 0x50 0x30
ID: 0x300 Len: 8 Data: 0x22 0x39 0x30 0x37 0x31 0x31 0x35 0x48
ID: 0x300 Len: 8 Data: 0x23 0x20 0x20 0x30 0x30 0x34 0x30 0x10
ID: 0x300 Len: 8 Data: 0x24 0x00 0x00 0x00 0x01 0xDC 0x5A 0x10
ID: 0x300 Len: 8 Data: 0x25 0x00 0xBF 0x32 0x2E 0x30 0x6C 0x20
ID: 0x300 Len: 8 Data: 0x26 0x52 0x34 0x2F 0x34 0x56 0x20 0x54
ID: 0x300 Len: 8 Data: 0x27 0x46 0x53 0x49 0x20 0x20 0x20 0x20
ID: 0x300 Len: 2 Data: 0x18 0x20
ID: 0x740 Len: 1 Data: 0xB9
ID: 0x740 Len: 7 Data: 0x12 0x00 0x04 0x31 0xB8 0x00 0x00
ID: 0x300 Len: 1 Data: 0xB3
ID: 0x300 Len: 8 Data: 0x29 0x00 0x12 0x71 0xB8 0x01 0x01 0x01
ID: 0x300 Len: 8 Data: 0x2A 0x03 0x01 0x02 0x01 0x06 0x01 0x07
ID: 0x300 Len: 7 Data: 0x1B 0x01 0x08 0x01 0x0D 0x01 0x18
ID: 0x740 Len: 1 Data: 0xBC
ID: 0x740 Len: 5 Data: 0x13 0x00 0x02 0x1A 0x9A
ID: 0x300 Len: 1 Data: 0xB4
ID: 0x300 Len: 8 Data: 0x2C 0x00 0x17 0x5A 0x9A 0x01 0xDC 0x5A
ID: 0x300 Len: 8 Data: 0x2D 0x10 0x00 0xBF 0x30 0x30 0x34 0x30
ID: 0x300 Len: 8 Data: 0x2E 0x10 0x09 0x01 0x03 0x00 0x03 0x18
ID: 0x300 Len: 5 Data: 0x1F 0x0F 0x01 0x60 0xFF
ID: 0x740 Len: 1 Data: 0xB0
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 5 Data: 0x14 0x00 0x02 0x1A 0x91
ID: 0x300 Len: 1 Data: 0xB5
ID: 0x300 Len: 8 Data: 0x20 0x00 0x11 0x5A 0x91 0x0E 0x38 0x50
ID: 0x300 Len: 8 Data: 0x21 0x30 0x39 0x30 0x37 0x31 0x31 0x35
ID: 0x300 Len: 6 Data: 0x12 0x42 0x20 0x20 0x20 0xFF
ID: 0x740 Len: 1 Data: 0xB3
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
You must return an ACK (A3) to keep the session "alive"....
And here is a typical TP2.0 frame of measure block (IE MB 001) :
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 5 Data: 0x15 0x00 0x02 0x21 0x01
ID: 0x300 Len: 1 Data: 0xB6
ID: 0x300 Len: 8 Data: 0x23 0x00 0x1A 0x61 0x01 0x01 0xC8 0x00
ID: 0x300 Len: 8 Data: 0x24 0x05 0x0A 0x71 0x14 0x32 0x80 0x10
ID: 0x300 Len: 8 Data: 0x25 0xFF 0xB2 0x25 0x00 0x00 0x25 0x00
ID: 0x300 Len: 8 Data: 0x16 0x00 0x25 0x00 0x00 0x25 0x00 0x00
ID: 0x740 Len: 1 Data: 0xB7
ID: 0x740 Len: 5 Data: 0x16 0x00 0x02 0x21 0x01
ID: 0x300 Len: 1 Data: 0xB7
ID: 0x300 Len: 8 Data: 0x27 0x00 0x1A 0x61 0x01 0x01 0xC8 0x00
ID: 0x300 Len: 8 Data: 0x28 0x05 0x0A 0x71 0x14 0x32 0x80 0x10
ID: 0x300 Len: 8 Data: 0x29 0xFF 0xB2 0x25 0x00 0x00 0x25 0x00
ID: 0x300 Len: 8 Data: 0x1A 0x00 0x25 0x00 0x00 0x25 0x00 0x00
ID: 0x740 Len: 1 Data: 0xBB
ID: 0x740 Len: 5 Data: 0x17 0x00 0x02 0x21 0x01
ID: 0x300 Len: 1 Data: 0xB8
ID: 0x300 Len: 8 Data: 0x2B 0x00 0x1A 0x61 0x01 0x01 0xC8 0x00
ID: 0x300 Len: 8 Data: 0x2C 0x05 0x0A 0x71 0x14 0x32 0x80 0x10
ID: 0x300 Len: 8 Data: 0x2D 0xFF 0xB2 0x25 0x00 0x00 0x25 0x00
ID: 0x300 Len: 8 Data: 0x1E 0x00 0x25 0x00 0x00 0x25 0x00 0x00
ID: 0x740 Len: 1 Data: 0xBF
ID: 0x740 Len: 5 Data: 0x18 0x00 0x02 0x21 0x01
ID: 0x300 Len: 1 Data: 0xB9
ID: 0x300 Len: 8 Data: 0x2F 0x00 0x1A 0x61 0x01 0x01 0xC8 0x00
ID: 0x300 Len: 8 Data: 0x20 0x05 0x0A 0x71 0x14 0x32 0x80 0x10
ID: 0x300 Len: 8 Data: 0x21 0xFF 0xB2 0x25 0x00 0x00 0x25 0x00
ID: 0x300 Len: 8 Data: 0x12 0x00 0x25 0x00 0x00 0x25 0x00 0x00
ID: 0x740 Len: 1 Data: 0xB3
ID: 0x740 Len: 1 Data: 0xA3
ID: 0x300 Len: 6 Data: 0xA1 0x0F 0x8A 0xFF 0x4A 0xFF
ID: 0x740 Len: 5 Data: 0x19 0x00 0x02 0x21 0x01
ID: 0x300 Len: 1 Data: 0xBA
ID: 0x300 Len: 8 Data: 0x23 0x00 0x1A 0x61 0x01 0x01 0xC8 0x00
ID: 0x300 Len: 8 Data: 0x24 0x05 0x0A 0x71 0x14 0x32 0x80 0x10
ID: 0x300 Len: 8 Data: 0x25 0xFF 0xB2 0x25 0x00 0x00 0x25 0x00
ID: 0x300 Len: 8 Data: 0x16 0x00 0x25 0x00 0x00 0x25 0x00 0x00
ID: 0x740 Len: 1 Data: 0xB7
ID: 0x740 Len: 5 Data: 0x1A 0x00 0x02 0x21 0x01
ID: 0x300 Len: 1 Data: 0xBB
ID: 0x300 Len: 8 Data: 0x27 0x00 0x1A 0x61 0x01 0x01 0xC8 0x00
ID: 0x300 Len: 8 Data: 0x28 0x05 0x0A 0x71 0x14 0x32 0x80 0x10
ID: 0x300 Len: 8 Data: 0x29 0xFF 0xB2 0x25 0x00 0x00 0x25 0x00
ID: 0x300 Len: 8 Data: 0x1A 0x00 0x25 0x00 0x00 0x25 0x00 0x00
ID: 0x740 Len: 1 Data: 0xBB
ID: 0x740 Len: 5 Data: 0x1B 0x00 0x02 0x21 0x01
ID: 0x300 Len: 1 Data: 0xBC
SKOLS
|
|
|
|
« Last Edit: October 19, 2016, 05:29:10 AM by SKOLS »
|
Logged
|
|
|
|
kuebk
Jr. Member
Karma: +3/-0
Offline
Posts: 47
|
|
« Reply #3 on: October 19, 2016, 02:08:05 PM »
|
|
|
You should say something (ACK this or ACK older frame again ) otherwise peer it can drop connection as in 1st case,
if you respond it will continue with new data or retransmit contentious frame
Yep I should reply with ACK, but I thought that sequence numbers should follow each other. in 2nd case you should ACK again obviously peer doesn't received your ACK
Thanks, after ACK the 2nd occurence of will I need to send again 0x36 dataTransfer request? @SKOLS, thank you for your examples and tips. I have managed to successfully establish session and use services, issues start to appear after 20-30 (or sometimes even more) minutes of continuous communication. |
|
|
|
« Last Edit: October 19, 2016, 02:34:24 PM by kuebk »
|
Logged
|
VAG immo solutions (clone, immo off, repair) MEDC17, SIMOS, SDI, BCM2, ELV, DQ/DL/VL gearboxes, INVCON, MED9.x crypto
|
|
|
andrew
Newbie
Karma: +0/-0
Offline
Posts: 10
|
|
« Reply #4 on: October 20, 2016, 12:56:11 PM »
|
|
|
Yep I should reply with ACK, but I thought that sequence numbers should follow each other.
Generally you are right, normally they are but it also you can manage to retransmit data (emulate as it would got lost ) - it looks like "can0 300 [2] 1E 00 <- seq=E" got corrupted in peer or your TP20 stack Thanks, after ACK the 2nd occurence of will I need to send again 0x36 dataTransfer request?
...
Nope |
|
|
|
|
Logged
|
|
|
|
kuebk
Jr. Member
Karma: +3/-0
Offline
Posts: 47
|
|
« Reply #5 on: October 24, 2016, 04:00:30 PM »
|
|
|
I think I have managed to solve my previous issues.  The worst news is that I started to get frames like these: can0 740 [8] 22 00 08 35 40 7C F0 00
can0 740 [4] 13 00 00 05
can0 300 [1] B4
can0 300 [5] 15 00 02 75 FF
can0 740 [1] B6
can0 740 [8] 24 00 08 36 40 7C F0 00
can0 740 [4] 15 00 00 05
can0 300 [1] B6
can0 300 [8] 26 00 06 76 00 00 01 00
can0 300 [2] 17 00
can0 740 [1] B8
can0 740 [8] 26 00 08 35 50 03 AC 00
can0 740 [4] 17 00 00 24
can0 300 [1] B8
can0 300 [1] A3
can0 740 [1] A3
can0 300 [5] 18 00 02 75 FF
can0 300 [6] A1 0F 8A FF 4A FF
can0 740 [1] B9
can0 740 [8] 28 00 08 36 50 03 AC 00
can0 740 [4] 19 00 00 24
can0 300 [1] BA
can0 300 [8] 28 00 00 00 00 00 25 76 <- too many bytes before length?
can0 300 [8] 28 00 00 00 00 00 25 76
can0 300 [1] A8
can0 740 [1] A8
can0 740 [8] 23 00 08 35 40 7C F0 00
can0 740 [4] 14 00 00 05
can0 300 [1] A3
can0 740 [1] A3
can0 300 [1] B5
can0 300 [6] A1 0F 8A FF 4A FF
can0 300 [7] 15 00 00 00 02 75 FF <- too many bytes before length? shouldn't it be 15 00 02 75 FF?
can0 740 [1] B6
can0 300 [1] A3
can0 300 [6] A1 0F 8A FF 4A FF
can0 740 [1] A3
can0 300 [1] A3
can0 740 [1] A3
can0 300 [6] A1 0F 8A FF 4A FF
can0 300 [1] A3
can0 740 [1] A3
Generally seems like most of problems arise when ECU sends A1/A3 frames, but I don't understand why.  |
|
|
|
« Last Edit: October 24, 2016, 04:02:07 PM by kuebk »
|
Logged
|
VAG immo solutions (clone, immo off, repair) MEDC17, SIMOS, SDI, BCM2, ELV, DQ/DL/VL gearboxes, INVCON, MED9.x crypto
|
|
|
kuebk
Jr. Member
Karma: +3/-0
Offline
Posts: 47
|
|
« Reply #6 on: October 27, 2016, 12:15:33 PM »
|
|
|
I tried to reply with ACK 9x for "special" frames mentioned in my previous posts and got partial success but still I have no idea why ECU is sending frames with incorrect length. can0 740 [8] 28 00 08 36 50 24 19 00
can0 740 [4] 19 00 00 04
can0 300 [6] A1 0F 8A FF 4A FF
can0 300 [1] BA
can0 300 [8] 26 00 00 00 00 00 05 76
can0 740 [1] 96
can0 300 [8] 26 00 00 00 00 00 05 76
can0 300 [5] 17 00 00 00 01
can0 740 [1] 96
can0 740 [1] 97
can0 300 [8] 26 00 00 00 00 00 05 76
can0 300 [5] 17 00 00 00 01
can0 740 [1] 96
can0 740 [1] 97
can0 300 [8] 26 00 00 00 00 00 05 76
can0 300 [5] 17 00 00 00 01
can0 740 [1] 96
can0 740 [1] 97
can0 300 [8] 26 00 00 00 00 00 05 76
can0 300 [5] 17 00 00 00 01
can0 740 [1] 96
can0 740 [1] 97
can0 300 [8] 26 00 00 00 00 00 05 76
can0 300 [5] 17 00 00 00 01
can0 740 [1] 96
can0 300 [1] A8
can0 740 [1] 97
can0 740 [1] A8
Above is just a proof of concept, after first ACK 96 complete frame should be handled without sending 96/97 ACKs. |
|
|
|
« Last Edit: October 27, 2016, 03:21:55 PM by kuebk »
|
Logged
|
VAG immo solutions (clone, immo off, repair) MEDC17, SIMOS, SDI, BCM2, ELV, DQ/DL/VL gearboxes, INVCON, MED9.x crypto
|
|
|
|
H2Deetoo
|
|
« Reply #7 on: November 01, 2016, 05:19:00 AM »
|
|
|
I am sorry I have never experienced such packets.
I guess your ecu is to blaim but why ...
|
|
|
|
|
Logged
|
|
|
|
superglitch
Jr. Member
Karma: +4/-0
Offline
Posts: 45
|
|
« Reply #8 on: November 11, 2016, 03:53:38 PM »
|
|
|
The ACK of 0x9x is never really used in any of the implementations I've logged. I would suggest looking at possibly errors with your hardware (resistors between CAN lines and such).
|
|
|
|
|
Logged
|
|
|
|
kuebk
Jr. Member
Karma: +3/-0
Offline
Posts: 47
|
|
« Reply #9 on: November 11, 2016, 04:36:37 PM »
|
|
|
It could be a hardware failure, but "that" frames happen after A1 channel param frame only. I'm doing 15 minutes sessions, like 5-10 first session works flawlessly, the later ones are making problems - and that's kinda odd for me. :<
What hardware are you talking about? You meant ECU or CAN2USB?
Checked the resistor between CAN lines and it gives me reading at 118 Ohm, same resistor but not installed reads at 116 Ohm, checked resistance in genuine VCDS and it is 120 Ohm, could that be an issue?
|
|
|
|
« Last Edit: November 11, 2016, 04:55:10 PM by kuebk »
|
Logged
|
VAG immo solutions (clone, immo off, repair) MEDC17, SIMOS, SDI, BCM2, ELV, DQ/DL/VL gearboxes, INVCON, MED9.x crypto
|
|
|
superglitch
Jr. Member
Karma: +4/-0
Offline
Posts: 45
|
|
« Reply #10 on: November 11, 2016, 10:57:59 PM »
|
|
|
Sorry early reply didn't fully inspect your logs.
You need to reply to channel test messages (0xA1 or 0xA3) first refer to SAE J2819 for priorities of TP2.0.
I've logged many different applications, the only time that an 0x9x ACK packet is ever used is when there is a mistake or the tester is sending messages too fast.
|
|
|
|
|
Logged
|
|
|
|
|
H2Deetoo
|
|
« Reply #11 on: November 12, 2016, 05:51:00 AM »
|
|
|
I did experience ACK of 0x9x packets (see some other post of mine), and handle them appropriately.
So depending on which ecu/sw version this is normal.
However those packets with wrong length I never saw ...
|
|
|
|
|
Logged
|
|
|
|
jasnm
Newbie
Karma: +0/-0
Offline
Posts: 7
|
|
« Reply #12 on: November 13, 2016, 09:44:10 AM »
|
|
|
I did experience ACK of 0x9x packets (see some other post of mine), and handle them appropriately.
Having spent a fair amount of time (months) decoding TP/KWP2000. I would say 0x9x aren't the norm. As superglitch indicated they either indicating requests are sent too fast or a mistake. Its also important to bear in mind that the ECU will slow its communication down if its busy with higher priority tasks or tight on resources. Hence you aren't guaranteed your responses in a timely manor. |
|
|
|
|
Logged
|
|
|
|
|
H2Deetoo
|
|
« Reply #13 on: November 14, 2016, 07:42:15 AM »
|
|
|
>either indicating requests are sent too fast
Well for me this means those packets are normal.
I mean, a tool preferably wants to send as fast as it can and the ecu can slow it down by replying these packets. Nothing strange and normally no problem.
|
|
|
|
|
Logged
|
|
|
|
jasnm
Newbie
Karma: +0/-0
Offline
Posts: 7
|
|
« Reply #14 on: November 15, 2016, 01:34:04 AM »
|
|
|
>either indicating requests are sent too fast
Well for me this means those packets are normal.
I mean, a tool preferably wants to send as fast as it can and the ecu can slow it down by replying these packets. Nothing strange and normally no problem.
As per the spec, for acknowledge with receiver not ready 9X, the senders needs to wait 100 ms (T_Wait) and then re-transmit TP blocks starting from sequence X. The tool is forced to slow down by the ecu, in fact the ecu can slow you down further by sending subsequent 9X. The overhead for a tool would be to cache the preceding TP blocks for such scenario. It can be further complicated by the possibly that the 9X refers to a TP block from a previous KWP2000 command. Circumventing this by responding with 9X won't always solve the problem as you can't guaranteed what the ecu actually received. |
|
|
|
« Last Edit: November 15, 2016, 01:41:23 AM by jasnm »
|
Logged
|
|
|
|
|
