Closed jglim closed 3 years ago
Well in case of the KW2C3PE protocol I mean that there is not really a standardization.
In Vediamo/Ecoute they do send 0x1A86
0x1A87
0x1A88
0x1A89
0x1A8A
0x1A...
random and if the ecu do not support (response with 0x7F
) they ignore it or print not supported in init form.
I think we do only need 0x1A86
and 0x1A87
. For very early ecus they used 0x1A86
to identify them.
Let us check following first...
0x1A87
including following in order:(please note that's an example)
SupplierIdentifier
EcuIdentifier
ProductionAndDevelopmentStatus
DiagnosticIdentifier
HardwareVersion
SoftwareVersion
Partnumber
Name | Type | DataType | BytePos | BitPos | ByteLength | BitLength | Note |
---|---|---|---|---|---|---|---|
SupplierIdentifier | String | Byte | 3 | 0 | 1 | - | The prefered supplier is written in cbf file |
EcuIdentifier | unsigned Long | Bit | 4 | 0 | - | 7 | raw data conversion |
ProductionAndDevelopmentStatus | String | Bit | 4 | 7 | - | 1 | 0=Serial Production 1=Devlopment |
DiagnosticIdentifier | unsigned Long | Bit | 5 | 0 | - | 8 | raw data conversion |
HardwareVersion | unsigned Word | Byte | 7 | 0 | 2 | - | YearYearWeekWeek |
SoftwareVersion | unsigned Long | Bit | 9 | 0 | 3 | - | YearYearWeekWeek Patschlevel |
Partnumber | String | Byte | 12 | 0 | 10 | - | ASCII |
That looks like a good start, and seems to match up somewhat with the EZS906:NCV3_0300 trace. However I still do not know where the variant ID (03 00
) can be found in the response (5A 87 01 43 03 01 00 07 28 08 12 00 39 30 36 35 34 35 36 35 30 38
). Could you help me understand this part better?
Once I know how the variant identifier is stored, I can proceed to implement KW2C3PE:
NR: 7F
TesterPresent: 3E
/ 7E
Session switch: 10 92
Variant query: [1A 86
.. 1A 8B
]
I am also assuming that the response for 1A 86
.. 1A 8A
all have the same response structure? Do you think it is possible if you can capture the logs between DTS<->VGSNAG2, and attempt to initiate contact so that I can have more traces to understand the variant detection process?
note plz that 39 30 36 35 34 35 36 35 30 38 is partnumber convert to dec >9065456508
It actually was EZS906.cbf varinat NCV3_0301 as i sayed at first/
so
23:49:45 Request:
1A 87
23:49:45 EZS906:
5A 87 01 43 03 01 00 07 28 08 12 00 39 30 36 35 34 35 36 35 30 38
Got it, this is much clearer now. Once I have a few more traces to compare, I will have enough information to reliably implement KW2C3PE. This is just to make sure that the offset is in positions 4 and 5 (counting from 0), and is the same across other ECUs.
Challenge accepted
Request: DT_ID_DB_Identifikation 1A 86 CR4_NFZ: 5A 86 00 44 46 79 40 31 06 46 06 03 4A 54 00 07 08 12
00 44 46 79 40 = mb number
31 06 = HW version
46 06 = SW version
03 = Bosch ?
4A 54 = Diagversion:84 ($4A54)
00 = ?
07 08 12 = Manuf.Date(D/M/Y): 12/08/07
Request: DT_ID_DCX_ECU_Identification 1A 87 CR4_NFZ: 5A 87 01 03 4A 54 FF 06 31 06 46 00 30 30 34 34 34 36 37 39 34 30
4A 54 diag version
FF -??
06/31 06/46 -HW/SW
00
30 30 34 34 34 36 37 39 34 30 0044467940
Hi folks, Commit https://github.com/jglim/CaesarSuite/commit/061bcfdf01953a0b85dbdd4f9322aac73a4bac87 (Release: https://github.com/jglim/CaesarSuite/releases/tag/v1.4.4 ) includes initial KW2C3PE support from all your help. So far it supports 1A 86
and 1A 87
since those are the only ones that I have seen.
I don't have a KW2C3PE device to test with (tried to find a cheap EZS, turns out they are all expensive around here), please let me know if it does not work as intended.
Attempting to open a connection to (EZS906) with profile 'HSCAN_KW2C3PE_500' Target voltage : 12365 mV nothing happens more Using Scanmatik 2 pro interface
Here is an experimental build that is more verbose, so that I can identify where it is stuck at
CaesarSuite_dbg_2020-12-29.zip
Can you try it again and share the full Diogenes log? Here's an example of what I am seeing:
Initializing new connection to OpenPort 2.0 J2534 ISO/CAN/VPW/PWM using C:\Windows\SysWOW64\op20pt32.dll
Attempting to open a connection to (CRD3) with profile 'HSCAN_UDS_500'
Target voltage : 12025 mV <---- seems to be stuck from here onwards
Preparing to configure interface
Filters enabled, setting configuration
Configuration OK, flushing buffer
Preparing to configure interface (2)
Filters enabled, setting configuration (2)
Configuration OK, flushing buffer (2)
Interface configured
Notifying of new connection status
Preparing to return OK
Starting post-connection tasks
MainForm: calling ConnectionEstablishedHandler
Name: UDS
UDS: Switching session states
Initializing new connection to SM2 USB using C:\Program Files (x86)\Scanmatik\smj2534.dll Attempting to open a connection to (EZS906) with profile 'HSCAN_KW2C3PE_500' Target voltage : 12400 mV Preparing to configure interface Filters enabled, setting configuration Configuration OK, flushing buffer Preparing to configure interface (2) Connection failed with exception : There is already a filter with that identifier ECU Connection was unsuccessful.
Thanks for the prompt response. The "2x filter config" was my attempt to fix AVDI-specific behavior. OpenPort happily allows the filter to be configured twice. Seems like Scanmatik notices this and stops the interface.
I have made another experimental build that recognizes the Scanmatik exception, and should allow you to continue. Maybe this will work.
Initializing new connection to SM2 USB using C:\Program Files (x86)\Scanmatik\smj2534.dll Attempting to open a connection to (EZS906) with profile 'HSCAN_KW2C3PE_500' Target voltage : 12400 mV Preparing to configure interface Filters enabled, setting configuration Configuration OK, flushing buffer Preparing to configure interface (2) Second config exception suppressed: There is already a filter with that identifier Interface configured (2) Notifying of new connection status Preparing to return OK Starting post-connection tasks MainForm: calling ConnectionEstablishedHandler Name: KW2C3PE Running KW2C3PE ConnectionEstablishedHandler KW2C3PE: Switching session states
I assume it is stuck at KW2C3PE: Switching session states
, in this build I have completely removed the 2x filter, perhaps it might make a difference if the error was never triggered.
I noticed that the log indicates a successful detection:
KW2C3PE: Found ID for GetVariantID_1A86
GetVariantID successful with ID 4A54, returning from ConnectionEstablishedHandler
Did the automatic identification work for you? The interface will change if the detection is successful:
Before variant identification:
After variant identification:
Yes it detected but after got a bunch of messages in box
Here is a List called SupplierList_3p7 Hope it will match with our actual tests in detection of ecu. The raw value should match with:
Byte 11
Byte 3
Value | Name |
---|---|
00 | * |
01 | Becker |
02 | Blaupunkt |
03 | Bosch |
04 | MB |
05 | HuF |
06 | Kammerer |
07 | Kostal |
08 | Siemens |
09 | Stribel |
10 | MicroHeat |
11 | JATCO |
16 | SWF |
17 | VDO |
18 | Webasto |
19 | Dornier |
20 | TEG |
21 | Hella |
22 | Lucas |
23 | GKR |
24 | MBB |
25 | Motometer |
32 | Borg |
33 | Temic |
34 | Teves |
35 | Borg Warner |
36 | MED S.P.A |
37 | DENSO |
38 | ZF |
39 | TRW |
40 | Dunlop |
41 | LUK |
48 | Magneti Marelli |
49 | DODUCO |
50 | Alpine |
51 | AMC (AEG Mobile Com.) |
52 | Bose |
53 | Dasa |
54 | Motorola |
55 | Nokia |
56 | Panasonic |
57 | APAG |
58 | Rialtosoft |
59 | Applicom |
60 | Conti Temic |
61 | Cherry |
62 | TI Automotive |
63 | Kongsberg Company |
64 | Delphi |
65 | Alfmeier |
66 | Sidler |
67 | Marquardt |
68 | Wehrle |
69 | megamos |
70 | ADC |
71 | BERU |
72 | Valeo |
73 | Magna |
74 | Allison |
75 | Isringhausen |
76 | Grammer |
77 | Funkwerk Dabendorf |
78 | Hella-Behr |
79 | Pollak |
80 | AKG |
81 | Automotive Lighting |
82 | TAG |
83 | UNITED PARTS |
84 | catem |
85 | Alge |
86 | Pierburg |
87 | Brusa |
88 | Ecostar |
89 | Xcellsis |
90 | Wabco Automotive |
91 | Voith |
92 | Knorr |
93 | TVI |
94 | Stoneridge |
95 | Telma |
96 | STW |
97 | Koyo |
98 | Eberspächer |
99 | ADVICS |
100 | OMRON |
101 | Mitsubishi Heavy Industry |
102 | Methode |
103 | UNISIAJECS |
104 | UNISIA JKC Steering Systems |
105 | AISIN |
106 | Zexel Valeo |
107 | Schrader |
108 | Ballard |
112 | SFT |
113 | Kieckert AG |
114 | Behr |
115 | MB Lenkungen |
116 | Sachs Automotive |
117 | Peiker |
118 | Petri |
119 | Autoliv |
120 | Thien Electronic |
121 | Siemens VDO |
122 | Dornier Consulting GmbH |
123 | Alps |
124 | PREH |
125 | Hitachi Unisia |
126 | Hitachi |
127 | reserved |
128 | Huntsville |
129 | Yazaki |
130 | Lear |
131 | Johnson Controls |
132 | Harman/Becker |
133 | Mitsubishi Electric |
134 | Tokico USA Inc. |
135 | Nippon Seiki(NS Intl) |
136 | Inalfa |
137 | Nippon Seiki (UK) |
138 | GHSP |
139 | Vector |
140 | Gentex |
141 | Visteon |
142 | Tochigi Fuji |
143 | DCA |
144 | May and Scofield |
145 | DaimlerChrysler Hamburg Plant |
146 | AISIN AW |
147 | TOYODA MACHINE WORKS |
148 | Solectron-Invotronics |
149 | Kicker |
150 | American Axle Company |
151 | GETRAG |
152 | Promate |
153 | ArvinMeritor |
160 | Reserved by MMC |
161 | Reserved by MMC-SMART |
162 | Reserved |
254 | After Market Supplier |
255 | Unidentified |
1A 87
CR4_NFZ:
5A 87 01 03 4A 54 FF 06 31 06 46 00 30 30 34 34 34 36 37 39 34 30
1A 86
CR4_NFZ:
5A 86 00 44 46 79 40 31 06 46 06 03 4A 54 00 07 08 12
So my comment was correct 03 = Bosch
@Feezex I believe it should be working well, the messages were added in the special builds to identify any potential problems. I will tidy it up and build a new release.
@N0cynym Thanks for the table. I will think of how I can implement and display your vendor data along with @Feezex's prior work:
If these commands to retrieve the above data are also standardized in UDS , I can try to implement it too.
Hi folks, v1.4.5 is available now, which may improve the KW2C3PE experience:
@Feezex : This release does not contain verbose logging, and might now work with your EZS906
@N0cynym : I am trying out a slightly different connection method in v1.4.5 to try to support AVDI since it required connecting twice to work. The earlier method seems to affect some vendor like Scanmatik. If it still does not work, let me know again and I will try to find a different solution.
Thanks, please note that I am not able to test with avdi for the next upcoming week. Please let me know if you have any wish bench setup for tests. I will check and verify the VC function as soon as possible and will try to explain the fingerprint...
Great as always!
I wish santa can hear my dreams. This image can give you some useful information. also check https://automotive.wiki/index.php/ISO_14229 https://en.wikipedia.org/wiki/Unified_Diagnostic_Services 0x23 0x3D
I wish santa can hear my dreams. This image can give you some useful information. also check https://automotive.wiki/index.php/ISO_14229 https://en.wikipedia.org/wiki/Unified_Diagnostic_Services 0x23 0x3D
You mean we need a form for read and write memory by adress?
@N0cynym : No problem, please rest well and enjoy the new year holidays. Thanks again for your interest in the project and for your prior contributions. I will summarize everyone's testing so far and try to figure out what bench tests are required.
@Feezex : Glad to see confirmation that SM2 works properly with KW2C3PE.
About your feature request, I will look into your request on adding a UDS hex editor.
For the custom unlocking process, I do not have enough information to start. At minimum, I will need to know the CPU model (at least a datasheet for its architecture, reset vector, memory map etc.) and the CFF files for its entire memory. I have never attempted that before, so there is no guarantee and it is also likely that I might never figure it out.
KW2C3PE session switching / variant detection seems to be working now, so this issue will be closed. If something isn't quite right, please feel free to let me know and I can reopen this issue again.
Diogenes currently does not perform any further assistive tasks when initiating a connection with a KW2C3PE target.
For reference, UDS targets will automatically have their session switched to extended, variant detection and filtering is automatic. This is much harder for KW2C3PE, since the command names and request bytes are not standardized.
This is the approximate breakdown of the requirements to fulfill this task, please let me know if any of the rules or assumptions are incorrect.
Negative response, TesterPresent
These aren't standardized, but appear to be consistent with UDS:
3E
7E
7F
Session switch request
The value almost seems to be universal as
10 92
, else it can be reliably guessed by filtering theDiagService.ServiceType.Session
, then looking at the DiagService's qualifier for the word "extended". If this fails, the DiagService with the highest integer value (big-endian) is almost always for extended session.Example:
10 92
10 92
10 92
As long as the session switch request does not respond with a NR, I would assume that it is OK.
Variant detection
In EZS906.CBF, there are no commands that match
1A 87
. In the response, there is nothing that seems to match the variant's identifier of0300
.Variant detection is the major issue that is preventing this feature from being implemented. I do not know which DiagService to call, and I do not know how to interpret the returned result. Any advice on how to move forwards is welcome.