Pages: [1]
Author Topic: TP20, ACK 9x -> ACK but not ready for packet ?  (Read 16548 times)
H2Deetoo
Sr. Member
****

Karma: +26/-1
Offline Offline

Posts: 257


« on: July 26, 2015, 07:18:34 AM »

Hi guys,

I am writing some KWP2000 routines over TP20.
Normally you send or receive an ACK (Bx) byte at specific moments.
Sometimes I am receiving a 9x byte, which seems to be an "ACK but not ready for next packet".

I can't find any information on what to do in this case?!
The only TP20 info I found is here: http://jazdw.net/tp20

Anyone know this, or has some log where this ACK is used?


Regards,
H2Deetoo
Logged
Basano
Full Member
***

Karma: +90/-3
Offline Offline

Posts: 192


« Reply #1 on: July 26, 2015, 12:16:41 PM »

Let me know if this helps?
Logged
H2Deetoo
Sr. Member
****

Karma: +26/-1
Offline Offline

Posts: 257


« Reply #2 on: July 26, 2015, 11:55:00 PM »

Thanks!
It seems my missing info is all in this document, I'll check it out!


Regards,
H2Deetoo
Logged
superglitch
Jr. Member
**

Karma: +4/-0
Offline Offline

Posts: 45


« Reply #3 on: May 09, 2016, 12:42:06 PM »

You're doing it too fast.
« Last Edit: May 09, 2016, 12:49:28 PM by superglitch » Logged
H2Deetoo
Sr. Member
****

Karma: +26/-1
Offline Offline

Posts: 257


« Reply #4 on: August 15, 2016, 10:32:43 PM »

It's all sorted now, I simply didn't have all the needed info at the time.


Regards,
H2Deetoo
Logged
jasnm
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 7


« Reply #5 on: October 10, 2016, 09:22:55 AM »

Let me know if this helps?

I'm having the same problem of occasional 9x responses instead bx ACKs in my test code. Do you know what the cause is?
Logged
H2Deetoo
Sr. Member
****

Karma: +26/-1
Offline Offline

Posts: 257


« Reply #6 on: October 10, 2016, 11:36:21 PM »

Yes it is a normal answer when the remote side isn't ready yet.
Check the attached document how to properly cope with this reply
Logged
jasnm
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 7


« Reply #7 on: October 18, 2016, 09:31:27 AM »

Yes it is a normal answer when the remote side isn't ready yet.
Check the attached document how to properly cope with this reply

The document indicates the same block should be resent after 100 ms, from my testing this doesn't seem to work as described. Here's a snippet when the first request returned 0x92 and subsequent retries all return 0x92.

Code:
0339 05 12 00 02 1a 91
0300 01 92
0339 05 12 00 02 1a 91 
0300 01 92
0339 05 12 00 02 1a 91 
0300 01 92
0339 05 12 00 02 1a 91

Has anyone got some vcds can dumps of a full scan?
Logged
Teitek
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 21


« Reply #8 on: March 07, 2017, 11:19:53 AM »

The document indicates the same block should be resent after 100 ms, from my testing this doesn't seem to work as described. Here's a snippet when the first request returned 0x92 and subsequent retries all return 0x92.

Code:
0339 05 12 00 02 1a 91
0300 01 92
0339 05 12 00 02 1a 91 
0300 01 92
0339 05 12 00 02 1a 91 
0300 01 92
0339 05 12 00 02 1a 91

Has anyone got some vcds can dumps of a full scan?

You solve this problem¿?

I have the same problem after transfer some block flashing the ECU and i don't found document refers to this.

TX -> 740            4 1C 00 01 37                    <-- exit transfer
RX -> 300            1 BD
RX -> 300            4 18 00 01 77
TX -> 740            1 B9       
TX -> 740            8 2D 00 0A 31 C5 0A 00 00
TX -> 740            6 1E 1B FF FF 7D 26            <-- CRC32 for segment 0x0A0000 to 0x1BFFFF
RX -> 300            1 BF
RX -> 300            5 19 00 02 71 C5
TX -> 740            1 BA       
TX -> 740            5 1F 00 02 33 C5               
RX -> 300            1 B0
RX -> 300            6 1A 00 03 7F 33 23

....

RX -> 300            6 1C 00 03 7F 33 23
TX -> 740            1 BD       
TX -> 740            5 12 00 02 33 C5   
RX -> 300            1 B3
RX -> 300            6 1D 00 03 7F 33 23
TX -> 740            1 BE       
TX -> 740            5 13 00 02 33 C5   
RX -> 300            1 B4
RX -> 300            6 1E 00 03 7F 33 23
TX -> 740            1 BF       
TX -> 740            5 14 00 02 33 C5   
RX -> 300            1 B5
RX -> 300            6 1F 00 03 7F 33 23
TX -> 740            1 B0       
TX -> 740            5 15 00 02 33 C5   
RX -> 300            1 B6
RX -> 300            6 10 00 03 7F 33 23
TX -> 740            1 B1       
TX -> 740            5 16 00 02 33 C5   
RX -> 300            1 B7
RX -> 300            6 11 00 03 7F 33 23
TX -> 740            1 B2       
TX -> 740            5 17 00 02 33 C5   
RX -> 300            1 97                          <---- 0x97
TX -> 740            1 B8       
TX -> 740            5 18 00 02 33 C5   
RX -> 300            8 28 00 00 00 00 00 00 00   <---- eing ¿¿???
RX -> 300            1 97 

Thanks

Logged
nyet
Administrator
Hero Member
*****

Karma: +608/-168
Offline Offline

Posts: 12270


WWW
« Reply #9 on: March 07, 2017, 04:05:56 PM »

Try a longer wait period?
Logged

ME7.1 tuning guide
ECUx Plot
ME7Sum checksum
Trim heatmap tool

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
H2Deetoo
Sr. Member
****

Karma: +26/-1
Offline Offline

Posts: 257


« Reply #10 on: March 07, 2017, 11:38:20 PM »

Can you log a tool which can correctly do what you want to achieve?
If so it will show what they do to handle this.
Logged
Teitek
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 21


« Reply #11 on: March 08, 2017, 09:44:57 AM »

Try a longer wait period?

Solved with this action.

Thank you !!!!!
Logged
SB_GLI
Hero Member
*****

Karma: +116/-10
Offline Offline

Posts: 1022


« Reply #12 on: June 04, 2019, 06:37:22 AM »

I am also facing a similar issue, and need a little help.  I am confused by the re transmission of an earlier packet by the ecu.

08:28:04.495 - Erasing Flash: 0x020000 - 0x07FFFF
08:28:04.497 - 1.5556 07 40 25 00 0E 31 C4 02 00 00  -- start routine (erase flash)
08:28:04.500 - 1.5583 07 40 26 07 FF FF 00 01 02 03
08:28:04.503 - 1.5607 07 40 17 04 05
08:28:04.505 - 1.5635 03 00 B8
08:28:04.954 - 2.0114 03 00 14 80 03 7F 31 78  -- start routine (neg response, request pending)
08:28:04.963 - 2.0210 07 40 B5
08:28:05.054 - 2.1119 03 00 15 00 03 71 C4 05  -- start routine positive response (0x05?)
08:28:05.059 - 2.1173 07 40 B6
08:28:06.566 - 3.6239 07 40 18 00 02 33 C4       -- request routine results - no response from server
08:28:08.273 - 5.3303 07 40 19 00 02 33 C4       -- request routine results - no response from server
08:28:10.272 - 7.3303 07 40 1A 00 02 33 C4       -- request routine results - no response from server
08:28:10.708 - 7.7657 03 00 98                          -- ack, not ready for next packet
08:28:10.844 - 7.9008 07 40 1A 00 02 33 C4       -- request routine results
08:28:10.854 - 7.9123 03 00 15 00 03 71 C4 05   -- start routine positive response (0x05?)  same response as above @ 2.1119  this confuses me
08:28:10.870 - 7.9278 07 40 B6
08:28:10.900 - System.Exception: Unable to request routine C4 result  -- code crash Smiley

What's up with the second start routine positive response, and how can I handle it?
Logged
SB_GLI
Hero Member
*****

Karma: +116/-10
Offline Offline

Posts: 1022


« Reply #13 on: June 04, 2019, 08:21:29 PM »

I realize now, something in my code changed that caused this problem.

request routine results with no response should not increment counter, and in my case where spaced too far apart.

The result is this:

5.269 07 40 25 00 0E 31 C4 02 00 00
5.270 07 40 26 07 FF FF 00 01 02 03
5.271 07 40 17 04 05
// KWP Data: StartRoutineByLocalIdentifier (31) Parameter: C4
5.272 03 00 B8
// ACK
5.723 03 00 14 80 03 7F 31 78
// KWP Data: NegativeResponse Service: StartRoutineByLocalIdentifier - Code: RequestPending
5.724 07 40 B5
// ACK
5.809 03 00 15 00 03 71 C4 05
// KWP Data: PositiveResponse StartRoutineByLocalIdentifier (71)
5.810 07 40 B6
// ACK
7.327 07 40 18 00 02 33 C4
// KWP Data: RequestRoutineResultByLocalIdentifier (33) Parameter: C4
8.327 07 40 18 00 02 33 C4
// KWP Data: RequestRoutineResultByLocalIdentifier (33) Parameter: C4
9.327 07 40 18 00 02 33 C4
// KWP Data: RequestRoutineResultByLocalIdentifier (33) Parameter: C4
10.327 07 40 18 00 02 33 C4
// KWP Data: RequestRoutineResultByLocalIdentifier (33) Parameter: C4
11.327 07 40 18 00 02 33 C4
// KWP Data: RequestRoutineResultByLocalIdentifier (33) Parameter: C4
11.499 03 00 B9
// ACK
11.501 03 00 16 00 03 73 C4 00
// KWP Data: PositiveResponse RequestRoutineResultByLocalIdentifier (73)
11.501 07 40 B7
Logged
Pages: [1]
  Print  
 
Jump to:  

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