KW2C3PE session switching and variant detection

[jglim]

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:

• TesterPresent request: 3E
• TesterPresent response: 7E
• Negative Response: 7F

Session switch request

The value almost seems to be universal as 10 92, else it can be reliably guessed by filtering the DiagService.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:

• EZS906: SES_Extended_Diagnostic_Session_physical 10 92
• VGSNAG2: SES_Extended_Diagnostic_Session_physical 10 92
• CR4_NFZ: SES_Sel_Diag_Mode_DC_Diag 10 92

As long as the session switch request does not respond with a NR, I would assume that it is OK.

Variant detection

EZS906 (NCV3_0300): Variant Query
1A 87
5A 87 01 43 03 01 00 07 28 08 12 00 39 30 36 35 34 35 36 35 30 38 

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 of 0300.

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.

[N0cynym]

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 0x1A86to identify them.

Let us check following first...

The Service 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

[jglim]

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?

[Feezex]

note plz that 39 30 36 35 34 35 36 35 30 38 is partnumber convert to dec >9065456508

[Feezex]

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

[jglim]

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.

[Feezex]

Challenge accepted

[Feezex]

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

[Feezex]

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

[jglim]

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.

[Feezex]

Attempting to open a connection to (EZS906) with profile 'HSCAN_KW2C3PE_500' Target voltage : 12365 mV nothing happens more Using Scanmatik 2 pro interface

[jglim]

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

[Feezex]

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.

[jglim]

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.

CaesarSuite_dbg_2020-12-29-B.zip

[Feezex]

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

[jglim]

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.

CaesarSuite_dbg_2020-12-29-C.zip

[Feezex]

log.txt

[jglim]

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:

[Feezex]

Yes it detected but after got a bunch of messages in box

[N0cynym]

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:

• Service 0x1A86 Byte 11
• Service 0x1A87 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

[Feezex]

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

[jglim]

@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:

• MB Number
• Part Number
• HW version
• SW version
• Vendor,
• Manufacturing Date

If these commands to retrieve the above data are also standardized in UDS , I can try to implement it too.

[jglim]

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.

[N0cynym]

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...

[Feezex]

Great as always!

[Feezex]

link.txt

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

[N0cynym]

link.txt

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?

[jglim]

@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.

[jglim]

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.