K-Line: Difference between revisions
Line 61: | Line 61: | ||
0x02 - verify and mark blocks as ready to execute. Needs to be called after flashing | 0x02 - verify and mark blocks as ready to execute. Needs to be called after flashing | ||
0x03 - unknown. requires security access, returned 0x33 0xE0 on a bench ecu | |||
0x04 - unknown, returns 0x22 - Conditions Not Correct Or Request Sequence Error | |||
0x05 - unknown, returns 0x22 - Conditions Not Correct Or Request Sequence Error | |||
0x12 - query immobilizer info: 2 bytes number of keys learnt, 2 bytes immo status (01 = learnt), 2 bytes key status (00 - not learnt) | 0x12 - query immobilizer info: 2 bytes number of keys learnt, 2 bytes immo status (01 = learnt), 2 bytes key status (00 - not learnt) |
Revision as of 16:48, 14 January 2024
K-Line on SIMK43 runs at 10400 baud and uses the KWP2000 protocol for diagnostic communication.
Connection points
ECU
- If you have 1.6 or 2.0 without immobilizer installed:
Good news! Your K-Line pins (OBD2/MCC) are connected directly to the K-line pin on the ECU (2.0 - 77)
- If you have 1.6 or 2.0 with immobilizer installed:
Your K-Line pins (OBD2/MCC) are connected to BCM's "Diagnosis" pin (BCM-IM, pin 19). THERE IS NOTHING CONNECTED TO K-LINE PIN AT THE ECU!! (2.0 77). Instead, all K-line stuff is connected to the ECU's W-Line (2.0 - 47)
- If you have 2.7 with or without immobilizer installed:
Your K-Line pins (OBD2/MCC) are connected to BCM's "Diagnosis" pin (BCM-IM, pin 19). Your K/Immo-Line pin at the ECU (C133-1, pin 3) is connected to BCM's "Immo W-line" (BCM-IM, pin 20). 2.7 ECUs don't have a separate K and W line - it's all integrated in one pin, you don't have nothing to worry about.
KWP2000
To start communication, you need to use Fast Init - so bring the K-line down for exactly 25ms, then up for 25ms followed by StartCommunication request. Python example of that using a FTDI cable can be found in GKBus code.
ID of the ECU is 0x11, and as a diagnostic device you should be using ID 0xF1. So an example command and response would look like this:
Diagnostic device: 82 11 F1 27 01 AC
(security access request)
ECU response: 83 F1 11 67 02 34 22
Baudrate
By default, SIMK43 uses 10400 baud. On some ECUs (so far testing revealed that <2005 ECUs might not support that), baudrate can be manipulated by additional undocumented parameter of the StartDiagnosticSession service:
0x01: 10400
0x02: 20000
0x03: 40000
0x04: 60000
0x05: 120000
Challenge-response calculation
SIMK43/41 uses a 2 byte seed and 2 byte key for security access. Until a write-up about the algorithm is prepared, you can take a look at it's Python implementation in GKFlasher: https://github.com/Dante383/GKFlasher/blob/15a715b18f2119d697a5ceed00f6383f690c4a23/ecu.py#L42
Input-Output local identifiers
0x10 - check engine light
0x1A - cooling fan relay high
0x1B - cooling fan relay low
0x23 - idle speed actuator
0x24 - cvvt valve
0x50 - adaptive values
Routines by local identifier
0x00 - erase program section
0x01 - erase calibration section
0x02 - verify and mark blocks as ready to execute. Needs to be called after flashing
0x03 - unknown. requires security access, returned 0x33 0xE0 on a bench ecu
0x04 - unknown, returns 0x22 - Conditions Not Correct Or Request Sequence Error
0x05 - unknown, returns 0x22 - Conditions Not Correct Or Request Sequence Error
0x12 - query immobilizer info: 2 bytes number of keys learnt, 2 bytes immo status (01 = learnt), 2 bytes key status (00 - not learnt)
0x13 - immobilizer password teaching/changing. more info needed
0x14 - immobilizer teaching. more info needed
0x15 - immobilizer reset. more info needed
0x16 - immobilizer limp home mode. more info needed