KI211 can't connect

[mbw211]

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]

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

https://user-images.githubusercontent.com/1116555/213608665-b6903b9d-7a29-40c6-888f-2e71cbdf646a.mp4

The detailed way (much more useful info) is through J2534 logging : https://github.com/jglim/CaesarSuite/discussions/11

[mbw211]

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]

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]

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]

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]

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]

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]

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

[jglim]

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]

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]

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

[jglim]

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]

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

[N0cynym]

@jglim you can have a look at https://github.com/rnd-ash/ecu_diagnostics/pull/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]

Yes, EZS211 also can't connect)

[Feezex]

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]

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]

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]

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

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]

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]

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]

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

[jglim]

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]

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]

UDS editor not an KW2C3PE. Lets umprove it)

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

[Feezex]

https://github.com/jglim/CaesarSuite/issues/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]

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]

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]

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]

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

[jglim]

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]

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

https://user-images.githubusercontent.com/122815418/215764817-f226ab23-1141-4cfc-b802-f5cf8d5025e6.mp4

[Feezex]

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/blob/305e836c210e6971bff9752de0045e6fcd54a46e/Chapter%203%20Connecting%20to%20the%20Vehicle.md

[jglim]

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]

eis not needed. twice checked all wirings, and got some mistakes/ reading attempt - causing unhandled exception

[Feezex]

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

so 00 may cause stuck

[jglim]

Address Width parameter should be set to 3, the values in the video here are correct: https://github.com/jglim/CaesarSuite/issues/52#issuecomment-1410283616

[Feezex]

[Feezex]

lol i dont have seed unlocked ))

[Feezex]

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]

tested on auto, the same behavior as in the previous build ShimDLL_2023-02-01_16-42-51_0537.txt

[Feezex]

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

So they definitely uses different methods

[jglim]

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.

1. 23 39 00 00 08
2. 23 39 00 00 08 (again)
3. 23 39 00 08 08
4. 23 39 00 10 08
5. 23 39 00 10 10
6. 23 39 00 20 10

[Feezex]

the most interesting thing - they dont use seed

[mbw211]

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 (https://github.com/jglim/CaesarSuite/issues/52#issuecomment-1407398657) use cmd 23 39 00 00 10

[jglim]

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

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

[Avarec93]

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]

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