SBEC3 flash re-programming details

This thread serves as a pure theoretical interest towards the SBEC3 re-flashing procedure.
The information presented here is gathered from log files of actual re-flashing sessions and from people knowing much more than me, who understandably didn't go much into detail.

Note: Chrysler CCD/SCI Scanner V1.5.0 and below is not protected against high programming voltage. Do not attempt to apply higher than +5V voltage to any of its pins! Put a custom protection device between scanner and ECU if need to.

Workaround for read-only operations:
- disconnect scanner from OBD2 port,
- while key is off jump battery voltage (OBD2 pin 16) to SCI-RX pin (OBD2 pin 6 for SCI-A configuration) with a wire,
- turn key on,
- remove jump wire a moment later,
- connect scanner to OBD2 port.

At this point the ECU is in bootstrap mode waiting to be unlocked. In this mode the ECU is not able to perform normal engine controller functions. This may cause unexpected behavior of the instrument cluster, etc.

The latest scanner firmware is able to unlock the ECU and upload a stock or custom bootloader application:
- connect to the scanner with GUI,
- set SCI-bus baudrate to 62500 manually (not with the well known 12 command),
- in the expanded view select stock or custom bootloader and click on the "Bootstrap PCM" button,
- shortly after that the GUI responds with success or failure,
- upon success you can continue with step 7 below.

Detailed steps:

1. While ignition switch is off apply +12V bootstrap voltage (could be raw battery voltage) or +20V programming voltage to SCI-RX pin. At this point both voltages will trigger bootstrap mode.

2. Turn key on, remove high voltage from SCI-RX pin.

3. Send a magic byte over SCI-bus at 62500 baudrate and wait for response. Bootstrap code automatically detects baudrate. If 0x7F is sent and 0x06 is received then the ECU baudrate is changed to 62500 baud. Other magic bytes can be used to set different baudrates.

TX: 7F
RX: 06

4. Next, a high-speed variant of the security seed challenge needs to be requested, solved and sent back to unlock ECU. Written bytes are not echoed back.

24:       SCI ID for high-speed security seed request/send
D0 27 C1: security seed request (always the same)
CS:       checksum

24:       SCI ID for high-speed security seed request
D0 27 C2: security seed solution (always the same)
XX YY:    security seed solution itself
CS:       checksum

26:       SCI ID for high-speed security seed response/result
D0 67 C1: security seed response (always the same)
XX YY:    security seed itself
CS:       checksum

26:       SCI ID for high-speed security seed response/result
D0 67 C2: security seed solution accepted (always the same)
CS:       checksum

Example #1:
TX: 24 D0 27 C1 DC       // request security seed
RX: 26 D0 67 C1 6C C0 4A // security seed received: 6C C0
TX: 24 D0 27 C2 AD FC 86 // send security seed solution back: AD FC
RX: 26 D0 67 C2 1F       // solution accepted

Example #2:
TX: 24 D0 27 C1 DC       // request
RX: 26 D0 67 C1 FA A5 BD // seed: FA A5
TX: 24 D0 27 C2 2C FD 06 // solution: 2C FD
RX: 26 D0 67 C2 1F       // accepted

Example #3:
TX: 24 D0 27 C1 DC       // request
RX: 26 D0 67 C1 96 22 D6 // seed: 96 22
TX: 24 D0 27 C2 75 7F D1 // solution: 75 7F
RX: 26 D0 67 C2 1F       // accepted

Seed algorithm by Piton :

uint16_t Math_Seed(uint16_t input)
{
 uint16_t seed = (input+0x247c) | 5;
 int i= seed & 0xF;
 while(i--)
  if(seed & 1)   seed=(seed>>1) | 0x8000;
  else           seed>>=1;
 return (seed | 0x247c);
}
5. Send the bootloader app "01_LdBoot.bin" over SCI-bus. This binary has a header of 5 bytes to let the bootstrap code know where to save the bootloader app and what size it has.

TX: 4C 01 00 03 03 XX YY ZZ ...
RX: 4C 01 00 03 03 XX YY ZZ ...

The ID byte 4C instructs the bootstrap code to prepare to accept and save serial data transmission. After that 01 00 gives a start offset inside RAM where the data transmission should be saved. Next 2 bytes tell the bootstrap code the length of the data transmission + start offset value. XX YY ZZ bytes are the binary instructions of the bootloader application itself.

The bootstrap code echoes back every transmitted byte before being able to accept the next one.

6. Send the "StartLdr" command to start the bootloader application.

TX: 47 01 00
RX: 47 01 00 22

Here 01 00 is the same start offset given in the previous step. After the byte echos the bootloader application responds with 22 if it's taken control over the ECU and ready to accept instructions. Program execution jumps from the bootstrap area to RAM.
Note that when ignition key is cycled the bootloader app gets deleted (since it resides inside RAM) and needs to be uploaded again.

7. Send the "ReqDwnldFnc" command to initiate worker function upload.

TX: 10 00 02 27 F7
RX: 11 00 02 27 F7 14

The ID byte 10 means we are preparing to upload a worker function. After that 00 02 tells the bootloader that the worker function is 2 bytes long. Binary instructions follow. In this example 27 F7 is the "rts" instruction which does nothing but returns from the subroutine to the main bootloader loop.

The bootloader application responds with the ID byte 11 if it's ready to save a worker function. Right after that it echoes every transmitted byte. Finally the byte 14 is transmitted signifying that the bootloader has finished saving the worker function and it's ready to execute.

Note that only 1 worker function can run at any given time.
A worker function can be executed multiple times when necessary.
Any previous upload gets overwritten.
Bootloader application is not affected, worker functions are saved in a different memory area.

8. Send the "FncExecReq" command to execute the worker function.

TX: 20
RX: 21 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 04 72 72 48 41 45 FF F7 AA

The worker function responds with 21 if it's running.
After execution it returns a series of bytes containing the requested information.
In this example a part number reader worker function output is shown displaying the current/old ECU part number.

Part Number: 04727248AE

Note that once a worker function is finished program execution returns to the bootloader which awaits the next command (upload or run last upload).

9. Repeat steps 7-8 to upload the next worker function that performs a different task. These include erasing the flash chip, uploading new flash file, verifying checksum, erase EEPROM, upload settings to EEPROM, etc. Examples can be found in the attached file.

Original binaries and reverse engineered padded binaries are attached below.
SBEC3_re-flashing_binaries.zip (60.65 KB)