KI211 can't connect #52

mbw211 · 2023-01-18T22:06:53Z

I select KI211.cbf and try to connect using OpenPort 2.0 (china) via CANHS but get an access error.

Maybe I'm doing something wrong? This cbf work perfectly in Vediamo and I can open access with your UnlockECU calc.

If I'm not mistaken, I get error 7F 10 21.

I really hope for a solution to this problem, I really liked your HEX editor!

jglim · 2023-01-20T03:01:09Z

Hello mbw211,

Thanks for trying this project out and taking time to open this issue.

From the traces, it seems like the ECU is responding with a "Busy Repeat Request" error when attempting to enter a diagnostics session, which indicates that the ECU is busy handling another request.

This is the first time that I have seen this error type. As Vediamo is working fine, would you be able to help capture the traces so that I can check if there might be an initialization issue?

The quick and easy way (less info):

lolhQWfXrA.mp4

The detailed way (much more useful info) is through J2534 logging : #11

mbw211 · 2023-01-20T15:28:04Z

Hello! Here is capture of traces from Vediamo.

17:12:32 Request:
1A 86
17:12:32 KI211:
5A 86 21 15 40 54 48 18 06 17 06 11 07 0F 00 07
05 16

Hope this helps in solving the problem

Feezex · 2023-01-20T20:53:08Z

DT_STO_ECU_IDENT : 1A 86
KI211 ( 5A 86 is answer header to 1A 86 request ):
5bytes mb number :21 15 40 54 48 = 211 540 54 48
HW 18\06
Manufacturer 17 (from SupplierList_3p7) = VDO
06 11 probably sw
07 0F = metadata variant id 18 07 (07 0F) = AJ_06_1_211
prod date d/m/y 07 05 16

Well this is correct identification from ki211, and your connection is stable.

mbw211 · 2023-01-20T22:39:28Z

Well this is correct identification from ki211, and your connection is stable.

Yes, the conection is stable in vediamo. I have problems with connection in Diogenes tool

jglim · 2023-01-21T15:37:48Z

Thanks for the trace! It is particularly interesting as there is only an ident message 1A 86, and no sign of session changing 10 92.

The suggested solution to a "Busy Repeat Request" is to resend the same message after a short wait. There is a possibility that Vediamo is re-sending that message, however that re-transmission will only be visible on a J2534 log.

I will need to find some time to implement a test build with that behavior, and will be back here again when it is available. In the meantime, if you manage to capture a J2534 log or similar, please let me know as there will be much more information in there.

mbw211 · 2023-01-22T12:41:41Z

Hello! Here I post traces from vediamo made using J2534 shim . I opened ki211.cbf via vediamo, then sent a command to open access and calculated the seed key back.
I hope there is enough information to solve the problem.
ShimDLL_2023-01-22_14-14-31_0249.txt

jglim · 2023-01-22T16:43:36Z

The trace is very helpful, thank you!

So far, this is what I've observed:

When entering a diagnostic session, the message 10 92 is sent to an unknown recipient at address 0x1C. No response message was received (e,g, 50 92). This behavior is not normal, and Diogenes does not proceed because of this situation.
Thereafter, ecu identification starts with 1A 86. This time, the message goes to the expected address at 0x5B4, and correctly receives a response from 0x4F4.
After ECU identification is done, a "tester present" message is sent every second to the unknown address at 0x1C. Again, there are no responses.
Subsequent unlocking behavior is normal. (0x5B4/0x4F4)
When exiting, 10 81 is sent to 0x1C to restore the prior session.

The address 0x1C doesn't seem to be special or defined anywhere, so this seems to be a dead end. However, KI211 appears to be unusual as there seems to be no Session definitions.

In the case where KI211 does not support sessions, it makes sense that 10 92, 10 81 and 3E XX will not work as intended. This might also explain why the current security levels are stored in the persistent EEPROM.

To test this theory, please try using this debug build. This build will not send any session-specific messages, and hopefully it will make better progress.

I've added some notes to the above J2534 trace and cleaned it up a bit:

0.000s ++ PTOpen(*NULL*, 0x039FD380)
  returning DeviceID: 2
  5.048s 0:STATUS_NOERROR

5.048s ** PTReadVersion(2, 0x039FCFF8, 0x039FCFA8, 0x039FCF58)
  Firmware: 1.17.4877
  DLL:      1.01.4341 Jul 10 2014 14:16:35
  API:      04.04
  5.048s 0:STATUS_NOERROR

5.048s ** PTReadVersion(2, 0x039FCDF8, 0x039FCE68, 0x039FCED0)
  Firmware: 1.17.4877
  DLL:      1.01.4341 Jul 10 2014 14:16:35
  API:      04.04
  5.048s 0:STATUS_NOERROR

5.073s ** PTIoctl(2, 3:READ_VBATT, 0x00000000, 0x039FD93C)
  12.308000 Volts
  5.075s 0:STATUS_NOERROR


// uses HSCAN_KW2C3PE_500

22.598s ++ PTConnect(2, 6:ISO15765, 0x00000800, 500000, 0x0B0D87AE)
  Flags: 11:CAN_ID_BOTH
  returning ChannelID: 3
  22.599s 0:STATUS_NOERROR



// configures ISO-TP, request to ECU: 0x5B4, response from ECU: 0x4F4

22.599s ++ PTStartMsgFilter(3, 3:FLOW_CONTROL_FILTER, 0x0CEA9A6C, 0x0CEAAAA4, 0x0CEABADC, 0x0B0D8952)
  Mask[ 0] 6:ISO15765. 4 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ ff ff ff ff
  Pattern[ 0] 6:ISO15765. 4 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 04 f4
  FlowControl[ 0] 6:ISO15765. 4 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 05 b4
  returning FilterID: 0
  22.600s 0:STATUS_NOERROR

22.600s ** PTIoctl(3, 2:SET_CONFIG, 0x0CEAFBFC, 0x00000000)
  3 parameter(s) at 0x0CEAFC1C:
    35:STMIN_TX = 2
    30:ISO15765_BS = 8
    31:ISO15765_STMIN = 40
  22.602s 0:STATUS_NOERROR

22.605s ** PTIoctl(3, 2:SET_CONFIG, 0x0CEAFBFC, 0x00000000)
  3 parameter(s) at 0x0CEAFC1C:
    35:STMIN_TX = 2
    30:ISO15765_BS = 8
    31:ISO15765_STMIN = 40
  22.607s 0:STATUS_NOERROR

22.607s ** PTIoctl(3, 2:SET_CONFIG, 0x0CEAFBF4, 0x00000000)
  0 parameter(s) at 0x0CEAFC14:
  22.607s 0:STATUS_NOERROR

----------------------------------



// enter diag session (defined as FN_Sel_Diag_Mod_Db_Diag)
// request is sent to 0x1C. who is 0x1C? not defined in com-param
// no reply to this message (or it might have been filtered out)

22.607s >> PTWriteMsgs(3, 0x0B1BC442, 0x0CEAFD58, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 00 1c 10 92
  sent 1 of 1 messages
  22.607s 0:STATUS_NOERROR

22.768s >> PTWriteMsgs(3, 0x0B1BC442, 0x0CEAFD58, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 00 1c 10 92
  sent 1 of 1 messages
  22.768s 0:STATUS_NOERROR



// ecu ident, note request to 0x5B4, response from 0x4F4, matches com-params

22.807s >> PTWriteMsgs(3, 0x0B324F2A, 0x0CEAFD54, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 05 b4 1a 86
  sent 1 of 1 messages
  22.808s 0:STATUS_NOERROR

22.840s << PTReadMsgs(3, 0x0AD9BBC2, 0x0C81FECC, 0)
  read 1 of 1 messages
  Msg[ 0] 77.779663s. 6:ISO15765. Actual data 7 of 7 bytes. RxS=0x00000000
  \__ 00 00 04 f4 7f 1a 78
  22.840s 0:STATUS_NOERROR

22.966s << PTReadMsgs(3, 0x0B1BD4B2, 0x0C81FECC, 0)
  read 1 of 1 messages
  Msg[ 0] 77.903992s. 6:ISO15765. Actual data 22 of 22 bytes. RxS=0x00000000
  \__ 00 00 04 f4 5a 86 21 15 40 54 48 18 06 17 06 11 07 0f 00 07 05 16
  22.966s 0:STATUS_NOERROR



// request seed

36.982s >> PTWriteMsgs(3, 0x0B324F2A, 0x0CEAFD54, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 05 b4 27 01
  sent 1 of 1 messages
  36.983s 0:STATUS_NOERROR

37.068s << PTReadMsgs(3, 0x0AD9BBC2, 0x0C81FECC, 0)
  read 1 of 1 messages
  Msg[ 0] 92.003136s. 6:ISO15765. Actual data 14 of 14 bytes. RxS=0x00000000
  \__ 00 00 04 f4 67 01 5a a6 9a 2b c4 8c ca 3c
  37.068s 0:STATUS_NOERROR



// authenticate for level 7, KI211_211_00A9

85.040s >> PTWriteMsgs(3, 0x0B324F2A, 0x0CEAFD54, 0)
  Msg[ 0] 6:ISO15765. 13 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 05 b4 27 02 07 bf 8f 37 0b ff ff
  sent 1 of 1 messages
  85.041s 0:STATUS_NOERROR

85.077s << PTReadMsgs(3, 0x0B345FA2, 0x0C81FECC, 0)
  read 1 of 1 messages
  Msg[ 0] 140.028809s. 6:ISO15765. Actual data 7 of 7 bytes. RxS=0x00000000
  \__ 00 00 04 f4 7f 27 78
  85.077s 0:STATUS_NOERROR

85.140s << PTReadMsgs(3, 0x0AD9BBC2, 0x0C81FECC, 0)
  read 1 of 1 messages
  Msg[ 0] 140.075241s. 6:ISO15765. Actual data 7 of 7 bytes. RxS=0x00000000
  \__ 00 00 04 f4 67 02 34
  85.140s 0:STATUS_NOERROR



// tester present messages also go to the same mysterious 0x1C address, with no response
// first tester present is issued only after ecu ID response (5A 86)
// interval is approx 1000ms
// 3 snippets below for reference
// our current implementation sends `3E 01`, hence the negative response `7F 3E 12`

86.795s >> PTWriteMsgs(3, 0x0B1BC442, 0x0CEAFD58, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 00 1c 3e 02
  sent 1 of 1 messages
  86.795s 0:STATUS_NOERROR

87.857s >> PTWriteMsgs(3, 0x0B1BC442, 0x0CEAFD58, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 00 1c 3e 02
  sent 1 of 1 messages
  87.857s 0:STATUS_NOERROR

88.890s >> PTWriteMsgs(3, 0x0B1BC442, 0x0CEAFD58, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 00 1c 3e 02
  sent 1 of 1 messages
  88.890s 0:STATUS_NOERROR



// "reconfiguring" J2534 device, no actual change, identical values to prior config

90.362s ** PTIoctl(3, 2:SET_CONFIG, 0x0CEAFBFC, 0x00000000)
  3 parameter(s) at 0x0CEAFC1C:
    35:STMIN_TX = 2
    30:ISO15765_BS = 8
    31:ISO15765_STMIN = 40
  90.363s 0:STATUS_NOERROR

90.364s ** PTIoctl(3, 2:SET_CONFIG, 0x0CEAFBF4, 0x00000000)
  0 parameter(s) at 0x0CEAFC14:
  90.364s 0:STATUS_NOERROR



// exit diagnostic session, back to default

90.364s >> PTWriteMsgs(3, 0x0AD9BBC2, 0x0CEAFD58, 0)
  Msg[ 0] 6:ISO15765. 6 bytes. TxF=0x00000040
  TxFlags: 6:ISO15765_FRAME_PAD
  \__ 00 00 00 1c 10 81
  sent 1 of 1 messages
  90.364s 0:STATUS_NOERROR



// clean up and close

100.727s -- PTStopMsgFilter(3, 0)
  100.727s 0:STATUS_NOERROR
100.727s -- PTDisconnect(3)
  100.728s 0:STATUS_NOERROR
100.759s -- PTClose(2)
  100.775s 0:STATUS_NOERROR

mbw211 · 2023-01-22T20:50:32Z

Tested your debug version, it still show error... Look at photos.

jglim · 2023-01-23T05:54:40Z

Here's another attempt, this time I've enabled session messages again, but their addresses are hard-coded to 0x1C. This is closer to Vediamo's behavior, even if it does not make sense to me yet.

CaesarSuite_dbg_2023_01_23-B.zip

N0cynym · 2023-01-23T07:05:24Z

Here's another attempt, this time I've enabled session messages again, but their addresses are hard-coded to 0x1C. This is closer to Vediamo's behavior, even if it does not make sense to me yet.

CaesarSuite_dbg_2023_01_23-B.zip

CAN ID 0x01C is used as global session control and IC211 cares alot about this CAN ID....

mbw211 · 2023-01-23T09:07:33Z

I tried the new debug version, the connection error still remained. Look at the photo.

jglim · 2023-01-24T14:13:37Z

At this time, I am still unable to identify the source of the issue. Would you be able to capture the J2534 trace again, but this time using Diogenes? I will try to compare the new trace with the previous upload to see if there are other differences that I might have missed.

@N0cynym interesting, thanks for pointing that out. Can you also refer me to more details on 0x1C being the global session control? I've checked the communication params and haven't seen them there, perhaps they are defined elsewhere.

mbw211 · 2023-01-24T16:49:30Z

Here is j2534 trace from Diogenes
ShimDLL_2023-01-24_18-31-20_0122.txt

N0cynym · 2023-01-24T17:57:34Z

@jglim you can have a look at rnd-ash/ecu_diagnostics#6.

So we had this issue with EZS211 because it's also using ID 0x01C as global global_session_control.

It might be hard coded into the caeser server but we never figured out which communication parameter in CBF is triggering it.

mbw211 · 2023-01-24T20:07:28Z

Yes, EZS211 also can't connect)

Feezex · 2023-01-25T09:19:02Z

im suspecting this Id has to be ZGW, wake up command.
Possibly this why W164, W169, W209, W211 used to have zgw on bech while working with eis and other units.

Feezex · 2023-01-25T12:56:36Z

w203_zgw_and_eis_bench_read.txt
bus trace for w203 eis readout by cgmb over zgw
And another one showing cgmb lookup for eis while its powered off (zgw also off).
noresponse_trace.txt

Feezex · 2023-01-26T11:23:03Z

Small update. For 01C dialog understanding.
Previous traces been taken with 500k baud, but now i understand that zgw do his job converting 83.3k EIS to 500k diag.
I put sniffer between ZGW and EIS to get clear conversation to 203 EIS. its 83.3k.
83.3k_W203 EIS CGMB reading_sniff_between ZGW and EIS.txt

jglim · 2023-01-26T12:45:14Z

@mbw211 I've compared your new traces between Diogenes/Vediamo, and so far I've found some differences:

STMIN_TX config uses a magic value of 2. The only com-param that uses 2 is CP_C_REQ_SUG.
ISO15765_BS is set as 8. No com-param has a value of 8. There is a chance that 8 is a default value if that com-param is undefined.
The session request 10 92 is sent twice by Vediamo. Looking at the traces from @Feezex , CGMB sends that value 5x, so this is a strange problem with an equally strange solution.

This debug build will send the session request twice, and force the j2534 config to be set like Vediamo, i.e.

STMIN_TX = 2
ISO15765_BS = 8
ISO15765_STMIN = 40

Thanks for taking time to debug this issue here together. Again, if it doesn't work, please upload the traces.

@N0cynym Glad to see that this is a known issue and has been worked on before. I'll dig deeper into that linked issue if this gets stuck.

@Feezex Appreciate the gateway hint and the traces. After your remark on zgw/eis baud conversion, I then noticed that there is an option for an 83.3k connection for KI211. This might allow for a direct connection without a gateway?

mbw211 · 2023-01-26T16:58:23Z

option for an 83.3k connection for KI211

Openport (china), as far as i know, can't work with LSCAN. Only HSCAN...
I will try to connect using new debug version later and report back

Feezex · 2023-01-26T19:28:49Z

option for an 83.3k connection for KI211

Openport (china), as far as i know, can't work with LSCAN. Only HSCAN... I will try to connect using new debug version later and report back

Dunno about china openport, im working with original SM2 Pro never had issues with CAN or K.

Feezex · 2023-01-26T19:30:32Z

I then noticed that there is an option for an 83.3k connection for KI211. This might allow for a direct connection without a gateway?

I guess thats the main purpose of couple connection methods that used in single control unit.

mbw211 · 2023-01-26T19:38:02Z

Trace from Diogenes, your last dbg build
ShimDLL_2023-01-26_21-24-23_0655.txt

jglim · 2023-01-27T15:53:42Z

Testing if it is a timing issue, since Diogenes sends all 3 messages, 1092, 1092 and 1A86 in the span of only 4 milliseconds according to the trace.

Vediamo sends 1092, waits for ~161ms, sends 1092 again, waits for ~39ms, then sends 1A86.

CGMB takes about 175ms between the first 1092 and 1A86.

This build sends 5x 1092 with an additional 35ms+ delay between messages before sending 1A86 (approx 175ms total)

mbw211 · 2023-01-28T13:24:53Z

It was a timing issue! Now Diogenes can connect to KI211 and unlock it (manually).

But I have a problem with reading eeprom using your UDS Hex Editor. Diogenes send commands 23 14 00 ...
Sorry for bad quality of photo :(

As I understand, now Diogenes send cmd 23 14 [address]

Feezex · 2023-01-28T14:31:01Z

UDS editor not an KW2C3PE.
Lets umprove it)

and i was rignt about (07 0F) = AJ_06_1_211 = ))

Feezex · 2023-01-28T15:32:05Z

#16

Request SID	Response SID	Service	Description

0x23	0x63	Read Memory By Address	Read data from the physical memory at the provided address. This function can be used by a testing tool, in order to read the internal behaviour of the software

0x3D	0x7D	Write Memory By Address	The “Write Memory By Address” service allows the external diagnostic tool to write information into the ECU at one or more contiguous memory locations.

It will allow you to read and write after seed key unlocking procedure
Meanwhile you getting reject messages

mbw211 · 2023-01-28T15:49:04Z

Meanwhile you getting reject messages

Reject msg is because the Diogenes cmd is not correct. But I want to work with eeprom using UDS Hex Editor. The problem is that Diogenes send wrong msg (23 14 00...) and KI cant recognize it.
when i tried i unlocked ki211 using UnlockEcu tool

Feezex · 2023-01-28T21:25:03Z

Now time to switch issue to UDS Hex Editor #16 since connection one seems to be solved.

"14 00" looks odd here,
cant find it in code :

        this.nudReadCmd.Name = "nudReadCmd";
        this.nudReadCmd.Size = new System.Drawing.Size(250, 32);
        this.nudReadCmd.TabIndex = 6;
        this.nudReadCmd.Value = new decimal(new int[] {
        35,
        0,
        0,
        0});

where 35 is the 0x23 write comand,

            uint remainder = destinationAddress - readCursor;
            int readSize = strideWidth;
            if (readSize > remainder) 
            {
                readSize = (int)remainder;
            }
            List<byte> readCommand = CreateReadCommand(readCmd, alfid, readCursor, addressWidth, readSize);

Alfid ?

        int strideWidth = decimal.ToInt32(nudIOWidth.Value);
        int addressWidth = decimal.ToInt32(nudAddressWidth.Value);
        int ioDigitCount = GetMemoryDigitCount(strideWidth);
        byte readCmd = decimal.ToByte(nudReadCmd.Value);
        byte positiveResponse = (byte)(readCmd + 0x40);

        byte alfid = GetAddressAndLengthFormatIdentifier(
                    addressWidth,
                    ioDigitCount
                );

correct me if I am wrong

jglim · 2023-01-30T05:06:14Z

Nice! Glad to see that it is finally connected. So it seems that the gateway needed more time to initialize before bridging between 500k <-> 83.3k.

Now to consolidate the changes and figure out how to best include them into the main branch..

Gateway address is defined in com-params as CP_GLOBAL_REQUEST_CANIDENTIFIER. The default value in Vediamo is 0x1C, and on some UDS targets, the CBF files can overwrite that address (0x441).
Session messages (1092, 1081), testerpresent (3Exx) are sent as global requests. Normally this is sent directly to the ECU (CP_REQUEST_CANIDENTIFIER). Is there an indicator that specifies whether to choose between this new "global" behavior, or the previous "direct" behavior? Global makes sense for connecting through the vehicle OBD port, but will probably break direct bench connections.
For reasons unknown so far, the original Vediamo trace shows testerpresent messages as 3E 02. When checking KI211 com-params in Vediamo, CP_TESTERPRESENT_MESSAGE is defined as 0x3E01. How did that value change to 3E 02?.
During global session initialization, Vediamo sends the 10 92 "enter diagnostic session" twice, CGMB sends that 5x. There is a mandatory wait time. Is that value defined in CP_GLOBAL_FIRST_R1_SUG?
J2534 filter values needs checking
- ISO15765_STMIN is correctly loaded from CP_STMIN_SUG (mapped to CP_StMin)
- STMIN_TX should be loaded from CP_StMinOverride, mapped to CP_C_REQ_SUG
- ISO15765_BS should be loaded from CP_BlockSize (mapped to CP_BLOCKSIZE_SUG), default 8
Message sending was modified to skip replies. When sending global requests, the preconfigured filter probably won't allow the response to arrive. Vediamo does not seem to care about the response.

With regard to the UDS hex editor, @Feezex is correct that the messages are formatted specifically for UDS.

The KI211 parameters are specified in the CBF

DT_Read_Address		User	8	0	5	1	23 00 00 00 01
DT_Read_Address_Word	User	8	0	5	1	23 00 00 00 02
DL_Write_Address	User	1	0	6	0	3D 00 00 00 01 00 00
DL_Write_Address_Word	User	1	0	6	0	3D 00 00 00 02 00 00

To read one byte from 0x390000, the message will be 23 39 00 00 01.
To write the byte AA at 0x390000, the message will be 3D 39 00 00 01 AA

The first byte 23 or 3D is the operation (read/write)
The next 3 bytes are for the address, encoded in big-endian
The subsequent 1 byte is the size (how many bytes to fetch or write)
Any remaining bytes are used as the payload for write operations

Notice how the address size is fixed (3 bytes) and the size is also fixed (1). For UDS, there is an additional value "alfid" AddressAndLengthFormatIdentifier that allows changes to those sizes. The equivalent alfid here would have been 0x13

(1-byte size << 4) | 3-byte address

If this style of memory read/write is consistent across most KW2C3PE devices, I can look into adding a KW2C3PE mode for the memory editor.

Feezex · 2023-01-30T10:38:31Z

so it would be new tab - kw2c3pe hex editor ?
or checkbox to disable alfid to switch over uds / kw2c3pe?

jglim · 2023-01-31T07:42:40Z

Here's a build that adds a checkbox to toggle ALFID, since it might take a while to find proper answers for these questions.

@mbw211 thanks for your patience and I hope this settings will work for your use case:

Source address: 390000
Destination: 800
[ ] Address  [X] Size
Address Width: 3
IO Width: 10
Read.. : 23
Write..: 3D
[ ] AddressAndLengthFormatID

EDIT: Remember to back up your entire EEPROM before attempting any writes

Also consider that in the event of a corrupted write, you might need to use an external tool to write to the eeprom directly if it does not boot.
After a write, re-read from the device before resetting. If it looks abnormal, you can probably still manually issue write commands to fix the affected regions.

mbw211 · 2023-01-31T12:45:59Z

I tried the latest build, when I try to read eeprom, on the first lines the program freezes and cannot read it completely. I post video and j2534 trace below.
ShimDLL_2023-01-31_14-33-31_0340.txt

video_2023-01-31_14-50-20_Trim.mp4

Feezex · 2023-01-31T19:01:37Z

Notice:
Atemmpted to bench solo Ki211, no luck on 83,3k\500k.
Got confirmation it can work solo with no proof.
Vesiamo fails with response time fault, Sniffer shows data flow on 0x408, 0x412.
Adding ZGW didnt gave result, tomorrow i will add EIS and expecting to determine wake up signal.

Vedi have "Clamp 15 handling" function - but it looks useless there.

Possible function for CaesarSuite is Clamp 15,
Here is default Clamp15.cbf

It can also be adjustable (user defined) id and data, or selectable:

Mercedes-Benz model codes	Wake-up Packet ID	DLC	Wake-Up Packet Content
W164 (M class)	04E4	8	02 10 92 00 00 00 00 00
W169 (A class)	001C	8	02 10 92 00 00 00 00 00
W203 (C class)	001C	8	02 10 92 00 00 00 00 00
W209 (CLK class)	001C	8	02 10 92 00 00 00 00 00
W211 (E class)	001C	8	02 10 92 00 00 00 00 00
W215 (CL class)	001C	8	02 10 92 00 00 00 00 00
W216 (CL class)	0692	8	02 10 92 00 00 00 00 00
W219 (CLS class)	001C	8	02 10 92 00 00 00 00 00
W221 (S class)	0692	8	02 10 92 00 00 00 00 00
W240 (Maybach S class)	04E4	8	02 10 92 00 00 00 00 00
W245 (B class)	001C	8	02 10 92 00 00 00 00 00
W251 (R class)	04E4	8	02 10 92 00 00 00 00 00

Source page by @FransUrbo at Ashcon Mohseninia's project page [>>](https://github.com/rnd-ash/mercedes-hacking-docs.git) https://github.com/rnd-ash/mercedes-hacking-docs/blob/305e836c210e6971bff9752de0045e6fcd54a46e/Chapter%203%20Connecting%20to%20the%20Vehicle.md

jglim · 2023-02-01T04:41:01Z

The testerpresent messages are normally suppressed when sending messages in bulk. For KI211, this is a new issue as the primary ECU (KI211) is not the recipient of the testerpresent messages (received by ZGW instead). In this case, I assume that the ZGW has closed the bridge between 500k/83.3k when it did not receive a testerpresent message after a few seconds.

This build has the testerpresent-suppression behavior disabled.

@Feezex Got it, looking forward to hearing more about your investigation

I looked at the CLAMP15 file, however I could not understand how the file is used. The parameters are filled with placeholder FF values, and there is no embedded script. There is only one valid message 21 50.

From googling, I found a document that describes CLAMP15. This is a class of ECUs that require ignition to be on, normally detected through a separate pin (maybe voltage on a specific pin).

If a CLAMP15-type ECU does not detect ignition, the CAN transceiver must be fully bus-off, and will not be able to receive any CAN frames. This might explain the need for the EIS to be present.

With regard to the "wake up packet" and table, those messages 02 10 92 00 00 00 00 00 are padded ISO-TP messages, equivalent to 10 92 i.e. enter diagnostic session. The addresses vary; 0x1C is the default value for CP_GLOBAL_REQUEST_CANIDENTIFIER. I haven't seen 0x4E4 or 0x692 around, though it will be best to load these values directly from the CBF ComParams directly if they exist.

Feezex · 2023-02-01T07:35:44Z

eis not needed.
twice checked all wirings, and got some mistakes/

reading attempt - causing unhandled exception

Feezex · 2023-02-01T10:01:21Z

last build didnt made it work.
I noticed it sends : 23 00 39 00 00 10

so 00 may cause stuck

jglim · 2023-02-01T10:25:31Z

Address Width parameter should be set to 3, the values in the video here are correct: #52 (comment)

Feezex · 2023-02-01T10:35:05Z

Feezex · 2023-02-01T10:59:03Z

lol i dont have seed unlocked ))

Feezex · 2023-02-01T11:27:17Z

211_read_ee.zip
Readed eep with abrites
so that maybe will help
Trace made with bridge that marks each side as ECU1/ECU2 (abrites/ki211), zgw still here so there might be alot of other data

pay attention
row 921
CAN2( SVCI): 9849 5B4 8 05 23 39 00 00 08 FF FF
CAN1(KI211): 9894 4F4 8 10 09 63 E1 17 C2 2F 84
where E117C22F84 is the start of dump

mbw211 · 2023-02-01T14:51:25Z

tested on auto, the same behavior as in the previous build

ShimDLL_2023-02-01_16-42-51_0537.txt

Feezex · 2023-02-01T16:00:35Z

eep_read_cgmb.txt
one more trace to compare reading by SVCI/CGMB technique

So they definitely uses different methods

jglim · 2023-02-02T11:33:21Z

I still don't have answers yet, but here are some notes:

In the original trace from @mbw211 , the first read appears to be successful, responding with the first 16 bytes, EB CB D7 97 AF 2F 5E 5F BC BE 79 7D F2 FA E5 F5.
The next read appears to be requested "successfully", however the ECU never responds and the connection times out.

I've looked at the extra traces from CGMB/Abrites from @Feezex as well, which were interesting:

CGMB reads in blocks of 32 bytes (0x20). The equivalent iso-tp message is 23 39 00 00 20. Abrites reads in blocks of 8 bytes (23 39 00 00 08).
Both CGMB and Abrites send a iso-tp equivalent message of just 3E (not 3E 02 like Vediamo)
Abrites only sends the diag session request 10 92 message once.
Through the entire trace, Abrites only sends the testerpresent message on 3 occasions. This might mean that this message might be less important than expected.
While all 3 Abrites testerpresent messages are identical in iso-tp (3E), the last frame is padded differently.

Abrites:
CAN2:	5637	01C	8	01	3E	FF	FF	FF	FF	FF	FF
CAN2:	5700	01C	8	01	3E	FF	FF	FF	FF	FF	FF
CAN2:	5890	01C	8	01	3E	02	00	00	00	00	00


CGMB (for reference):
CAN2:	54975	01C	8	01	3E	FF	FF	FF	FF	FF	FF

Abrites: No testerpresent messages were sent while the entire memory was accessed.
CGMB: Sends a testerpresent between every memory read request.

I am curious to find out if this issue occurs when sending this commands manually by hand. Could anyone try to send the below commands using Diogenes (most recent debug build), through the J2534 console to see if the connection still fails.

If it fails, could you also try repeating the commands in Vediamo and post both traces here.

23 39 00 00 08
23 39 00 00 08 (again)
23 39 00 08 08
23 39 00 10 08
23 39 00 10 10
23 39 00 20 10

Feezex · 2023-02-02T11:34:32Z

the most interesting thing - they dont use seed

mbw211 · 2023-02-02T12:28:05Z

Diogenes trace with manual cmd
ShimDLL_2023-02-02_14-14-01_0573.txt

CGMB reads in blocks of 32 bytes (0x20). The equivalent iso-tp message is 23 39 00 00 20. Abrites reads in blocks of 8 bytes (23 39 00 00 08)

hex editor by sergeyklenov (#52 (comment)) use cmd 23 39 00 00 10

jglim · 2023-02-02T13:45:09Z

@mbw211 There seems to be no errors when reading with 8-byte wide requests (23 39 0X XX 08). Assuming that this might be another timing issue, I've made a change to the reader to wait for a short period before issuing another request.

With this new build, can you try this combination:

Source Address: 390000
Destination: 800
[ ] Address [X] Size

Address Width: 3
IO Width: 8 <--- use 8 instead
ReadMemory.. : 23
WriteMemory.. : 3D

[ ] ALFID

@Feezex 7F XX 33 is the UDS NRC for "Security Access Denied", unlock is required but thanks for trying. It is definitely interesting how the other tools managed to do this without authenticating.

mbw211 · 2023-02-02T14:00:45Z

Yes! It works! I tried also with IO width 10 and also work. Thanks.

Avarec93 · 2023-03-02T19:48:33Z

Yes! It works! I tried also with IO width 10 and also work. Thanks.

How can i contact with you? any e-mail or TG (телегу)

Feezex · 2023-03-02T22:12:05Z

Оставь свои контакты

Avarec93 · 2023-03-02T22:18:43Z

Телега

mbw211 closed this as completed Feb 2, 2023

jglim mentioned this issue Mar 24, 2023

KI221 Communication #56

Open

KI211 can't connect #52

KI211 can't connect #52

Comments

mbw211 commented Jan 18, 2023 • edited Loading

jglim commented Jan 20, 2023

mbw211 commented Jan 20, 2023 • edited Loading

Hello! Here is capture of traces from Vediamo.

Feezex commented Jan 20, 2023

mbw211 commented Jan 20, 2023

jglim commented Jan 21, 2023

mbw211 commented Jan 22, 2023 • edited Loading

jglim commented Jan 22, 2023

mbw211 commented Jan 22, 2023

jglim commented Jan 23, 2023

N0cynym commented Jan 23, 2023

mbw211 commented Jan 23, 2023

jglim commented Jan 24, 2023

mbw211 commented Jan 24, 2023

N0cynym commented Jan 24, 2023

mbw211 commented Jan 24, 2023

Feezex commented Jan 25, 2023

Feezex commented Jan 25, 2023 • edited Loading

Feezex commented Jan 26, 2023

jglim commented Jan 26, 2023

mbw211 commented Jan 26, 2023 • edited Loading

Feezex commented Jan 26, 2023

Feezex commented Jan 26, 2023

mbw211 commented Jan 26, 2023

jglim commented Jan 27, 2023

mbw211 commented Jan 28, 2023 • edited Loading

Feezex commented Jan 28, 2023 • edited Loading

Feezex commented Jan 28, 2023 • edited Loading

mbw211 commented Jan 28, 2023 • edited Loading

Feezex commented Jan 28, 2023 • edited Loading

jglim commented Jan 30, 2023

Feezex commented Jan 30, 2023

jglim commented Jan 31, 2023 • edited Loading

EDIT: Remember to back up your entire EEPROM before attempting any writes

mbw211 commented Jan 31, 2023 • edited Loading

Feezex commented Jan 31, 2023 • edited Loading

jglim commented Feb 1, 2023

Feezex commented Feb 1, 2023

Feezex commented Feb 1, 2023

jglim commented Feb 1, 2023

Feezex commented Feb 1, 2023

Feezex commented Feb 1, 2023

Feezex commented Feb 1, 2023 • edited Loading

mbw211 commented Feb 1, 2023 • edited Loading

Feezex commented Feb 1, 2023 • edited Loading

jglim commented Feb 2, 2023

Feezex commented Feb 2, 2023

mbw211 commented Feb 2, 2023 • edited Loading

jglim commented Feb 2, 2023

mbw211 commented Feb 2, 2023 • edited Loading

Avarec93 commented Mar 2, 2023 • edited Loading

Feezex commented Mar 2, 2023

Avarec93 commented Mar 2, 2023

mbw211 commented Jan 18, 2023 •

edited

Loading

mbw211 commented Jan 20, 2023 •

edited

Loading

mbw211 commented Jan 22, 2023 •

edited

Loading

Feezex commented Jan 25, 2023 •

edited

Loading

mbw211 commented Jan 26, 2023 •

edited

Loading

mbw211 commented Jan 28, 2023 •

edited

Loading

Feezex commented Jan 28, 2023 •

edited

Loading

Feezex commented Jan 28, 2023 •

edited

Loading

mbw211 commented Jan 28, 2023 •

edited

Loading

Feezex commented Jan 28, 2023 •

edited

Loading

jglim commented Jan 31, 2023 •

edited

Loading

mbw211 commented Jan 31, 2023 •

edited

Loading

Feezex commented Jan 31, 2023 •

edited

Loading

Feezex commented Feb 1, 2023 •

edited

Loading

mbw211 commented Feb 1, 2023 •

edited

Loading

Feezex commented Feb 1, 2023 •

edited

Loading

mbw211 commented Feb 2, 2023 •

edited

Loading

mbw211 commented Feb 2, 2023 •

edited

Loading

Avarec93 commented Mar 2, 2023 •

edited

Loading